Update : The method and all the files needed to do it are available in the article : How to remove date and timestamp from gumpack camera

I recently bought a micro camera to put on my RC glider on ebay. I am happy with the quality, as it does video at 30fps and 720×480. You should look at my RC glider videos here. The issue with this camera is that it automatically inserts the date in the video, and that it is reset to 01-01-2008 each time it is powered on. After reading Chuck’s web site, I decided to open and try to hack my camera. Here is what I found.

The camera is often called « gumpack camera », due to its form factor. I have chosen this one as it would easily fit into my plane. It look’s like to have the same characteristics as the #3 camera. The image have the same size, and the timestamps inserted are the same. It uses a file « TAG.TXT » to set the date with a line starting with « [date] » .

TODO Photo camera plane

I didn’t manage to go into any system mode, and didn’t managed to get the webcam working. It’s always seen as a mass storage from the computer.

When plugged on my linux box, it shows theses VID/PID:

Bus 001 Device 010: ID 04fc:0171 Sunplus Technology Co., Ltd

It behaves as a mass storage device, and let you access the content of the flash card.

If you press the « record » button while in mass storage, it goes into webcam mode, and advertise itself as:

Bus 001 Device 012: ID 04fc:1528 Sunplus Technology Co., Ltd

To go in this mode, you should wait ~5 seconds after having plugged it. I haven’t tried the webcam drivers.

Electronics

So, what is inside ?

There is:

  • LiPo 1 cell 270 mAh
  • The camera sensor
  • A 16Mbit (2MB) Flash SPI memory (cFeon F16-100HIP Q93H06A F921GDA, also called EN25F16). I managed to found the datasheet here : EN25F16.
  • Some RAM : VT3664164T-6 (4Mx16bit SDRAM)
  • And an ASIC : SPCA1527A

A reader (George S.)  sent me the datasheet of the SPCA1528. Ok, to be more precise, it is more a « commercial sheet », that just show some example products. Thanks !

Here are some photos of the camera opened. Click on the images to get the full resolution.

The CMOS sensor seems a bit different than other models, as it is mounted on a small support. Here is a macro of it. It has 24 pins.

I can corroborate the Chuck’s assumption with the help of my oscilloscope. When the camera boots, there are lots of transfer from the flash SPI during one second or so. There is no traffic at all after, even when you start and stop a recording. When the camera is in « sleep » (all leds off but power button « on »), the flash chip is powered off. We can conclude that the SPI flash contains the firmware of the camera, and it is copied inside the RAM at boot time. So the code that inserts the date in the film is in !

I bought mine in November, 30th, 2009. On the PCB, it is written :

D004_V3090818

Villamany posted a comment with some photos of his own gumstick camera. The components seems to be the same (at least the chipset), but it looks a bit smaller. He bought it in December, 23rd, 2009. On his one, it is written:

D001_V7091114

The second line looks like a production date or something similar, in the format YYMMDD. I assume mine stays one month and a half in stock before being sold, and it is almost the same delta for him.
The second line seems to indicate a model and a version. According to the manual, I have a « DV D004 camera ».

Playing with crystals

Following the Spiners’s idea in the comments, I tried to remove the RTC crystal. When I switched on the camera, the green led lights, then the red one and that’s all. It doesn’t respond to button presses. It doesn’t show up on the USB port.
When I remove the main crystal (written 27MHz), NOTHING happens. No lights, no USB, no response to buttons. I then tried to underclock the main chip, and put a 18MHz crystal on it, just to see what happens ;-) A took a 15s video, counting the seconds. The funny thing is that the video is « accelerated ». It only last 8s. The sound is accelerated also and is treble. The probable explanation is that the avi file says it’s 30fps. But the chip didn’t output all the 30 frames during a second because it was underclocked. But at play back, the 30 frames were displayed, and looked like accelerated. The timestamp insertion was still there and stamped the video at the correct real time.

Battery and current

I made some current consumption measures:

  • Switch « Off » : No current at all
  • Switch « On », but in sleep : 0.02 mA (more than one year before battery down)
  • Switch « On », with green led on : 115 mA (the current waveform shows a frequency around 15 KHz, hello RTC clock !)
  • During recording, the camera consumes around 145 mA. There are some spikes at 220 mA every 64ms. It’s probably when the SD card is written.

I measured the battery capacity at 270mAh (discharge current of 200mA, down to 3.0V). So I expect it to be able to last a bit more that one hour.

The next thing to do is to dump the data ;-)

Flash content

