Dissecting the GoDaddy email notifier - Part 4

Ok, this is hopefully the last part of my Dissecting series for the email notifier. I last left you with the fact that I had reverse engineered the encryption and decryption algorithm. I simply poked around the calls to the registry key write function calls and found the encryption and decryption routines. I will list them here:

004046D7  /$  55            PUSH EBP               ;  Main Encrypter
004046D8  |.  8BEC          MOV EBP,ESP
004046DA  |.  51            PUSH ECX
004046DB  |.  51            PUSH ECX
004046DC  |.  837E 14 00    CMP DWORD PTR DS:[ESI+14],0
004046E0  |.  8BC6          MOV EAX,ESI
004046E2  |.  0F84 CC000000 JE 004047B4
004046E8  |.  53            PUSH EBX
004046E9  |.  8B5E 14       MOV EBX,DWORD PTR DS:[ESI+14]
004046EC  |.  895D FC       MOV DWORD PTR SS:[EBP-4],EBX
004046EF  |.  57            PUSH EDI
004046F0  |.  4B            DEC EBX
004046F1  |.  8BFB          MOV EDI,EBX
004046F3  |.  E8 A0010000   CALL 00404898
004046F8  |.  0FB608        MOVZX ECX,BYTE PTR DS:[EAX]
004046FB  |.  8B45 FC       MOV EAX,DWORD PTR SS:[EBP-4]
004046FE  |.  6A 05         PUSH 5
00404700  |.  33D2          XOR EDX,EDX
00404702  |.  5F            POP EDI
00404703  |.  F7F7          DIV EDI
00404705  |.  8BFB          MOV EDI,EBX
00404707  |.  C1E2 08       SHL EDX,8
0040470A  |.  66:0FB68411 4>MOVZX AX,BYTE PTR DS:[EAX+ECX+427F48]
00404713  |.  0FB7C0        MOVZX EAX,AX
00404716  |.  8945 FC       MOV DWORD PTR SS:[EBP-4],EAX
00404719  |.  8BC6          MOV EAX,ESI
0040471B  |.  E8 78010000   CALL 00404898
00404720  |.  66:8B00       MOV AX,WORD PTR DS:[EAX]
00404723  |.  66:25 00FF    AND AX,0FF00
00404727  |.  66:0B45 FC    OR AX,WORD PTR SS:[EBP-4]
0040472B  |.  0FB7C0        MOVZX EAX,AX
0040472E  |.  8945 FC       MOV DWORD PTR SS:[EBP-4],EAX
00404731  |.  8BC6          MOV EAX,ESI
00404733  |.  E8 60010000   CALL 00404898
00404738  |.  66:8B4D FC    MOV CX,WORD PTR SS:[EBP-4]
0040473C  |.  66:8908       MOV WORD PTR DS:[EAX],CX
0040473F  |.  8BC6          MOV EAX,ESI
00404741  |.  E8 52010000   CALL 00404898
00404746  |.  0FB700        MOVZX EAX,WORD PTR DS:[EAX]
00404749  |.  6A 05         PUSH 5
0040474B  |.  99            CDQ
0040474C  |.  59            POP ECX
0040474D  |.  F7F9          IDIV ECX
0040474F  |.  33FF          XOR EDI,EDI
00404751  |.  85DB          TEST EBX,EBX
00404753  |.  8955 FC       MOV DWORD PTR SS:[EBP-4],EDX
00404756  |.  76 58         JBE SHORT 004047B0
00404758  |>  8BC6          /MOV EAX,ESI
0040475A  |.  E8 39010000   |CALL 00404898
0040475F  |.  0FB600        |MOVZX EAX,BYTE PTR DS:[EAX]
00404762  |.  8B4D FC       |MOV ECX,DWORD PTR SS:[EBP-4]
00404765  |.  C1E1 08       |SHL ECX,8
00404768  |.  66:0FB68408 4>|MOVZX AX,BYTE PTR DS:[EAX+ECX427F48]
00404771  |.  0FB7C0        |MOVZX EAX,AX
00404774  |.  8945 F8       |MOV DWORD PTR SS:[EBP-8],EAX
00404777  |.  8BC6          |MOV EAX,ESI
00404779  |.  E8 1A010000   |CALL 00404898
0040477E  |.  66:8B00       |MOV AX,WORD PTR DS:[EAX]
00404781  |.  66:25 00FF    |AND AX,0FF00
00404785  |.  66:0B45 F8    |OR AX,WORD PTR SS:[EBP-8]
00404789  |.  0FB7C0        |MOVZX EAX,AX
0040478C  |.  8945 F8       |MOV DWORD PTR SS:[EBP-8],EAX
0040478F  |.  8BC6          |MOV EAX,ESI
00404791  |.  E8 02010000   |CALL 00404898
00404796  |.  66:8B4D F8    |MOV CX,WORD PTR SS:[EBP-8]
0040479A  |.  66:8908       |MOV WORD PTR DS:[EAX],CX
0040479D  |.  8B45 FC       |MOV EAX,DWORD PTR SS:[EBP-4]
004047A0  |.  47            |INC EDI
004047A1  |.  6A 05         |PUSH 5
004047A3  |.  40            |INC EAX
004047A4  |.  33D2          |XOR EDX,EDX
004047A6  |.  59            |POP ECX
004047A7  |.  F7F1          |DIV ECX
004047A9  |.  3BFB          |CMP EDI,EBX
004047AB  |.  8955 FC       |MOV DWORD PTR SS:[EBP-4],EDX
004047AE  |.^ 72 A8         \JB SHORT 00404758
004047B0  |>  5F            POP EDI
004047B1  |.  8BC6          MOV EAX,ESI
004047B3  |.  5B            POP EBX
004047B4  |>  C9            LEAVE
004047B5  \.  C3            RET

