Firmware Disassembly

The eval period on my USB sniffer program ran out (and I can't figure out where they leave a breadcrumb so I can cleanly reinstall :), but for what it's worth, this is the profile it reports when the camera is in this mode : Port1: USB Mass Storage Device Hub Power: Self Power Number of Ports: 2 Power switching: None Compound device: No Over-current Protection: Individual Device Descriptor USB Version: 2.0 Device Class: (0) Reserved (defined in Interface Descriptor) Device Subclass: 0 Device Protocol: 0 Max Packet Size: 0x40 (64) bytes Vendor: 0x167b () Product ID: 0x2002 Product Version: 0x0000 Manufacturer: 1 0x0409: Pure Digital Inc. Product: 2 0x0409: Saturn SerialNumber: 3 0x0409: PS5000010 Number of Configurations: 1 Connection Status: Device Connected Current Configuration: 1 Device Bus Speed: Full Device Address: 0x01 Number of Open Pipes: 2 Configuration Descriptor (1) Total Length: 32 bytes Number of Interfaces: 1 Configuration Value: 1 Configuration: 0 Attributes: 0x80 Bus Powered Max Power: 0x30 (96 Ma) Interface Descriptor (0) Interface Number: 0 Alternate Setting: 0x00 Number of Endpoints: 0x02 Interface Class: (8) Storage Interface Subclass: 5 Interface Protocol: 80 Interface: 0 Endpoint Descriptor (Addr: 0x02) Endpoint Address: 0x02, Output Transfer Type: Bulk Max Packet Size: 0x0040 (64) bytes Interval: 0x00 Endpoint Descriptor (Addr: 0x82) Endpoint Address: 0x82, Input Transfer Type: Bulk Max Packet Size: 0x0040 (64) bytes Interval: 0x00

Nice job CVSfan! Clearly this discovery is the labor of your dedicated disassembly work, and I for one say thanks! I'll definitely add a button to Ops for this, so people don't have to recall the values. I'm even considering a writing a small program that does nothing else but an automatic "Open, Unlock, Enable Mass Storage, Close". Anybody interested?

Excellent CVSfan!!! BillW, Only if you also bump resolution - but not as high as 640. I think I am going to settle on 448. That's what I used in my la-*test*-('") Preying Praying Mantis Video: forumer.com/viewtopic.php?t=1215" target="_blank">http://camerahacks.10.forumer.com/viewtopic.php?t=1215

brite_eye, I'm thinking that people will still use Ops to change the resolution, customize the cams, etc.,, since those are one-time operations. The mass storage thing would be when you just want to get at the movies. mconsidine, the VID matches the usual one, so no special setup in Ops is necessary, just the libusb .inf file. I tried out communications with Ops that way and it didn't work. I'm guessing it's because we're entering the Mass Storage mode in the non-standard way. Normally the camera probably spawns another thread that enables the mass storage init and deals with communications. As I understand it (without having read the disassembly) CVSfan's instruction forces an already established thread dealing with the event handler to always branch to the mass storage init and handling.

Thanks guys, but I need to thank morcheeba; this is the first I've ever looked at MIPS code and I don't think I would've been able to get this far without dismipper. BillW, Definitely having a separate app that does everything with a single click would be great. Probably combine the "view/set cam settings" along with the mount device (seems to be what most folks would be using; at least those that aren't hacking). Don't know if you're looking for Ops feature requests, but I've got some that would make my life easier: - Download memory: allow input in hex (both fields) and if possible make them remember previous locations and use a pop-up field. :D - Monitor command: would be nice to be able to recall previous commands, e.g. last 9 or so. - Need a memory monitor, similar to download memory but something that will continously poll until cancelled. Would be nice if the "period" could controlled. Whatever is easiest, nothing fancy. Don't know what the minimum time is to dump memory to file, download file from camera, append data to file in OS, but if possible make period adjustable in millisecs. Maybe even add a couple of fields to Memory Download to enable continous fetching and a time field. 8)

