Scan of the Month 26

This month, the mission proposed was to analyze the floppy discovered lying on the ground in Jimmy Jungle's appartment. To manage in our research, we worked on a windows xp box, with a vmware running on it in order to be abble to use the powerful tools linux is providing. We hardly get everything done with UltaEdit32 and hours of reading and documentation on the Internet.

The first step was to read the police report. We didn't learn much from it. Then we download the zip file. We did it from our vmware running a linux RedHat 7.3. The linux box is running a samba server in order to share easily share files between the two OS.

 > wget http://www.honeynet.org/scans/scan26/scan26.zip
 
 > md5sum scan26.zip
 c8e2454b970538de26a0fa887017109b scan26.zip
 > unzip scan26.zip
 
 > md5sum scan26
 e9c7d0c87ab0ecce09bf90362b830a74 scan26
 

We checked that both of the files weren't corrupted with the md5 signature. The signatures are similar, the file are not corrupted. The interest of using the md5 encryption is not a matter of security. Someone who hacked the http server would have modified the md5 signature after altering the original files. The interest is only to be shure that we share the same files. Let's go further...

The next thing to do is know what is containing the scan26 file. Let's use the file tool under linux:

 > file scan26
 scan26: x86 boot sector
 

The file seemed to be a image file, we tried to mount it on the system:

 > mkdir mounted
 > mount -o loop ./scan26 ./mounted
 > cd mounted
 > ls -al
 

The directory seemed to be empty... So we use the df command in the directory containing the scan26 file. The file size was 1423 ko and the file was correctly mounted on the mouted directory. From here, we skipped to the XP box and decided to dissect the file with an hex editor. We used UltraEdit.

We understood that there were no entry in the root directory (which by the way was said in the Bonus Question, but unfortunately, we didn't take care of it first. How did we understood it. First we opened the scan26 file with UltraEdit:

The format partition is FAT12. As we read some of the correction of the scan of the month 24, we learnt a bit more about FAT12:

Every sector is composed of 512 bytes. So if we want to check what is inside the root directory, we had to go to the offset 19 * 512 = 16896 = 0x2600:

No more doubt on the subject, the root directory is empty. If we want to get the file, we'll have to deep directly into the bytes to find it by ourself. So we tried first to use the binText to see if there were any interesting information in the image (this operation could be done under a linux box to using the tool strings):

We discovered an address and a password: help. There was probably a zip file hide somewhere in the bytes. The next step was to try to identify if they were files hidden there and exctract them from the image. So we searched about magic file number on the Internet. Those magic number are in fact a combination of bytes coding to start a type of file (for more inforamtion, check this page out: File magic numbers). So if we managed to find those magic file numbers, we would manage to extract the files from the image. Here is a table containing the magic file numbers we identified:

The problem was that we did know how to find the beginning of a lot of different files, but we didn't know how to find the end. So, we edited some of them and tried to find what. Here is a table containing our results:

It seemed that every JPEG file ended with FF D9. But concerning BMP and BZ files, we didn't find out a motif that could code for the end of the file. We thougth that the size of the file is probably contained in the header of the file or only in the root directory, but we didn't search further. So we began looking after file in the disk image. The first we found was a JPEG one at the offset: 0x 4200h(to do that, we simply uesd UltraEdit)

We saved the bytes we extracted from the image and named it as a .jpg file. Here is what we got:

Then, we looked after other files. We came upon a new image (a Bitmap one this second time). This image is located at the offset: 0xc200h

The problem was to know where was the end of the file? We know that the file is a Bitmap one. In a Bitmap, colors are coded on three octet and that the white color is coded as FFF. So we thought that the file was a map like the precedent one and that thre was a lot of F because the image xas pretty much white. So we stopped just before the F6 succession (but in reality, we could have copied the rest of the file, it didn't change anything. Here is what we got:

As we found a password hidden in the bytes, we were expecting to find a compress file. We found a potentially BZIP file at the offset: 0x98b05.

The problem was that the header of the file seemed to be damaged. We didn't manage in any way to recover the bzip file. We came back on our linux box and try to use the bunzip2 and the bzip2recover tools. But it wasn't possible to recover the file. We tried to replace the header of the file with the header of a correct bzip file we got from the Internet. It didn't work... We stopped the forensic analysis here... There is a life outside too!

We would like to thank Digital Forensic Research Workshop for giving us the possibility to do this challenge. you gave us hard time but it was pleasant to search for the solution. Too bad we didn't manage to find out the compress file (if it is really a compress file). We are defenetely looking forwart to read report of other team to understand where we failed.