The code above is for the Encrypter and the code below is the Decrypter:

004047B6  /$  55            PUSH EBP                 ;  Main Decrypter
004047B7  |.  8BEC          MOV EBP,ESP
004047B9  |.  51            PUSH ECX
004047BA  |.  51            PUSH ECX
004047BB  |.  53            PUSH EBX
004047BC  |.  8B5E 14       MOV EBX,DWORD PTR DS:[ESI+14]
004047BF  |.  85DB          TEST EBX,EBX
004047C1  |.  8BC6          MOV EAX,ESI
004047C3  |.  0F84 CC000000 JE 00404895
004047C9  |.  57            PUSH EDI
004047CA  |.  4B            DEC EBX
004047CB  |.  8BFB          MOV EDI,EBX
004047CD  |.  E8 C6000000   CALL 00404898
004047D2  |.  0FB700        MOVZX EAX,WORD PTR DS:[EAX]
004047D5  |.  6A 05         PUSH 5
004047D7  |.  99            CDQ
004047D8  |.  59            POP ECX
004047D9  |.  F7F9          IDIV ECX
004047DB  |.  33FF          XOR EDI,EDI
004047DD  |.  85DB          TEST EBX,EBX
004047DF  |.  8955 FC       MOV DWORD PTR SS:[EBP-4],EDX
004047E2  |.  76 58         JBE SHORT 0040483C
004047E4  |>  8BC6          /MOV EAX,ESI
004047E6  |.  E8 AD000000   |CALL 00404898
004047EB  |.  0FB600        |MOVZX EAX,BYTE PTR DS:[EAX]
004047EE  |.  8B4D FC       |MOV ECX,DWORD PTR SS:[EBP-4]
004047F1  |.  C1E1 08       |SHL ECX,8
004047F4  |.  66:0FB68408 4>|MOVZX AX,BYTE PTR DS:[EAX+ECX+428448]
004047FD  |.  0FB7C0        |MOVZX EAX,AX
00404800  |.  8945 F8       |MOV DWORD PTR SS:[EBP-8],EAX
00404803  |.  8BC6          |MOV EAX,ESI
00404805  |.  E8 8E000000   |CALL 00404898
0040480A  |.  66:8B00       |MOV AX,WORD PTR DS:[EAX]
0040480D  |.  66:25 00FF    |AND AX,0FF00
00404811  |.  66:0B45 F8    |OR AX,WORD PTR SS:[EBP-8]
00404815  |.  0FB7C0        |MOVZX EAX,AX
00404818  |.  8945 F8       |MOV DWORD PTR SS:[EBP-8],EAX
0040481B  |.  8BC6          |MOV EAX,ESI
0040481D  |.  E8 76000000   |CALL 00404898
00404822  |.  66:8B4D F8    |MOV CX,WORD PTR SS:[EBP-8]
00404826  |.  66:8908       |MOV WORD PTR DS:[EAX],CX
00404829  |.  8B45 FC       |MOV EAX,DWORD PTR SS:[EBP-4]
0040482C  |.  47            |INC EDI
0040482D  |.  6A 05         |PUSH 5
0040482F  |.  40            |INC EAX
00404830  |.  33D2          |XOR EDX,EDX
00404832  |.  59            |POP ECX
00404833  |.  F7F1          |DIV ECX
00404835  |.  3BFB          |CMP EDI,EBX
00404837  |.  8955 FC       |MOV DWORD PTR SS:[EBP-4],EDX
0040483A  |.^ 72 A8         \JB SHORT 004047E4
0040483C  |>  8B46 14       MOV EAX,DWORD PTR DS:[ESI+14]
0040483F  |.  8945 F8       MOV DWORD PTR SS:[EBP-8],EAX
00404842  |.  8BFB          MOV EDI,EBX
00404844  |.  8BC6          MOV EAX,ESI
00404846  |.  E8 4D000000   CALL 00404898
0040484B  |.  0FB608        MOVZX ECX,BYTE PTR DS:[EAX]
0040484E  |.  8B45 F8       MOV EAX,DWORD PTR SS:[EBP-8]
00404851  |.  6A 05         PUSH 5
00404853  |.  33D2          XOR EDX,EDX
00404855  |.  5F            POP EDI
00404856  |.  F7F7          DIV EDI
00404858  |.  8BFB          MOV EDI,EBX
0040485A  |.  C1E2 08       SHL EDX,8
0040485D  |.  66:0FB68411 4>MOVZX AX,BYTE PTR DS:[ECX+EDX+428448]
00404866  |.  0FB7C0        MOVZX EAX,AX
00404869  |.  8945 F8       MOV DWORD PTR SS:[EBP-8],EAX
0040486C  |.  8BC6          MOV EAX,ESI
0040486E  |.  E8 25000000   CALL 00404898
00404873  |.  66:8B00       MOV AX,WORD PTR DS:[EAX]
00404876  |.  66:25 00FF    AND AX,0FF00
0040487A  |.  66:0B45 F8    OR AX,WORD PTR SS:[EBP-8]
0040487E  |.  0FB7C0        MOVZX EAX,AX
00404881  |.  8945 F8       MOV DWORD PTR SS:[EBP-8],EAX
00404884  |.  8BC6          MOV EAX,ESI
00404886  |.  E8 0D000000   CALL 00404898
0040488B  |.  66:8B4D F8    MOV CX,WORD PTR SS:[EBP-8]
0040488F  |.  66:8908       MOV WORD PTR DS:[EAX],CX
00404892  |.  8BC6          MOV EAX,ESI
00404894  |.  5F            POP EDI
00404895  |>  5B            POP EBX
00404896  |.  C9            LEAVE
00404897  \.  C3            RET