quoting CVSfan function=0x800058e8,"Determine recording rates?" var=0x80138fe8, "w- ?recording/compression rate based on image size - 2148765672" var=0x80138fec, "w- ?recording/compression rate based on FPS and soft-limit" 00138fe8: 4E 00 00 00 1E 00 00 00 (default camera) : 8E 00 00 00 36 00 00 00 (9 minutes, 640x480) : 9E 00 00 00 3C 00 00 00 (10 minutes, 640x480) : 3E 01 00 00 78 00 00 00 (20 minutes, 640x480) : 02 01 00 00 61 00 00 00 (60 minutes, 640x480, 0x1c0=1) : F0 04 00 00 DA 01 00 00 (60 minutes, 640x480, 0x1c0=1, 0x1bf=1) : 2A 00 00 00 10 00 00 00 (255 mins, 640x480, 0x1c0=7f, 0x1bf=1) looking at 0x80138fec at 9, 10, & 20 minutes 8Eh=142, 9eh=158, 13eh=318 the differance between 9 & 10 minutes is just over 10% 158 (10minutes) is just under 1/2 of 318 (20minutes) it appears to be a fixed number based on time, 0x80138fec 36h=54, 3ch=60, 78h=120 following the same pattern. you should be able to predict these number's before making a change will have to compare video size/bit rate at these settings. wonder what effects changing fps & x,y settings would have on them

Definitely having a separate app that does everything with a single click would be great. Probably combine the "view/set cam settings" along with the mount device (seems to be what most folks would be using; at least those that aren't hacking). I'm thinking something *super* basic, so I'll probably even skip the settings part. I don't want to intrude too much on the featurespace in Ops and Drmn4ea's upcoming work. Regarding the feature requests: - Download memory: sensible enough. I'll set it to look for a prefixed 0x to detect hex input. - Monitor command: I'll look into converting those into comboboxes that remember. I'll likely get around to this in a couple releases. - Memory monitor: Interesting, though it's a real pain to do something like that in an MFC program. I'll look into it, but no promises.

BillW, good choice ignoring my request (and others too) for adding settings changes to quick unlock enable mass storage. I wasn't thinking that once changed it is permanent until I change it again. To really be usefull the mass storage needs to be enabled in permanent firmware - Is there any way yet to accomplish firmware changes on flash?

On Linux (Fedora 3), going through this routine to get the camera into mass storage mode works the same. A directory listing using ops-for-linux shows a NO_NAME directory entry and a dialog box comes up saying something to the effect that "photographs are one this device - do you want to import them?" I did not have gphoto or the freeware Zoran driver installed, so I can't yet report on what they might have shown. Again, fwiw.

carpespasm: might it be possible to automate the "press any key" part from within Ops? so it can be fully automated? Can't you simulate playback by using a monitor command? zapped: sci x (where x is a the number of the video you want to preview) http://camerahacks.10.forumer.com/viewtopic.php?t=792

Eye, there's no way yet to change the firmware. To be honest I'm pretty scared of the remaining USB commands that look promising. I don't think I can probe them the way I have the other commands without killing more than a couple cams. I eventually plan to get into the disassembly and see what I can glean from it about these commands. I have a feeling it will be mostly uphill though. :(

Couldn't you cut the WR trace to the Flash, then wire a high value resistor to make it read only by default, and install a switch to connect the pin back to the original trace?

I guess I could, but it would make command failures fairly meaningless... eg. Did that last command I tried fail because it couldn't write the firmware to flash, or because I formatted it wrong? Up until now I've had other analogous safe commands to try. File downloads are pretty well the same syntax as file uploads. Flash reads are pretty much the same syntax as flash writes. etc. It looks like this cam protects the firmware from everything except a "update firmware from inserted media" upgrade... that's what the remaining firmware-related usb functions look like anyway. To make matters worse, it appears that the firmware we have access to isn't the same as the on-flash version. It's been relocated or modified in-place or something, according to posts I've read. Like I said, it's an uphill journey!

View Full Version: Firmware Disassembly