Last night I was trying to get a VeriSign issued SSL certificate installed on my ASA using Cisco ASDM 6.2. I installed the Intermediate CA and the CA certificates all installed. I then imported the SSL certificate into the “Configuration -> Device Management -> Manage Certificates -> Identity Certificates” but it did not seem to work. I kept getting an error “Failed to parse or verify imported certificate”. The certificate was in the .p7b form. Changing the format of the certificate to X.509 Base64 Encoded format resulted in acceptance of the certificate.
I sincerely hope that Cisco alters its error messages to accurately reflect that .p7b is not a format supported by them.

Update: This link has the information on how to install SSL certificates on ASA:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00809fcf91.shtml

An interesting thing happened today …I was trying to redirect some input to /dev/null in cygwin…using something like:
some_exec -p params 2>&/dev/null | grep blah
I kept getting an error : bash: Ambiguous redirect.
I then realized that I should probably doing a simple direct and not a re-direct…seemed to solve my problem. Come to think of it…it makes sense, why should I need to redirect when I’m sending it to /dev/null…should simply be able to direct it using:
some_exec -p paraa 2>/dev/null | grep blah

In the capitalist world, it is said that the companies survive on the hyper-consumerism of the people. The highly competitive economical scenario results in an environment where (as they say) consumer is the winner, but not without a fight.
A few weeks back, my Compaq Presario Laptop 2575us went bad. Well, the laptop is 2 yrs old and it has already been serviced twice so I guess my patience thresholds have diminished over a period of time. But this time around a person with even immense patience could have lost his mind. So here’s what happened. My laptop’s S-video port had been dysfunctional since the time I can recall but I never had so much time to let my laptop go out of my hands. This time when I sent it for repairs my laptop almost disappeared from the face of the earth for almost 25 days. And when they returned it to me to a wrong address I had a premonition of difficult times. The “repaired” laptop even failed to start.
This really infuriated me coz my 25 day wait had gone down the drain. So I called up the customer care and they asked me to ship the laptop to service center yet again. But this time around they wanted me to wait for 3 days before I could FedEx it to them. It was completely unacceptable to me. So I spoke to the supervisor and became as adamant as a stone. I continued to ask him for next day shipping and he continued to repeat that he could not do that. A 2hr45min sparring continued on the phone and it resulted in him being the loser as he disconnected the phone. He kept saying that this discussion is going nowhere as we cannot reach an agreement and I kept insisting that the call had multiple destinations : 1. To the HP supervisors and 2. To the BBB .
This guy called himself Nick and he also refused to give me his employee number. I knew very well (because of past experience that Compaq uses words like “You have no proof for your requests” etc.) so this time I needed some real strong evidence of my conversation. So I requested the permission from this Nick guy to allow me to record the conversation. I think this made him a little wary of my intentions. But still he did not give me his details. I think he was really scared because he felt that my wrath could result in him facing the music from his bosses in Palo Alto, CA. There were a few interesting discussions, for example, he said “I am Nick and you can identify me with this name alone.” to which I retorted by saying “Well…I know that Nick is a common name in U.S and you guys might as well redirect my call to NY Knicks judging by the way things are going.”.
So the next day I called up the HP Customer Care Service Manager’s Line at 1-877-917-4380 , code 94 option 1. This time I spoke to a guy called Douglas Gilmore who was equally tough with me (if not more). He refused to acknowledge any of my concerns initially. But later as the conversation progressed, it went on from being just a plain discussion to a heated argument. However, I did not utter even a single foul word because I knew that he could use my language as a pretext to disconnect my call which I was not willing to risk at all. So throughout the discussion I kept my head cool and tried to explain the things to him. But after going through the history of the whole thing, he realized that I had suffered a lot because of this laptop and that the attitude of the Customer care was rather cold. So he finally agreed to give me a replacement after much requests. This was probably my best argument till date and I think that it was some good thinking on my part as well as some codial behavior on the part of the managers that I could get what I truly deserved: a replacement to my defective laptop.
-Rajat.
Japanese art forms

I was just browsing away when I stumbled upon Johnny Long’s GooScan. He says that this is a Linux only tool but it seems to compile (not without problems though) on cygwin.
I kept getting the following errors:

L:\tools\gooscan-v1.0.9>gcc gooscan.c
gooscan.c: In function `inet_send':
gooscan.c:575: error: `MSG_WAITALL' undeclared (first 
                       use in this function)
gooscan.c:575: error: (Each undeclared identifier is 
                       reported only once
gooscan.c:575: error: for each function it appears in.)

Then I read somewhere that MSG_WAITALL is not defined for Cygwin and that instead of that zero would work. There are many neater solutions to this…but I’m a hacker and I’ll do the stuff that’s easiest and hassle-free.
Some people say that the following will work:
#ifdef __CYGWIN__
#define MSG_WAITALL 0

So in order to compile this bad boy, you need to goto line 574 in your favorite editor.
It looks like this:
recv(sock, recvbuf, sizeof(recvbuf), MSG_WAITALL);

You need to make it look like this:
recv(sock, recvbuf, sizeof(recvbuf), 0);//MSG_WAITALL);

You are all set:
gcc gooscan.c -o gooscan.exe

Compilation works! But then I observed that the results were not coming well. However, if you run it through a local proxy such as burp it still works…I bet it has something to do with socket establishment and receiving and being incompatible with the MSG_WAITALL flag.
But as long as you can get the results … who cares? If someone figures out exactly how to make this work, please post it as a comment.

Copy paste the text shown below into a file called madwifing-r3876.patch.