I will leave you with the python source code for the encryption and decryption routines so that you can look at the algorithm and get a feel for what was going on. You will need the static data which can be found in the .rdata section. This is the cipher text that is looked up during the encryption and decryption phase. I have included it in the tool as a separate file.
I may decide to start developing a Linux variant for checking my GoDaddy mail, but don’t hold your breath. Mail me any questions you may have. If you’re interested.

The tool can be found here.

Dissecting the GoDaddy email notifier - Part 3

It’s been sometime since I made a post and that kinda sucks. I’ve been a bit swamped with work and have not had any real time to do my own stuff. Presently out in Cairo. Pyramids are phun.

You must be wondering why the hell I chose OllyDbg to make a simple hex edit in the previous post. The truth is, I was using it to try and study at exactly what point the SSL protocol is chosen and I found it at 0×414356.



By changing the CMP operation as in the picture above with 0×2E instead of 0×00, I can get the client to select plain old HTTP to speak to the main server. This is good, because I can now look at all the Web Service calls it makes and hopefully try to write a Linux version.
One other reason I chose OllyDbg is to study what the client actually does. My next quest is to study where my credentials are stored. Since this is Windows, I figure the first place to look would be the registry. By sniffing around the “string references” of the client, I did notice a specific registry key which is referenced: “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”
 
