Scan 26 - February 2003

Author: Diego Gonzįlez Gómez
dggomez@arrakis.es

Table of contents:


Analysis:

After downloaded the scan26.zip file, I have checked the md5 sum for the two files, scan26 and scan26.zip:

>md5sum -c scan26.md5
scan26: OK
scan26.zip: OK

Contents of scan26.md5:
e9c7d0c87ab0ecce09bf90362b830a74 *scan26
c8e2454b970538de26a0fa887017109b *scan26.zip

I extracted of scan26 binary from scan26.zip and I used a hexadecimal editor (Ultraedit32) to open scan26 file. With the help of a FAT12 reference document like the DCube Software one [1], the header of the file reveals this information:

00000000h: EB 3E 90 22 52 56 52 62 49 48 43 00 02 01 01 00 ; ė>"RVRbIHC.....
00000010h: 02 E0 00 40 0B F0 09 00 12 00 02 00 00 00 00 00 ; .ą.@.š..........
00000020h: 00 00 00 00 00 00 29 44 06 DA 16 4E 4F 20 4E 41 ; ......)D.Ś.NO NA
00000030h: 4D 45 20 20 20 20 46 41 54 31 32 20 20 20 F1 7D ; ME    FAT12   ń}

OEM Version: "RVRbIHC
Bytes Per Sector: 512
Sectors Per Cluster: 1
Number of FAT copies: 2
Total Sectors: 2.880
Volume Serial #: 16DA-0644
Volume Name: NO NAME
File System: FAT12

The OEM version  is not normal, but I do not know the reason for which somebody has changed it.

When I looked to the first copy of the FAT, I verified that there are not entries:

00000200h: F0 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 ; š’’.............
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000220h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000230h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000240h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000250h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00000260h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

The same thing occurs with the second copy of the FAT:

00001400h: F0 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 ; š’’.............
00001410h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00001420h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00001430h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00001440h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00001450h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00001460h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

The root directoy does not have entries either:

00002600h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002610h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002620h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002630h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002640h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002650h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00002660h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................

At the beginning of the data space (4200h) I found signs of data. In this case I identified the header of a possible JPEG file. I searched the web for the JPEG header information and I found a document used by Dennis Ruck in sotm24, written by James R. Weeks.[2]

000041e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000041f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
00004200h: FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 48 ; ’Ų’ą..JFIF.....H
00004210h: 00 48 00 00 FF FE 00 4C 11 53 6E 55 47 B3 2D 44 ; .H..’ž.L.SnUG³-D
00004220h: 35 D2 23 66 6B 1D BD 76 3C 89 68 69 D4 17 60 E8 ; 5Ņ#fk.½v<‰hiŌ.`č

The JPEG picture finishes at the End of Image (EOI) marker (FF D9). After it, there are a little area bytes empty. And soon, at c200h address I found the possible header of a BMP file.

0000c140h: 80 88 88 08 88 80 88 88 08 88 80 88 88 08 88 80 ; €ˆˆ.ˆ€ˆˆ.ˆ€ˆˆ.ˆ€
0000c150h: 88 88 08 88 80 88 88 3F FF D9 00 00 00 00 00 00 ; ˆˆ.ˆ€ˆˆ?’Ł......
0000c160h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c170h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c180h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c190h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1a0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1c0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1d0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c1f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
0000c200h: 42 4D 76 CC 11 00 00 00 00 00 36 00 00 00 28 00 ; BMvĢ......6...(.
0000c210h: 00 00 D0 02 00 00 1C 02 00 00 01 00 18 00 00 00 ; ..Š.............
0000c220h: 00 00 40 CC 11 00 00 00 00 00 00 00 00 00 00 00 ; ..@Ģ............
0000c230h: 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF ; ......’’’’’’’’’’
0000c240h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ; ’’’’’’’’’’’’’’’’
0000c250h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ; ’’’’’’’’’’’’’’’’

I marked the end of the BMP file at the dir 128e75h, and extracted the file. After that dir, the disk image is (almost, read below) empty.

00128e40h: FE FF FF FE FE FE FE FF FE FF FF FE FF FF FE FE ; ž’’žžžž’ž’’ž’’žž
00128e50h: FF FF FE FE FE FE FF FF FE FF FE FF FF FF FE FE ; ’’žžžž’’ž’ž’’’žž
00128e60h: FF FE FE FF FE FF FF FF FF FE FF FF FE FF FF FE ; ’žž’ž’’’’ž’’ž’’ž
00128e70h: FF FE FE FE FF FE F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 ; ’žžž’žöööööööööö
00128e80h: F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 ; öööööööööööööööö
00128e90h: F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 ; öööööööööööööööö
00128ea0h: F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 F6 ; öööööööööööööööö

To obtain more information I decided to apply a strings command to the pictures and the image file. The strings command extracts any ASCII information in a file, and in some cases it is very useful.

The pictures have not have value information., but the last two lines of the disk image output are interesting:

pw=help
John Smith's Address: 1212 Main Street, Jones, FL 00001

The second line is the address of John Smith. Excelent.

And the other line is a password, but for what? I think that there is some type of hidden information in the disk image. It is possible that the information has been hidden using some type of steganography techniques.

But before looking for it in the images, I mounted the image in a floppy disk, and I installed some forensic tools.

I used Winimage to mount the disk image in the floppy. After that I used several programs to recover the data. The only program that managed to identify both files (the jpeg and bmp) correctly was an eval version of BadCopy. Some of the other software founded only the jpeg file.

The next step in my forensic analisys was to look for information on steganography. Steganography is the art of concealing the existence of information within seemingly innocuous carriers, like image or audio files for example. Steganography can be viewed as akin to cryptography. There is an important source of information at JJTC [3].

I used file command to verify the format of the pictures.

$ file map1.jpg
map1.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), "SnUG³-D5Ņ#fk½v<‰hiŌ`訤- Y«", 72 x 72
$ file map2.bmp
map2.bmp: PC bitmap data, Windows 3.x format, 720 x 540 x 24

