• Sunplus Technology Digital Camera Driver
• Sunplus Spca 533 Driver Download
• Sunplus Firmware
• Sunplus Innovation Technology

AMCAP MD80 MINI DV DRIVER FOR MAC - General still camera device, Sunplusmm, bulk Generous flux helps to create a good bond. Then if the camera seems dead, I do the next step. Even within a version of the camera there are various camera modules used so. The RAR driver file is less than 4 megabytes. Open SPCA1528.RAR file using WinRAR or equivalent. Here is a link to the SunPlus webcam driver which works for the #3 and #6 cameras. The driver file is available from multiple places on the web. Just Google one of these files and download it. Sunplus is a leading provider of multimedia IC solutions for Automotive DVD players, portable DVD players, Car CD/DVD players, etc. Meanwhile Sunplus is offering high-speed I/O IP, high performance data conversion IP, and analog IP for a broad range of applications on. How to Manually Download and Update: This built-in Sunplus MMcatch (VII) Video Camera Device driver should be included with your Windows® Operating System or is available through Windows® update. The built-in driver supports the basic functions of your Sunplus MMcatch (VII) Video Camera Device hardware.

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

Update : datasheet of SPCA533A available !

Update : A software-only method have been made available ! Isoprop gathered all the needed steps in his tutorial. And it *is* working, without any soldering needed. Job done 😉 Thank him, and thank you dear readers for your grateful comments.

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:

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:

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

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 !

Another reader, Bob N, sent me a much more precise datasheet of a SPCA-533A. 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 :

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:

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 😉

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:

• gumpack_camera_flash.raw.bz2 (606K)
• gumpack_camera_flash.ihex.bz2 (1.1M)

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

• MD80.bin.bz2 (622K)
• MD80bis.bin.bz2 (623K)

And Allan also sent me his camera firmware :

• allan-808-number3.bin.bz2 (624K)

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 :

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:

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 :

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

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.

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 :

• recup_0090__0x093d42-0x0952fd.jpg (5.4 KB)
• recup_0120__0x0a967a-0x0aa535.jpg (3.7 KB)
• recup_0295__0x0b7192-0x0b871a.jpg (5.4 KB)
• recup_0316__0x0b871c-0x0ba247.jpg (6.8 KB)
• recup_0336__0x0ba248-0x0bb103.jpg (3.7 KB)
• recup_0391__0x0fa558-0x104e07.jpg (42.2 KB)
• recup_0406__0x0fa6a0-0x0fb4ad.jpg (3.5 KB)
• recup_0423__0x0fba2a-0x0fcdb0.jpg (4.9 KB)
• recup_0441__0x104e08-0x110f0d.jpg (48.3 KB)
• recup_0453__0x104f50-0x105ee2.jpg (3.9 KB)
• recup_0467__0x10644b-0x107b8d.jpg (5.8 KB)
• recup_0480__0x110f0e-0x113c83.jpg (11.4 KB)
• recup_0493__0x113c84-0x11fc89.jpg (48.0 KB)
• recup_0501__0x113dcc-0x114fb7.jpg (4.5 KB)
• recup_0511__0x115520-0x116dd2.jpg (6.2 KB)
• recup_0529__0x19b21c-0x19c7d7.jpg (5.4 KB)

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:

Here are the 4 files:

• recup_0010__0x0a3d42-0x0aa576.wav (26.1 KB)
• recup_0020__0x0ad4f0-0x0aff8c.wav (10.7 KB)
• recup_0025__0x0b021c-0x0b5cf6.wav (22.7 KB)
• recup_0035__0x0bb104-0x0cc59a.wav (69.1 KB)

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. 0x120000-0x130000:
2. 0x130000-0x138000:
3. 0x138000-0x13d000:
4. 0x13d000-0x140880:
5. 0x140880-0x141880:
6. 0x141880-0x142880:
7. 0x142880-0x143880:

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 :

Sunplus Technology Digital Camera Driver

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 0x138000-0x13d000. Here is the corresponding part of the firmware with the transparent font:
0x138000-0x13d000_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.

Sunplus Spca 533 Driver Download

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

Sunplus Firmware

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

Sunplus Innovation Technology

Happy Hacking !