Pure Digital PV2 Flash Analysis

PV2 Flash Memory Analysis

Pure Digital's Ritz Camera Dakota PV2 LCD variant

Storage format
This looks like a subset of the standard Smart Media format used in the previous version of the camera. As per the standard, every 512 bytes of data has an additional 16 bytes allocated it to help manage bad blocks. The ECC field seems to be used, but the Block Address isn't. My guess is that the firmware handles bad blocks by simply marking the blocks bad in the FAT (this method has been around since the early days of DOS). The conversion program I wrote for the older camera -- flashdump2iso.c -- is not needed.

Directory
What's stored on the flash? Unlike the previous version, there's a whole lot more, including the main firmware (I assume there is a bootloader in the main chip capable of passing control to this program) and various screen images that get displayed at different times during the camera's operation.

total 1728
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 SPLASH.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 SHUTDOWN.TFT
-rwxrwxrwx 1 mouse admin      24 31 Dec 1979 PDSCRTCH.BIN
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-09.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-08.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-07.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-06.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-05.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-04.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-03.TFT
-rwxrwxrwx 1 mouse admin   61600 31 Dec 1979 PD-02.TFT
-rwxrwxrwx 1 mouse admin     776 31 Dec 1979 NVRAM.DAT
-rwxrwxrwx 1 mouse admin   16384 31 Dec 1979 LANG-EN.DAT
-rwxrwxrwx 1 mouse admin     334 31 Dec 1979 FWCFG.DAT
-rwxrwxrwx 1 mouse admin 127488 31 Dec 1979 FIRMWARE.BIN
drwxrwxrwx 1 mouse admin   16384 31 Dec 1979 DCIM
-rwxrwxrwx 1 mouse admin    1024 31 Dec 1979 CAMCALIB.BIN

The DCIM directory contains only one file: the subdirectory RAW:

total 2432
32 drwxrwxrwx 1 mouse admin   16384 31 Dec 1979 .
32 drwxrwxrwx 1 mouse admin   16384 31 Dec 1979 ..
1024 -rwxrwxrwx 1 mouse admin 517604 31 Dec 1979 IMG_0001.RAW
1216 -rwxrwxrwx 1 mouse admin 609420 31 Dec 1979 IMG_0004.RAW
128 -rwxrwxrwx 1 mouse admin   65536 31 Dec 1979 THMBNAIL.TFT

I'm guessing that because these ".RAW" files are small and of variable size, they are probably compressed. This is not to be confused with the "RAW" format that some high-end cameras use that is essentially an unprocessed version of the data from the imager. The file THMBNAIL.TFT is probably the last picture taken.