The comment of JPEG picture is a bit strange. I used the header documentation to extract the complete comment text.

00000000h: FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 00 48 ; ’Ų’ą..JFIF.....H
00000010h: 00 48 00 00 FF FE 00 4C 11 53 6E 55 47 B3 2D 44 ; .H..’ž.L.SnUG³-D
00000020h: 35 D2 23 66 6B 1D BD 76 3C 89 68 69 D4 17 60 E8 ; 5Ņ#fk.½v<‰hiŌ.`č
00000030h: A8 A4 2D 09 59 19 AB 28 1A DE 5E 98 60 C2 A5 C3 ; ؤ-.Y.«(.Ž^˜`Ā„Ć
00000040h: A7 AE 24 D0 3D 16 03 47 6A 60 90 DA E1 44 F9 CC ; §®$Š=..Gj`ŚįDłĢ
00000050h: ED B5 71 A0 E7 72 B1 4B D3 D9 1E 92 D7 AE 5F 1E ; ķµq ēr±KÓŁ.’×®_.
00000060h: 00 00 FF FE 1E 61 5B 1E 00 00 CD 1E 4D 86 D2 52 ; ..’ž.a[...Ķ.M†ŅR

I tried to XOR decode it using the password "help" with xor-analyze package [4]. Unfortunately, the out file did not contain anything meaningful.

I installed and used stegdetect 0.4 [5] with map1.jpg.

stegdetect-0.4>stegdetect.exe map1.jpg
map1.jpg : invisible[7771](***)

The output seems to indicate that there are signs the use of Invisible Secrets program [6] in the file. I downloaded an eval copy from the main page, and installed it. After several tries with many encryption algorithms I was not successful deciphering or unhiding any information in the JPEG picture, neither in the BMP one.

 

Questions:

 

Conclusion:

To eliminate information of a floppy disc by formating it with [/q] parameter is not safe. This analysis demonstrates how easy is to recover it using forensic methods and tools. In case of eliminating any sign of information it is necessary to do a complete format to the disc. The world of the steganography is varied and has many possibilities. Each steganography program leaves its own track. To find the suitable program requires the use of a meticulous analysis and specialized tools. On the other hand, the information hidden in carriers, can be encrypted with robust algorithms like AES or Blowfish, doing almost impossible its discovery.

 

References:

[1] DCube Software Technologies. Full Disk Information. Nagpur (India) Last Revised: 15th June 2002 8:05:20. (http://www.funducode.com/freevc/disk/disk1.htm) (local mirror)

[2] James R. Weeks. BioElectroMech. JPEG Header Information. 1998. http://www.obrador.com/essentialjpeg/HeaderInfo.htm

[3] Johnson & Johnson Technology Consultants, LLC. Steganography & Digital Watermarking. http://www.jjtc.com/Steganography/

[4] Thomas Habets. XOR-analyze 0.4. http://www.habets.pp.se/synscan/programs.php?prog=xor-analyze

[5] Niels Provos. Steganography Detection with Stegdetect. 1999-2001. http://www.outguess.org/detection.php

[6] NEO Byte Solutions. Invisible Secrets 2002. 1999-2003. http://www.neobytesolutions.com/invsecr/