Once again, I had to make my own tools. You are never better served than by yourself ! At first, I would have preferred to not desolder completely the 8-pins flash, to not take too much risks. As this solution was not working, I removed it completely, and fit it on a standard 8-pin DIL package, with some wires. Although it is a bit dirty, this solution worked well ! I also added a small decoupling capacitor closer to the chip, as I noticed on the oscilloscope some spikes in the power lines. As you can see on the photo, I removed the LiPo battery. To be more precise, it removed itself, as the wires doesn’t bend easily and are very fragile. I suspect that some camera will die as the lipo can move inside the case and the wires will break.

Using an old AT90S2313 AVR micro-controller from Atmel, I made a SPI reader. The uC firmware was reading all the content off the memory and dump it by its UART to my computer. A python script was in charge of reading the data back, and write them to a « raw » file and a « intel hex » file. I should do another article on that …

The flash is 16Mbit, so it makes a 2MB file. It took me more than 7 minutes to transfer it through the AVR at 10MHz, and the UART at 57600 bauds. Around 400KB of the memory are « 0xff », which means unused space.

You can download the raw data and the ihex:

Villamany managed to extract the firmware from both of his MD80 camera ! Here they are :

And Allan also sent me his camera firmware :

Thank you for sharing them ! The firmware are mostly identical, but there are some differences. The strings are not always in the same order in the file, showing a new recompilation of the code. Some strings, like a date, are also different.

There are some interesting « strings » in the content. Here are only a few of them :

NAND RSVDCIM100MEDIASunplus SPCA1KCCurrent F/W version: %sD:\1528.BINISP.BINDRAMPARA.TXTBoot %s, %lu KBISPKEY.TXTFW.BIN1528.BIN=====AE Gid and Luma====="[date]Omnivision 3.1MSunplus CA1528fill [mem type]  [+offset]dump [mem type] [start addr] [+offset] [end addr]adc s: Start adc testadc e: Stop adc testadc a: Start button testTask start successfulPress any key to start the test...No err has found in this test!Press 'r' to restart the test, other keys to exitTimeStyleMM/DD/YYYYDD/MM/YYYYwww.vividsound.com                                  (206) 781-8498Adobe Photoshop CS2 Windows

Seeing this, I am happy to have dumped something without errors ! (I mean correct endianness, no bit inversion, no ciphering, no shift). They show some file names, such as 1528.BIN, or the well know TAG.TXT. The hexdump tool can also be used to « see » something:

00008af0  e4 9e fe e4 9d fd e4 9c  fc 22 5b 64 61 74 65 5d  |........."[date]|00008b00  00 25 62 78 2f 25 62 78  2f 25 62 78 2f 25 62 78  |.%bx/%bx/%bx/%bx|00008b10  2f 25 62 78 2f 25 62 78  0a 00 4e 6f 20 74 65 78  |/%bx/%bx..No tex|00008b20  74 20 66 69 6c 65 21 0a  00 44 3a 5c 44 43 49 4d  |t file!..D:\DCIM|00008b30  5c 00 31 30 30 4d 45 44  49 41 00 25 73 28 25 6c  |\.100MEDIA.%s(%l|00008b40  64 29 0a 00 73 70 69 5c  73 65 72 69 61 6c 5f 66  |d)..spi\serial_f|00008b50  6c 61 73 68 5f 53 54 2e  63 00 31 20 25 62 78 0a  |lash_ST.c.1 %bx.|00008b60  00 30 78 32 35 30 30 20  25 62 78 0a 00 73 74 73  |.0x2500 %bx..sts|00008b70  20 66 61 69 6c 20 25 62  78 0a 00 0a 54 4b 20 42  | fail %bx...TK B|00008b80  20 00 46 2f 57 20 76 65  72 73 69 6f 6e 20 69 73  | .F/W version is|00008b90  20 25 73 0a 46 2f 57 20  63 6f 6d 70 69 6c 65 64  | %s.F/W compiled|00008ba0  20 40 20 25 73 2c 20 25  73 0a 0a 00 49 4f 54 72  | @ %s, %s...IOTr|00008bb0  61 70 20 25 62 78 0a 00  ef 64 0a 70 1c 30 98 11  |ap %bx...d.p.0..|00008bc0  e5 99 b4 13 0c c2 98 30  98 fd e5 99 b4 11 f6 c2  |.......0........|00008bd0  98 30 99 fd c2 99 75 99  0d 30 98 11 e5 99 b4 13  |.0....u..0......|00008be0  0c c2 98 30 98 fd e5 99  b4 11 f6 c2 98 30 99 fd  |...0.........0..|

ARM Inside ?

