blueDonkey.org
Linux.DakotaPv2Camera
Background
This is my collection of information about the Dakota PV2 digital camera, the one with the LCD screen. The cameras are available in some Ritz Camera/Wolf Camera stores for $18.99. They are intended to be returned to the store for "processing" in the same way as the "disposable" film cameras. In return for that you will get prints and a CD with the images on it, but not the camera back. From the perspective of a customer, this seems like a very expensive way to get low resolution digital prints (probably better off with a disposable film camera and asking for the CD at processing time). A more interesting business model would be to have them return the camera to you as well (ready for you to take more photos that they need to print). Some technical stuff: The camera is based on a chipset from SMaL for which almost nothing is known. There is some support in gphoto2 for other cameras based on SMaL products, but these do not seem to help much with Dakota PV2. Much like its predecessor, there is almost certainly something that must be done before the camera will talk to the host computer. Currently that trick is not known.
Collected Information
USB Description
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 34 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=0dca ProdID=0027 Rev= 0.01 S: Manufacturer=SMaL S: Product=Digital Camera C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms C: #Ifs= 1 Cfg#= 2 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0msDiscovered Information
- The camera seems to accept exactly 1 message on its bulk input endpoint; any subsequent writes fail. The only way to get out of this state appears to be disconnecting and then reconnecting it.
- The message that can be written can be no more than 36 bytes
- Holding down the shutter release, display and delete buttons while turning the camera on results in it displaying some information on the screen about the s/w installed, and also an ID.
- Control reads using vendor specific messages do not seem to do anything (I am currently trying reads from every request/index pair though this will take a while!)
- A complete pass through all 65536 index values for all 256 requests revealed nothing new; every request returned the 8 bytes of the message that would have been sent over the wire.
String Descriptors
Descriptor ID Value Comment 0 04 03 09 04 Language IDs: 0x0409 (US) and 0x0403 (??) 1 "SMaL" Manufacturer 2 "Digital Camera" Product string 3 "OK" Configuration string 4-255 "BAD" Unused strings Notes
Somehow with all the poking of the USB that I have done, I have managed to 'reset' the device ID to LAMSSMAL0000 (originally it was DAA04190nnnn (where nnnn is a four digit number that I do not remember!). Not sure what could have caused this.Windows Driver Experiments
I have been playing with a couple of Windows drivers for other cameras based on the SMaL chipset:
- Oregon Scientific's DS6628 (Driver .EXE)
These two drivers between them contain support for the following USB vendor/product pairs. More research into the internals of the Foxz2 driver for the Macintosh reveals the table of devices that it supports. Interestingly, the PV2 is listed in the table as a Legend Digital Camera. There is another Legend Digital Camera as well on device ID 0026. Here is a more complete table compiled from this driver, and other sources:
- NHJ's Che-ez! Foxz2 (Windows Driver .ZIP | Mac OS X Driver)
Adding the 0DCA/0027 pair to both drivers allows them to connect to the camera (at least the LED on the camera illuminates), but both drivers report that the "operation is not permitted in bootloader mode" when any attempt is made to download images. Both drivers are also unable to get a count of the number of photos on the camera, to format the flash on the camera or to reset the counter. That leaves me wondering whether there is in fact no USB software on the camera, only a USB bootloader. The software to download the images from the camera is then downloaded in the store by the 'processing' machine before it can obtain the images. That would make it much, much harder to hack. The 'bootloader' in this case is capable of simple camera operations (like storing images in flash and deleting the last image) as well as downloading software.
Driver Vendor Product Description Manufacturer 041E 4016 CardCam? Creative Labs 046D 0950 Pocket Digital (TCF-3) Logitech 046D 0953 Pocket Digital (TCF-5) Logitech 0471 0306 PocketCam? Philips 0DCA 0000 Ultra-Pocket Digital VGA Proto SMaL? Camera Technologies, Inc 0DCA 0001 Ultra-Pocket Digital VGA SMaL? Camera Technologies, Inc 0DCA 0002 eyeplate/SLIM SHOT FUJIFILM AXIA CO., LTD 0DCA 0003 Pocket Digital (BTLDR) Logitech 0DCA 0004 FLATFOTO RadioShack? Corporation 0DCA 0005 CardCam? (BTLDR) Creative Labs 0DCA 0006 Pocket Digital (BTLDR) Logitech 0DCA 0007 Reserved[0x0007] Unknown 0DCA 0008 DS6618 (TCF-5) Oregon Scientific 0DCA 0009 Reserved[0x0009] Unknown 0DCA 000A Reserved[0x000A] Unknown 0DCA 000B Reserved[0x000B] Unknown 0DCA 000C Reserved[0x000C] Unknown 0DCA 000D Reserved[0x000D] Unknown 0DCA 000E Reserved[0x000E] Unknown 0DCA 000F Reserved[0x000F] Unknown 0DCA 0010 Ultra-Pocket Digital MP Proto SMaL? Camera Technologies 0DCA 0011 Ultra-Pocket Digital MP SMaL? Camera Technologies 0DCA 0012 eyeplate/SLIM SHOT mega Proto FUJIFILM AXIA CO.,LTD DS6628 0DCA 0013 Oregon Scientific DS6628 (BTLDR) Oregon Scientific 0DCA 0014 eyeplate mega (BTLDR) FUJIFILM AXIA Co.,LTD 0DCA 0015 1.3 MP Digital Camera OEM 0DCA 0016 Reserved[0x0016] Unknown 0DCA 0017 Reserved[0x0017] Unknown 0DCA 0018 SLIMSHOT mega (BTLDR) FUJIFILM AXIA Co.,LTD 0DCA 0019 Reserved[0x0019] Unknown 0DCA 001a Reserved[0x001A] Unknown 0DCA 001b Reserved[0x001B] Unknown 0DCA 001c Reserved[0x001C] Unknown 0DCA 001d Reserved[0x001D] Unknown 0DCA 001e Reserved[0x001E] Unknown 0DCA 001f Reserved[0x001F] Unknown 0DCA 0020 Ulta-Pocket Digital 2MP Proto SMaL? Camera Technologies 0DCA 0021 1.3 MP Digital Camera SMaL? Camera Technologies 0DCA 0022 PocketCam? (BTLDR) Philips Foxz2 0DCA 0023 Che-ez! Foxz NHJ Foxz2 0DCA 0024 Che-ez! Foxz2 NHJ 0DCA 0025 2.0 MP Digital Camera SMaL? Camera Technologies 0DCA 0026 Legend Digital Camera (SMaL?) Pure Digital Technologies, Inc 0DCA 0027 Legend Digital Camera Pure Digital Technologies, Inc 0DCA 0028 CVS Blue
0DCA 002B 0DCA 0030 DS6628 0FDE 6628 Oregon Scientific DS6628 Oregon Scientific 11D6 0001 eyeplate mega FUJIFILM AXIA Co.,LTD There is full software on the camera, but there is an authentication step that the Foxz drivers do not expect. See John Maushammer's USB command summary page for more information on this.
Unlocking the Camera
John Maushammer's site has a Mac OS X tool for unlocking the Ritz PV2 cameras, and also making them appear to be Foxz2 cameras. I have a couple of modified scripts for this tool that handle the cameras that have had their serial number & authentication code reset.I am planning to port John's tool to Linux as soon as possible. Perhaps Forkboy's Windows tool will also gain this ability soon. Once unlocked, using the Foxz2 drivers (Windows, Mac OS X) you can easily extract photos from the camera. Reading them also seems to zero the camera's counter ready for more shooting. For Mac OS X, iPhoto will even recognise the camera and start as soon as you plug it in! On Windows I had to start my image editing software (an old version of Adobe's Photoshop Elements that came bundled with the machine) and use its import feature to get the photos.
Use these at your own risk. You can render your camera useless. By using these scripts you accept full responsibility for any damage caused by them
Bootloader Commands
While working on the Linux port for the pv2mod tool I managed to corrupt the firmware on the camera so that now it boots up with three low pitch tones (and if connected to the USB, one trailing high pitched tone). So I have been probing this mode to see what it will respond to. It seems to be using the same command structure, but supports many fewer commands. In fact, if I am reading the error codes correctly, just two:
Command Arguments Description 0x26 TBD TBD 0x51 TBD TBD Command 0x26
- Read: Size must be a multiple of 0x100, otherwise it stalls
- Read: Sizes between 0x100 and 0x3F00 (incl.) generate response code 0x61. Sizes of 0x4000 and more generate response code 0x62.
- Reads seem to return random memory contents (of the size requested).
- Writes generate a beep on the camera and a response code of 0xB1. The size of the write does not seem to affect the result.
Command 0x51
- Read: Reading LUN 1 returns a block of data and a success response code.
- Read: Reading LUN 0 returns the same block of data and a success response code.
- Read: Reading LUN 2 returns the same block of data and a 0xB1 response code.
- Read: Reading LUN 3 returns the same block of data and a success response code.
- Read: Block parameter appears to be unused
There might be some kind of header in the data returned by the read commands:
- Write: Writes to LUNs 0,1 and 3 return 0x62; writes to LUN 2 return 0xB1
02 06 00 00 00 27 00 04 50 51 06 00 00 fc 3f 00If I write data using 0x51, then read it back. I get the data I wrote except for the first 16 bytes which are always the same. The maximum I can read using this command is also there in the end of that header (0x003FFC00). Interestingly, when I look at the response code for a read of that maximum length, the residue word in the response packet contains 0x3FFBF0 (i.e. 16 less than the amount I asked for). Could this be loading straight into RAM, irrespective of the LUN I give it (the error for LUN 2 could be something generated by a generic validation routine). Some more interesting information about that header... When I connect the camera to the Windows box and open the Foxz import tool, it has an info tab that tells me some things about the camera:So, now I can see some of the values in that header block:
- Hardware Version: 0006
- Firmware = "5150 Internal ROM"
- Type = 0027
Now, I doubt that the header going in the other direction is the same format, but there does seem to be a header (as witnessed by the fact that the first 16 bytes of whatever I write are not returned to me). Could this be some information about how to start the downloaded code? Perhaps even load address, execution address etc that one would normally find in an executable file format? Maybe there's even a checksum somewhere (since we know it likes to checksum files it works with).
Byte(s) Meaning 00 01-02 03 04 05-06 USB Product Type 07 08-09 Firmware version 0A-0B 0C-0F Length of data? Response Codes
Code Possible Meaning 0x00 Operation OK 0x60 Unrecognised command 0x61 0x62 0xB1
USB Tool
As part of trying to work out how to talk to this camera I developed a small USB probing tool (for Linux) that can be used to send commands to the camera and read back results. The tool source can be downloaded from this page. The tool requires usbdevfs to be mounted and also libusb to be available on your system. Assuming all of that is OK, just type make and you will get a binary called usbtool. Unless you have all the privileges set up to allow full access to the USB subsystem, you'll probably have to run this as root. Usage is:Note that some things are not implemented (see below). The data strings are test strings with some escape code options for setting difficult to type values:Version: 0.3 (Jul 8 2004) Usage: usbtool <vendorID>:<prodID> bulk write [ <data_string> ] usbtool <vendorID>:<prodID> bulk read <length> usbtool <vendorID>:<prodID> ctrl write <req> <value> <idx> <size> usbtool <vendorID>:<prodID> ctrl read <req> <value> <idx> <size> usbtool <vendorID>:<prodID> req write device|interface|endpoint <req> <value> <idx> <size> usbtool <vendorID>:<prodID> req read device|interface|endpoint <req> <value> <idx> <size> usbtool <vendorID>:<prodID> string <idx> <language> usbtool <vendorID>:<prodID> config <alt> <cfg> usbtool <vendorID>:<prodID> resetYou might need to double escape the '\' character depending on your shell too. Here's an example command line for a bulk write to the camera, complete with result:
Escape Code Data Value \0 0 \xXX 0xXX \dN N (can be 1-3 digits) If the operation fails, then the tool will tell you that the operation failed:# ./usbtool 0xdca:0x27 bulk write "\\x00\\x01\\0DAA041900226\\0" Using config 1 interface 0 alt 0 inep 0x81 outep 0x1 intep 0xffffffff Data: 00 01 00 44 41 41 30 34 31 39 30 30 32 32 36 00# usbtool 0xdca:0x27 bulk write "\\x00\\x01\\0DAA041900226\\0" Using config 1 interface 0 alt 0 inep 0x81 outep 0x1 intep 0xffffffff Data: 00 01 00 44 41 41 30 34 31 39 30 30 32 32 36 00 usb_bulk_write(): Broken pipe Operation failedDakota PV2 Flash Upload Tool
I have added a simple tool that will allow the full 16MB flash image to be extracted from the flash. It copes with two different authentication key values: the original one described on John Maushammer's site, and the one for those of us who have cleared the serial number somehow (it would be useful to know how this happens since that would mean we could render all cameras usable without having to get the complete set of challenge/response blocks). Using the tool is simple:Once you have the image, it can be mounted directly on Mac OS X machines, but for Linux a little more processing is needed:dakota_pv2 flash.binYou will, of course, require root privilege for the mount command :-) Once you have that much, then you can do whatever you want with the files in the flash. Windoze users will want to check out the equivalent tool for that platform from ForkBoy: http://mysite.verizon.net/forkboy/PV2Tool.zip (screenshot). You will also need a tool to read the image (ForkBoy recommends http://www.softwarium.com/divwin.html for this).dd if=flash.bin of=flash.iso bs=512 skip=57 mount -o loop flash.iso /mntChange History
Version 0.5 (January 16, 2005)
- Added a preliminary ( and not tested, so use at your own risk ) port of John Maushammer's pv2mod tool to Linux
- Added a new tool, pv2ldr, that I am using to probe the bootloader functions (having killed my camera while testing the pv2mod tool port).
Version 0.4 (December 21, 2004)
- Added a new tool, dakota_pv2, based on the work done by John Maushammer and others that will capture the full 16MB flash image
Version 0.3 (July 8, 2004)
- Added support for standard requests to device/interface/endpoint (read & write)
- Added simple string descriptor read command
- Improved data dumping format for read commands
Version 0.2 (June 19, 2004)
- Added support for control transfers (read & write)
- Added version numbering scheme
Initial Version (June 12, 2004)
- Bulk read supported
- Bulk write supported, though only with parameter data strings (i.e. no standard input support yet)
- Reset supported
- Control transfers not supported
- Config/Alt setting not working
- Very limited testing!
Useful Links
-- JohnGordon - 15 Jan 2005
- I-Appliance Camera Hacking Index - watch the threads with 1 2 many 4 all in the title
- I-Applicance BBS: Hacking the RED Dakota PV2 (with LCD) - the original thread
- cexx.org Dakota PV2 Page
- John Maushammer's Dakota PV2 Information
- Windows tool to download the whole 16MB flash over USB
- PV2 Information from digitalfluff.net