--- madwifi/ath/if_ath.c  2008-11-07 01:05:07.000000000 -0500
+++ madwifi-patched/ath/if_ath.c   2008-11-06 17:56:59.000000000 -0500
@@ -3000,6 +3000,7 @@
 ath_tx_startraw(struct net_device *dev, struct ath_buf *bf, struct sk_buff *skb)
 {
        struct ath_softc *sc = dev->priv;
+       struct ieee80211com *ic = &sc->sc_ic;
        struct ath_hal *ah = sc->sc_ah;
        struct ieee80211_phy_params *ph = &(SKB_CB(skb)->phy);
        const HAL_RATE_TABLE *rt;
@@ -3012,7 +3013,8 @@
        struct ieee80211_frame *wh;

        wh = (struct ieee80211_frame *)skb->data;
-       try0 = ph->try[0];
+       //try0 = ph->try[0];
+        try0 = (ic->ic_opmode == IEEE80211_M_MONITOR) ? 1 : ph->try[0];
        rt = sc->sc_currates;
        txrate = dot11_to_ratecode(sc, rt, ph->rate[0]);
        power = ph->power > 60 ? 60 : ph->power;
@@ -3036,7 +3038,8 @@
        rt = sc->sc_currates;
        KASSERT(rt != NULL, ("no rate table, mode %u", sc->sc_curmode));

-       if (IEEE80211_IS_MULTICAST(wh->i_addr1)) {
+       //if (IEEE80211_IS_MULTICAST(wh->i_addr1)) {
+        if (IEEE80211_IS_MULTICAST(wh->i_addr1) || ((ic->ic_opmode == IEEE80211_M_MONITOR) && (skb->data[1]&3) != 0x01) ) {
          flags |= HAL_TXDESC_NOACK;    /* no ack on broad/multicast */
          sc->sc_stats.ast_tx_noack++;
          try0 = 1;

Check out the madwifi driver as follows:

sudo ifconfig ath0 down
sudo ifconfig wifi0 down
svn -r 3876 checkout http://svn.madwifi.org/madwifi/trunk/ madwifi-ng
cd madwifi-ng
patch -Np1 -i ../madwifing-r3876.patch
sudo ./scripts/madwifi-unload
make
sudo make install
sudo depmod -ae
sudo modprobe ath_pci

These instructions are similar to the ones written here (for a different revision):
http://www.aircrack-ng.org/doku.php?id=madwifi-ng

I’ll be attending the Shmoocon in Washington, DC from Feb 6th-8th. Hope to see all you h4X0rs out there!

The New Year brings in interesting things (or so we hope). My friend came up to me with an “infected” computer with a fantastic piece of malware installed. The malware was presented the user with a completely different HTML page when something was searched on Google. Browser Helper Objects (BHOs) are Dynamic Link Libraries (DLLs) that are installed in Internet Explorer (IE) and have a complete access to the DOM tree of the browser window. The name of the DLL was xyusx.dll (or something like that). This DLL was packed so that it wouldn’t permit a clean disassembly. The usual tricks seemed to work and I was able to unpack the DLL.

The procedure is simple. Open the DLL in OllyDbg. Search for the PUSHAD instruction (this instruction stores all the registers on the top of the stack) and set a breakpoint (F2 key in OllyDbg) on that instruction.

Press F9 to continue the debugging. Press F8 to execute the instruction, and then set a hardware breakpoint on the top of the stack in the Dump Window as shown in the image. You can do this easily by right clicking on the ESP register and clicking on “Follow in Dump”.
Once you reach the POPAD instruction or the hardware breakpoint is activated, this shows that the registers that were saved on the stack are now going to be restored in the respective registers. This indicates that the program has now finished extracting itself and is ready to execute the instructions.
I used OllyDump to dump out the contents of this DLL and then used LordPE to repair the import table. This process, however, needs more work due to the nature of the automated import address table repairing as some things can be missed.
Once this repairing was finished, I opened the file in IDA Pro to disassemble the unpacked DLL. This did give me a lot of information about this DLL, however, I’m still in the process of completing a good disassembly of this DLL.
As for now, I can say that this DLL installed a bunch of spyware CLSIDs into the system.
Some of the CLSIDs (out of the 45 that it uses) by this malware are listed below:

{CF46BFB3-2ACC-441b-B82B-36B9562C7FF1}
{67C55A8D-E808-4caa-9EA7-F77102DE0BB6}
{1557B435-8242-4686-9AA3-9265BF7525A4}
{55DB983C-BDBF-426f-86F0-187B02DDA39B}
{A24B57F8-505D-4fc5-9960-740E304D1ABA}
{4B646AFB-9341-4330-8FD1-C32485AEE619}
{CD3447D4-CA39-4377-8084-30E86331D74C}
{DEBEB52F-CFA6-4647-971F-3EDB75B63AFA}
{8F2183B9-F4DB-4913-8F82-6F9CC42E4CF8}
{92A444D2-F945-4dd9-89A1-896A6C2D8D22}
{1F6581D5-AA53-4b73-A6F9-41420C6B61F1}
{1126271C-A8C3-438c-B951-7C94B453B16B}
{938A8A03-A938-4019-B764-03FF8D167D79}
{44218730-94E0-4b24-BBF0-C3D8B2BCE2C3}

This DLL also seemed to communicate to :

89.188.16.10
89.188.16.16
65.243.103.56
65.243.103.60
65.243.103.62

Whatever you do to these servers is upto you. Some google searches allude that this is a “Vundo infection”. I’m also not sure what solutions people are posting to this problem but I’d not feel safe if this malware was on my computer and I’d definitely format my Windows install, patch it and change my passwords! I’m not completely dne with the disassembly and reversing of this malware yet, but I’m sure I’ll post more when I delve into this disassembled code deeper.