Examining this registry key with regedit, I see the following:



That looks interesting. If I count the characters, it equates to the exact number for both my email address and password*. This means that their encryption algorithm generates fixed length cipher text. This most likely means that they’re using a substitution algorithm. Tsk, tsk, tsk. Substitution algorithms rely on some form of calculation (if any) and lookup in order to generate cipher text. Again, by looking at the encrypted strings, it is possible to determine the fact that a calculation involving the string length is also done. How do I deduce this? By looking at the last two characters in my email address (d1). They are both “qq” for “om” the last two letters in “.com”. This means that both “o” and “m” are equal to “q”. Not possible in direct lookups with calculation.

Another good thing is the fact that I know the credentials are stored in the registry. This shortens my hunt significantly because I only have to trace any specific registry calls to find out where the Encryption/Decryption algorithms are lurking. If I trace any references or calls to the specific registry key, then I will most likely find where the algorithms exist.

Using the “search for all string references” in Olly, I try to pull up all the calls to “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”. I end up with this list:



The column “Called from” is what I’m interested in. This list contains all the addresses where the call to this registry key is made. I now have to follow each one and see if there is a “RegistrySetValue” call made. I look through each call one by one until I stumble upon this one:



It’s interesting because of the entry I have highlighted. This Unicode “d1” that’s on the stack is the registry entry for my email address. I follow this one to see where it goes and wind up discovering both the encryption and decryption algorithm. I will list them in the next part of this series. I think this post is dragging on long enough and I think it is about time I wrap it up. I will do just that in the next post and save everyone a lot of misery. I have successfully reversed the encryption/decryption algorithm and will post the python source code in my next post.

Dissecting the GoDaddy email notifier - Part 2

Welcome back. In our last installment, we had just figured out that the GoDaddy Email notifier uses SSL to communicate with the server. Today, I will look at ways of trying to bypass this and sniff traffic in order to figure out how the client communicates with the server.

Like I described in my previous post, I hooked up an stunnel/replug proxy chain to try and decrypt traffic, sniff it, and encrypt the traffic back on its way to the server. I first setup stunnel in both daemon and client modes. Here is a description of each:

Daemon mode. This instance of stunnel will listen on localhost:443 and forward traffic to localhost:8888 all over SSL.

sheran@azazel:~$ sudo stunnel -d 443 -r localhost:8888

Client mode. This instance will listen in non-SSL mode on port 8889 and re-establish the connection in SSL mode to the server. (When sniffing traffic, the DNS lookup for the notifier was noted. It looks up email.secureserver.net)

sheran@azazel:~$ sudo stunnel -c -d 8889 -r email.secureserver.net:443

How do we plug the hole in the middle? Simple, use replug found in BlackBag. Here's how:

sheran@azazel:~$ bkb replug localhost:8889@8888

This will start replug and listen on localhost:8888. Whatever it listens to on this port it will forward down to localhost:8889. The way traffic flows will be similar to this:

Client ---> localhost:443 (stunnel) ---> localhost:8888 (replug) ---> localhost:8889 (stunnel) ---> email.secureserver.net:443

Now for the client to think it's talking to an authentic server, I need to replicate the server certificate as well. This is not going to be an easy task since I don't own a CA; especially not the one that issues GoDaddy's certificates. So I do the next best thing and create a self-signed certificate almost identical to the GoDaddy certificate (weirder things have worked for me in the past). No dice. The client notifier program refuses to negotiate SSL with my first instance of stunnel. Shit.

Since this is not going to be as simple as I thought, I will have to resort to the next best thing: disassemble the notifier executable and try to patch it to talk non-SSL. So I fire up my favorite disassembler OllyDbg and try to locate any strings in the executable to give me a clue as to where the connection is made.

Well, here's something. Looking through strings (Right-click->Search for->All Referenced Strings) gives me several entries to a string reference called "http://" and "https://". I wonder if changing "https://" to "http://" will have any effect. Let's see:



In the "Strings window", right click and do a "Follow in Disassembler"; then when you're in the disassembler window, right click on the line with the "https://" and do a "Follow in Dump"->"Immediate Constant"



This should then bring the string up on the lower left window where you can change the "https://" entry to "http://". Then, right-click, choose "Copy to Executable", right-click on the window that opens up and select "Save File". Save it as another name and try it out for yourself. Now you can see all the traffic flowing between the client and server on Wireshark.