Chuck supposed that the SPCA chip was powered by an ARM CPU, especially the 926EJS. I tried to run a ARM disassembler on the file and find out that no code is ARM. I know ARM processors quite well, and can confirm that it’s not ARM powered.

My collegue Gillou ran a dissembler for the following CPU architectures : avr, mips, h8300, SH, z80, m68k. Neither of them give result. But a 8051 worked very well !
Here is some code example :

L0584:  1B64 EF    		MOV A, R7  1B65 7802  		MOV R0, #2hL0586:  1B67 C3    		CLR C  1B68 33    		RLC A  1B69 CE    		XCH A, R6  1B6A 33    		RLC A  1B6B CE    		XCH A, R6  1B6C D8F9  		DJNZ R0, L0586  1B6E 128AD8		LCALL L0587  1B71 128B81		LCALL L0588  1B74 6461  		XRL A, #61h  1B76 6003  		JZ L0589  1B78 028468		LJMP L0590
 
L0589:  1B7B A3    		INC DPTR  1B7C E0    		MOVX A, @DPTR  1B7D 6476  		XRL A, #76h  1B7F 6003  		JZ L0591  1B81 028468		LJMP L0590

Given that the 8051 uses variable length instruction, it’s very unlikely that we have good dis-assembly with a wrong architecture.

What’s next ?

Knowing the CPU, it’s time to disassemble the code and find where is the code that inserts this f*ing date in the image. If a good software guy can modify the code, I will have to do a circuit able to write into this flash memory to try it. There is also the string 1528.BIN in the raw file. We can suppose that this is a way the reprogram the flash more easily. Please use and explore the binary files.

More discoveries on the dump

By looking more closely to the strings, I noticed « JFIF ». It is present in the header of the .jpg images. The jpg images starts by the magic number 0xffd8 and ends with 0xffd9. I have made a python script (again !) that extracts all the data from the dump that starts with 0xffd8 and terminate by 0xffd9. I found 16 images, and here they are, with there start and end address in the dump file :

This represent 209KB of beautiful photos isn’t it ? I am sure that if these Chinese had made more effort, they could have used a 8Mbit flash memory only, and gain a few cents more on each camera !

And even sounds !

This time, it was the string « WAVEfmt » that kept my attention. I managed to extract 128.6 KB of wave files by modifying a bit my script. The files starts with:

00000000  52 49 46 46 .. .. .. ..  57 41 56 45 66 6d 74 20  |RIFF....WAVEfmt |

Here are the 4 files:

Extracting the font from the dump

Spinner and Bill W. have posted comments and methods to display « something » with the raw dump. Bill W. managed to see this:

We can see the numbers from 0 to 9 and the « / » and « : » needed to display date and time. We don’t know yet the encoding, but it looks promising. We can even recognize some Chinese characters. His explanations are here.

Spinner went a bit further, publishing this image in the comments with explanations:

On this one, the font is even more precise. (link to the original)

That’s really great work starting from a good idea from Bill !

Here are the characters we are looking for, extracted from the video :

Each character here is 16×24 pixels. So it fits quite well in bytes.

Address mapping of theses « fonts »

Following Spinner work, I cut the dump in part where « something » appear. Here is the result. If you click on the address range, you will get the raw data.

  1. 0×120000-0×130000:
  2. 0×130000-0×138000:
  3. 0×138000-0×13d000:
  4. 0×13d000-0×140880:
  5. 0×140880-0×141880:
  6. 0×141880-0×142880:
  7. 0×142880-0×143880:

The idea behind all this is to be able to change the font in the firmware so that all characters appears « transparent ».

I will try to write this into the firmware, and see what happens.
If the « 2  » has gone, it rocks ! I believe it is the same idea as Spinner, but I cannot access the file(rapidshare overloaded :-) )

Work done ! The « 2  » is out !

I made the soft to program the flash SPI, and program it with the tentative font with the « 2  » removed. Here is the result :

I removed all the other numbers, like the file submitted by spinner, and as expected, all timestamps have disappeared !
We still don’t really know the encoding of the font, when the firmware only show the following image, there is no timestamp:

The firmware change is only between 0×138000-0×13d000. Here is the corresponding part of the firmware with the transparent font:
0×138000-0×13d000_no_font.raw (20 KB)

So, work done, the timestamp is completely removed from my gumpack camera. Thanks to Chuck, Spinner, Bill W. and other people that posted great ideas in the comments. It took me a bit more that one week to achieve this.

Here is the final result :

Next thing to do is make this « easier » so that other people can use this information.

Update 10 march 2010

Villamany managed to remove the timestamp from his md80 camera too ! Here is his success : on this water rocket forum Congratulations !

Happy Hacking !