The two files start with the same basic header (which isn't a JPEG/JFIF header). daBass has an excellent analysis of these headers:

IMG_0001.RAW:

00000000 9c 00 09 e4 e5 07 00 9c 00 00 00 60 03 08 05 c8 |...........`....|
00000010 03 5c 03 00 05 9c 00 00 00 dc 00 18 01 00 00 00 |.\..............|
00000020 00 0c 0c 00 ff 03 00 1e 09 7f 19 00 00 18 00 20 |............... |
00000030 10 05 10 64 06 27 02 02 02 02 00 04 00 00 9c 00 |...d.'..........|
00000040 00 00 00 d4 e5 07 00 02 04 06 98 08 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 28 38 e5 07 00 10 00 00 00 |.......(8.......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 47 e1 09 00 |............G...|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 8d 92 db |................|

IMG_0004.RAW:

00000000 9c 00 09 8c 4c 09 00 9c 00 00 00 60 03 08 05 c8 |....L......`....|
00000010 03 5c 03 00 05 9c 00 00 00 dc 00 18 01 00 00 00 |.\..............|
00000020 00 0c 0c 00 7f 03 01 41 3f 7f 19 00 00 18 00 00 |.......A?.......|
00000030 10 05 10 64 06 27 02 02 02 02 00 04 00 00 9c 00 |...d.'..........|
00000040 00 00 00 54 4c 09 00 07 00 00 00 00 00 00 11 00 |...TL...........|
00000050 00 00 00 00 00 00 00 26 b8 4b 09 00 38 00 00 00 |.......&.K..8...|
00000060 00 00 00 00 50 80 0a 00 60 00 00 00 47 e1 09 00 |....P...`...G...|
00000070 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 55 21 fe |.............U!.|

Although detecting the presence of encryption on compressed files is difficult (ideally, they'll both have random data), my guess is that some sort of obfuscation is going on here. IMG_0001.RAW should look like my cat. IMG_0004 is probably an accidental picture taken by a friend, and it wouldn't surprise me if it looked like THMBNAIL.TGA.

The file FWCFG.DAT contains some interesting data, but probably isn't too useful.

cfg.version=1.0
cfg.camera.vendorid=0x0dca
cfg.camera.hwid=0x06
cfg.camera.typeid=0x27
cfg.camera.fwtype=0x02
cfg.tar.creationdate=04.29.2004:13:51:43
cfg.tar.system.media=1
cfg.tar.dst.location=\\
cfg.tar.fw.version=0x6410
cfg.tar.fw.src.file=t27-a06-f02-v6410.pack
cfg.camera.store.t27-a06-f02-v6410.pack.as=firmware.bin

Note that cfg.tar.fw.version, cfg.camera.hwid, and cfg.camera.typeid are displayed on the camera's INFO screen (available when you power on with screen while pressing the shutter, delete, and display buttons simultaneously).

The NVRAM.DAT file contains a bunch of constants used by the camera, including the serial number and authentication codes. My analysis is on this page.

The interpretation of data in files PDSCRTCH.DAT and CAMCALIB.BIN was not immediately obvious.

TFT File Format
It's no surprise that most of the .TFT files are 61600 bytes long because that's the number of pixels on the 280x220 display. Normal computer pixels are comprised of red, green, and blue components, but this format represents how the hardware actually displays the image: one pixel is shades of red, the next pixel is shades of green, etc. On even lines, the order is RGB, on odd lines, the order is GBR. I wrote a quick little utility to do the conversion: tft2tga.c. It gives decent results, but since the display has a very distinctive Bayer pattern and odd lines are offset by 1/2 pixel, the translation could be improved -- it's a trade off between making the result look good and look like the actual display.

Sample Image PD-07.TFT (converted to TGA, then GIF)

The thumbnail file (converted to THMBNAIL.TGA) is slightly bigger than the other .TFT files and the conversion didn't work too well. It's a picture my friend accidently took, so I suspect that the gray gradient is a correct picture of his desk. When thumbnails are shown on the screen, the picture count ("24 REMAINING") occupies the lower part -- so, I'd expect this file to be smaller than the other full-size .TFTs. On the contrary, it's a bit bigger. The translation shows some gibberish at the bottom where the text would be. Note that the first image taken (of my cat) is no longer stored in a readable format on the camera -- it could have been deleted and still be recoverable, though, but I suspect it was simply overwritten.

LANG-EN.DAT
This file has four parts:

0000-0BFF	Three copies of a 64 character 8x16 bit-mapped font table. It includes digits, a bunch of assorted icons, and an upper-case only set of letters.
0C00-1FFF	Zeros
2000-289F	Three copies of 40 text messages (the second copy starts at $2300, third at $2600). Only the second copy is used. It's not ASCII. Non-drawing areas are zero, spaces are 0xFF, and all other characters are (I assume) part of the font table. The letter "A" is represented by 0x26 -- ASCII would be 0x41, and it's entry 0x25 in the font table (assuming it starts at zero). 2000: FLASH........... 2010: ID.............. 2020: SIZE............ 2030: SECONDS......... 2040: READY........... 2050: TO.RECYCLE...... 2060: TIMEOUT......... 2070: CANCELLED....... 2080: DELETED......... 2090: INFO............ 20a0: FIRMWARE........ 20b0: HARDWARE........ 20c0: TYPEID.......... 20d0: IMGPROC......... 20e0: PICTURE.SAVED... 20f0: SAVING.PICTURE.. 2100: DELETE.......... 2110: DELETE.ALL...... 2120: FORMAT.......... 2130: REMAINING....... 2140: DELETE.PICTURE.. .. and more
28A0-3FFF	Zeros

I wrote the little utility lang2tga.c to generate a .TGA graphics file of the font information, and to decode the text of the messages (letters only).

FIRMWARE.BIN
Most of the analysis is going to center on this file -- it holds the key to the USB interface and the method of storing pictures in memory. It's going to take a long time to analyze, but I'll keep track of my progress on this page.

My main PV2 analysis page
other systems I've played with
visit my homepage