At this point, you will notice that GoDaddy's email notifier uses SOAP to transfer XML messages to and from the server. The URL is https://email.secureserver.net/soap/public.php and a listing of available operations and WSDL file.



I personally felt that it was easier to get the client to do various operations and sniff the traffic to get an idea of how things are implemented. I think I'm well on my way to writing my linux variant of the notifier.

Next time, I'll look into how the credentials are stored and if they are encrypted and if this is a trivial encryption to break.

Dissecting the GoDaddy email notifier - Part 1

I host at GoDaddy. Yes, yes, I know there have been horror stories and there is even a site that lists incidents involving the shutting down of some sites with little or no warning; but they're dirt cheap and I'm poor so...

Anyway, GoDaddy has this email notifier which will check your mailbox to see if you've got new mail without logging into the horribly slow Web Based email client. It's fairly convenient, but only installs on Windows. I wanted to do two things with this notifier:

1.See how safely it actually kept my credentials.
2. See how it communicated with the server and if it was secure as well.

I then wanted to see how easy it was to have a version written for Linux so that I can use it on my Ubuntu box.

I don't know how many of you have nodded off by now and how many of you wondering why I even bother. The truth is, its important to me, its my blog and it will also hopefully enlighten you on how you can go about conducting an analysis on a network application. In this regard, this is what I will be doing with this application:

1. Examining the communication between notifier and server
2. Identifying how the credentials are stored and if they are encrypted
3. Attempting to decrypt the credentials if it proves easy to do so
4. Writing my own Linux version of the tool. Either a Gnome Applet or Firefox Extension (whichever is easier)

Since this will be an ongoing saga of sorts, I will break it down into several posts for managability's sake. It also gives me time to conduct my research and publish the findings without waiting till the end.

Right, let's begin...

As with all applications, I downloaded and installed the tool. The notifier is in the form of a small envelope that sits in your taskbar . You can configure it to check up to 5 email addresses and specify such settings as duration between email checks, how long to display messages for and how many new messages to display in a small popup window. All fairly simple.

My first order of business is to check how the tool communicates with the server. So I fire up Wireshark and sniff a few packets. Immediately, it is apparent that the tool uses SSL. Points for GoDaddy. No casual sniffing can be done. This puts a dent in my plans of attempting to write a Linux version. How can I write one, when I don't know what it says to the server? I can always try an MITM SSL sniffing exercise. The idea for this one is as simple as this:



This can all be achieved by using stunnel and the replug tool found in Matasano's BlackBag. As a matter of fact, Dave Goldsmith has an article on the Matasano Blog about how he did this for a Java Application. In his case, it was a fairly easy workaround to bypass the certificate validation. I don't know how easy it will be for this specific application. But I'm getting ahead of myself. Join me for the next post where I setup the stunnel/replug proxy chain, discover if proper certificate validation is done and look for a way around the SSL communication.

Memory Card Forensics

So I'm looking into forensics and I remember reading about how some guys would buy used hard drives belonging to hospitals or banks and do some recovery on the data and come up with some interesting stuff and I think, why not try it on Memory Cards?

Sure, it's not an original idea, but a quick look on one of the local online auction sites says that for a relatively small amount, I can buy someone's memory card and potentially have access to a fair amount of his personal data.

Depending on where the card was used, I'm looking at quite a number of possibilities relating to information that I can dig up. Contact details, people he's called, photos and videos he's taken (could be some raunchy stuff on there as well :D ) and literally anything he's stored on his card. I'm betting on the fact that Mr. Average Joe will not do a DoD wipe on his SD card before deciding to sell it.

But to test this theory, I thought I'd try out one of my own memory cards. If you look at my post for "Installing CarvFS on Ubuntu 7.04", you will get an idea of in-place carving. I will adopt this technique for sniffing through my own (and eventually others) memory cards. So here goes:

I have this USB Disk which is 64Mb in size and I think it will be perfect for this demo. I first mount it and take a look at the contents:


sheran@azazel:~/Personal/research$ sudo mount /dev/sdb1 /media/usbdisk
sheran@azazel:~/Personal/research$ ls -alrt /media/usbdisk
total 17
drwxr-xr-x 8 root root 4096 2007-06-19 12:21 ..
drwx------ 2 root root 12288 2007-06-19 12:24 lost+found
drwxr-xr-x 3 sheran sheran 1024 2007-06-19 12:24 .
sheran@azazel:~/Personal/research$ df -kh /media/usbdisk
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 61M 1.3M 56M 3% /media/usbdisk
sheran@azazel:~/Personal/research$


That's pretty much the disk. I had run cfdisk and mke2fs previously on the Windows formatted USB Disk. I now image it with 'ewfacquire' which you don't get to see, but I end up with the file usbdisk.E01. I can now mount this file using CarvFS.


sheran@azazel:~/Personal/research$ sudo -s
root@azazel:~/Personal/research# carvfs /mnt/carvfs/ ewf usbdisk.E01
/mnt/carvfs//f183a8e2b50834552f9302b08251d4db
root@azazel:~/Personal/research# cd /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/
root@azazel:/mnt/carvfs/f183a8e2b50834552f9302b08251d4db# ls -alrt
total 63616
-rw-rw-rw- 1 root root 2545 1970-01-01 04:00 README
-rw------- 1 root root 85 1970-01-01 04:00 ocfa.missing
-r--r--r-- 1 root root 65135616 1970-01-01 04:00 CarvFS.crv
d--x--x--x 3 root root 0 1970-01-01 04:00 CarvFS
drwxr-xr-x 3 root root 0 1970-01-01 04:00 .
drwxr-xr-x 3 root root 4096 2007-06-19 13:28 ..
root@azazel:/mnt/carvfs/f183a8e2b50834552f9302b08251d4db#


Now I run 'scalpel' in preview mode with the configuration file set to grab graphic files:


root@azazel:~/Personal/research# scalpel -p -c ./scalpel_gfx.conf /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv
Scalpel version 1.60
Written by Golden G. Richard III, based on Foremost 0.69.


Opening target "/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv"


Image file pass 1/2.
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 16.1% 10.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 32.2% 20.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 48.3% 30.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 64.4% 40.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 80.5% 50.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 96.6% 60.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 100.0% 62.1 MB 00:00 ETAAllocating work queues...
Work queues allocation complete. Building carve lists...
Carve lists built. Workload:
gif with header "\x47\x49\x46\x38\x37\x61" and footer "\x00\x3b" --> 0 files
gif with header "\x47\x49\x46\x38\x39\x61" and footer "\x00\x3b" --> 146 files
jpg with header "\xff\xd8\xff\xe0\x00\x10" and footer "\xff\xd9" --> 22 files
png with header "\x50\x4e\x47\x3f" and footer "\xff\xfc\xfd\xfe" --> 0 files
** PREVIEW MODE: GENERATING AUDIT LOG ONLY **
** NO CARVED FILES WILL BE WRITTEN **
Carving files from image.
Image file pass 2/2.
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 16.1% 10.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 48.3% 30.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 96.6% 60.0 MB 00/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 100.0% 62.1 MB 00:00 ETAProcessing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 168, elapsed = 3 seconds.
root@azazel:~/Personal/research#


And I find 146 GIF files and 22 JPGs. Usually, scalpel can be used to extract these files and place them in another directory. The beauty of CarvFS is in the fact that you can add symlinks to the CarvFS image and these symlinks directly refer to offsets within the 'usbdisk.E01' image. CarvFS comes with a tool called 'scalpelcp' which does just this. I had to edit the script so that it works fine, because there was a problem with the "$basepath" variable. But anyway, here goes:


root@azazel:~/Personal/research# scalpelcp
Usage: scalpelcp <outputdir> <basepath>


this tool is meant to be used in conjunction with scalpel (>= 1.6)
run in preview mode (that is using the -p option that scalpel provides)
on carvpath pseudo files.
Scalpelcp will parse the audit.txt file and populate the scalpel output
directory with symlinks to valid sub-carvpaths extracted from the audit file


root@azazel:~/Personal/research# scalpelcp ./scalpel-output/ /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/
Target=/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS
symlinked 168 filenames to zero-storage carvpaths
root@azazel:~/Personal/research# cd scalpel-output/


oot@azazel:~/Personal/research/scalpel-output# ls
00000000.gif 00000034.gif 00000068.gif 00000102.gif 00000136.gif
00000001.gif 00000035.gif 00000069.gif 00000103.gif 00000137.gif
00000002.gif 00000036.gif 00000070.gif 00000104.gif 00000138.gif
00000003.gif 00000037.gif 00000071.gif 00000105.gif 00000139.gif
00000004.gif 00000038.gif 00000072.gif 00000106.gif 00000140.gif
00000005.gif 00000039.gif 00000073.gif 00000107.gif 00000141.gif
00000006.gif 00000040.gif 00000074.gif 00000108.gif 00000142.gif
00000007.gif 00000041.gif 00000075.gif 00000109.gif 00000143.gif
00000008.gif 00000042.gif 00000076.gif 00000110.gif 00000144.gif
00000009.gif 00000043.gif 00000077.gif 00000111.gif 00000145.gif
00000010.gif 00000044.gif 00000078.gif 00000112.gif 00000146.jpg
00000011.gif 00000045.gif 00000079.gif 00000113.gif 00000147.jpg
00000012.gif 00000046.gif 00000080.gif 00000114.gif 00000148.jpg
00000013.gif 00000047.gif 00000081.gif 00000115.gif 00000149.jpg
00000014.gif 00000048.gif 00000082.gif 00000116.gif 00000150.jpg
00000015.gif 00000049.gif 00000083.gif 00000117.gif 00000151.jpg
00000016.gif 00000050.gif 00000084.gif 00000118.gif 00000152.jpg
00000017.gif 00000051.gif 00000085.gif 00000119.gif 00000153.jpg
00000018.gif 00000052.gif 00000086.gif 00000120.gif 00000154.jpg
00000019.gif 00000053.gif 00000087.gif 00000121.gif 00000155.jpg
00000020.gif 00000054.gif 00000088.gif 00000122.gif 00000156.jpg
00000021.gif 00000055.gif 00000089.gif 00000123.gif 00000157.jpg
00000022.gif 00000056.gif 00000090.gif 00000124.gif 00000158.jpg
00000023.gif 00000057.gif 00000091.gif 00000125.gif 00000159.jpg
00000024.gif 00000058.gif 00000092.gif 00000126.gif 00000160.jpg
00000025.gif 00000059.gif 00000093.gif 00000127.gif 00000161.jpg
00000026.gif 00000060.gif 00000094.gif 00000128.gif 00000162.jpg
00000027.gif 00000061.gif 00000095.gif 00000129.gif 00000163.jpg
00000028.gif 00000062.gif 00000096.gif 00000130.gif 00000164.jpg
00000029.gif 00000063.gif 00000097.gif 00000131.gif 00000165.jpg
00000030.gif 00000064.gif 00000098.gif 00000132.gif 00000166.jpg
00000031.gif 00000065.gif 00000099.gif 00000133.gif 00000167.jpg
00000032.gif 00000066.gif 00000100.gif 00000134.gif audit.txt
00000033.gif 00000067.gif 00000101.gif 00000135.gif
root@azazel:~/Personal/research/scalpel-output#




And here are all my symlinked files. If you do a long listing you can see how the files are actually symlinked:


root@azazel:~/Personal/research/scalpel-output# ls -alrt | tail -n 5
lrwxrwxrwx 1 root root 67 2007-06-19 13:44 00000003.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/1206784:269.crv
lrwxrwxrwx 1 root root 67 2007-06-19 13:44 00000002.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/1205760:200.crv
lrwxrwxrwx 1 root root 68 2007-06-19 13:44 00000001.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/1203712:1231.crv
lrwxrwxrwx 1 root root 66 2007-06-19 13:44 00000000.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/1203200:50.crv
drwxr-xr-- 2 root root 4096 2007-06-19 13:44 .
root@azazel:~/Personal/research/scalpel-output#


Lastly, all that's left is to start up an image viewer program or plain old nautilus and see what the directory holds:



That's it for now. I'm off to buy some more memory cards. Be very careful if you know me and hear me ask you innocently, "Hey, can I borrow your camera?"

Installing CarvFS on Ubuntu 7.04

In place carving can save you a fair amount of space. There was a paper written about it and the Dutch National Police Agency also wrote a tool called CarvFS that does exactly this. What CarvFS allows you to do is mount an EWF image or raw 'dd' image and reference blocks of data by using a specific directory listing format. At it's simplest level, you could run 'strings' on a set of 1024 bytes beginning at the first byte by doing this:

root@azazel:/mnt/carvfs/524a4efcaa84cf7391705b2b292644a6# strings CarvFS/0:1024.crv
NO NAME FAT16
root@azazel:/mnt/carvfs/524a4efcaa84cf7391705b2b292644a6#


I'll leave you to work out why this is useful; alternatively you can also read my "Memory Card Forensics" post. Here is how I installed CarvFS:

Downloaded the source packages for CarvFS, libcarvpath, libewf and fuse. They can be found here:

CarvFS 0.2.1
libcarvpath 0.1.4
libewf-beta-20061223
fuse 2.6.5

There's no specific order, but make sure that libewf, fuse and libcarvpath are installed before CarvFS.

I believe fuse should already be running as a kernel module in 7.04, so the kernel module will not be built.

Then, once you install CarvFS, you're pretty much ready to go. I had one problem when I ran carvfs I received a library not found error for libfuse.so.2. The library itself was in /usr/local/lib, but there was no entry in /etc/ld.so.conf. So I added the entry and ran ldconfig and all was well.

How will you test CarvFS? First, you will need either a raw 'dd' image or an EWF image. libewf will install a tool called 'ewfacquire' which you can use to make EWF images. Here is an excerpt of one of my sessions:


sheran@azazel:~/Personal/research$ ewfacquire /dev/sdb1
ewfacquire 20061223 (libewf 20061223, zlib 1.2.3, libcrypto 0.9.8)
Information about acquiry required, please provide the necessary input
Image path and filename without extension: usbdisk
Case number: 1923
Description: USB Disk
Evidence number: 12
Examiner name: Sheran
Notes: 64Mb USB Disk used for Forensics tests
Media type (fixed, removable) [fixed]: removable
Use compression (none, fast, best) [none]: best
Use EWF file format (smart, ftk, encase1, encase2, encase3, encase4, encase5, linen5, ewfx) [encase5]:
Start to acquire at offset (0 >= value >= 65135616) [0]:
Amount of bytes to acquire (0 >= value >= 65135616) [65135616]:
Evidence segment file size in kbytes (2^10) (1440 >= value >= 2097152) [665600]:
The amount of sectors to read at once (64, 128, 256, 512, 1024, 2048, 4096) [64]: 512
The amount of sectors to be used as error granularity (1 >= value >= 512) [64]:
The amount of retries when a read error occurs (0 >= value >= 255) [2]:
Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [yes]:
...
...
...
...

It goes on to acquire an EWF image of my 64Mb USB Disk.

The next step would be to mount it. Create a mount point for it first. I use /mnt/carvfs.


sheran@azazel:~/Personal/research$ sudo carvfs /mnt/carvfs ewf usbdisk.E01 /mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80
sheran@azazel:~/Personal/research$


Now that the image is mounted, switch to the root prompt (I wasted some time on this one) and then go into the mounted image:


root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80# ls -alrt
total 63617
-rw-rw-rw- 1 root root 2545 1970-01-01 04:00 README
-r--r--r-- 1 root root 1397 1970-01-01 04:00 ocfa.xml
-r--r--r-- 1 root root 65135616 1970-01-01 04:00 CarvFS.crv
d--x--x--x 3 root root 0 1970-01-01 04:00 CarvFS
drwxr-xr-x 3 root root 0 1970-01-01 04:00 .
drwxr-xr-x 5 root root 4096 2007-06-18 17:43 ..

I then ran a strings on the first 512 bytes like so:

root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80# strings CarvFS/0:512.crv
MSDOS5.0
NO NAME FAT32 3
f`f;F
fXfXfXfX
NTLDR
Remove disks or other media.
Disk error
Press any key to restart
root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80#

That's about it.

I know my instructions probably suck big time, but I didn't want to waste too much time in actually telling you how to do some of the other things. Anyway, if you're sniffing around CarvFS you probably know how to do most of the stuff anyway. If, however, you still want to know stepwise details, drop me a comment or mail me.

Till then.

Teh First Post

Welcome to the Chirsashi Security blog! As is evident, this is teh first post. Setting up Wordpress and all that sort of thing, nothing much to write in this one.