PV2 USB Command Analysis

Pure Digital's Ritz Camera Dakota PV2 LCD variant

[camera pic]


First off, if you're new to the nitty-gritty of USB, I'd recommend the excellent USB-in-a-nutshell document.

USB has two main methods of communication -- a structured interface for sending commands, and a bulk interface for sending data. The old camera used both of these methods for their intended purposes, but the new camera uses only a bulk interface for its communications (except, to maintain compatibility, it still uses the command structure for device reset and enumeration).

It appears that this camera uses a variant of the "Mass Storage Bulk Only" specification (other related specs here).  I know what you're thinking -- this is a camera and not a "mass storage" device (like an external hard drive).  Well, I'm still investigating! This spec looks like a wrapper for getting commands over the bulk pipe, so it could just as easily carry camera commands as it can carry mass-storage commands.

daBass traced the communications to a similar SMaL-based camera (a Philips-Branded camera, also with an LCD, but obviously not with the same PureDigital firmware). This was helpful in locating the code that matched for the magic "LaMS" signature, and will be helpful as we attempt to document the commands.  My firmware disassembly will also help, too -- especially if there is something tricky!

It appears that commands can vary in size. So far, I've only partially documented one command.  I'm not sure what it is exactly, but I can download a megabyte of data from it. I think that data is coming from SDRAM.

Mass Storage Bulk Only
The "Mass Storage Bulk Only" document mentioned above defines two packet types.


The Command Block Wrapper (CBW):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature ("LaMS")
4-7
 dCBWTag
8-11
 dCBWDataTransferLength
12
 bmCBWFlags
13
 Reserved (0)
 bCBWLUN
14
 Reserved(0)
 bCBWCBLength
15-30
 CBWCB


The dCBWSignature used deviates from the standard (43425355h = "CBSW"). This is probably just so that the device doesn't break real bulk-storage drivers.

The dCBWTag can be anything the host wants. It is simply echoed back to associate the CSW with the CBW.

The DCBWDataTransferLength is just a transfer length, in bytes, LSB first.

The bmCBWFlag indicates direction of the data transfer. If bit 7 is set, the transfer if from the camera to the host; otherwise it is from the host to the camera. Bits 6-0 are not used and set to zero. Although the lower bits may be used in some implementations, it looks like only the 7th bit is used by the PV2 (this statement supported by experimentation and code analysis -- neither of which were thorough).

bCBWLUN is the Logical Unit Number. The firmware compares this value with $00 and $04, suggesting that the PV2 supports at least two unit numbers (I don't know what those two units could be, though -- internal and external memory on SMaL's non-disposable cameras?)

bCBWCBLength is the length of the following command block. Changing this does not affect the length of the CSW packet (in the spec, it is always 31 bytes). The only legal values are supposedly 1-16, but the PV2 doesn't seem to check it.


The Command Status Wrapper (CSW):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature ("LaMS")
4-7
 dCBWTag
8-11
 dCSWDataResidue
12
 bCSWStatus


The dCBWSignature and dCBWTag words are described above.

dCSWDataResidue is the difference between the amount of data expected (dCBWDataTransferLength) and the actual number of data bytes processed or sent by the device. It should never be larger than dCBWDataTransferLength.  The PV2 appears to not follow the spec and instead just return the number of data bytes.

bCSWStatus indicates the success or failure of the command.  The spec defines 00 as a successful command completion, 01 as a command failure, 02 as a phase error, reserves all other values. The PV2 does not obey this - it definitely returns many many other codes, and I'm not even sure that 00 is a success. Disassembling the firmware confirmed that this byte is a return code.


Phase Flowchart
The above-mentioned "Mass Storage Bulk Only" document also defines a flow chart that indicates what packet gets transfered when. The error recovery mechanism is an inelegant reset -- that's something that I've seen the camera do while I've been messing with it.


Possible Command Codes
By analyzing the code, I found all the valid command codes.  I don't know what they all do yet, but anything other than these commands will return an error code of $60. (that is, if another error doesn't take precedence).

An interesting note from BillW: "The camera has usb routines to read/write/delete files, make directories, change directories, etc., from usb, but there appears to be no way to get a directory listing via USB. The foxz2 drivers query the FAT in the flash filesystem directly whenever they want to get a filename and filelength, similar to PV2Tool. (although foxz2 uses the camera routines for actual file manipulation, unlike PV2Tool)."

Command
 Parameters
Expected
DataTransferLength
   Function
 Calls Function
$10

verified
 8-11, 12
 can be determined by header
 Beeps, opens shutter, takes a picture, closes shutter (verified).
A couple of seconds delay, no photo flash. Stores in FLASH memory, but does not make a thumbnail. Returns compressed version with header.
 $2d, which calls $1d
may call $23
will call $0F
$19
verified
by a courageous BillW
 8-11, 12, 15
17-29 is a null-terminated filename
 whatever is specified
Takes a while, so use a long timeout before reading the response.
 File system format. Loads and restores all files found in the filename table (all the root directory files) so they are preserved. Pictures are erased. Not be sensitive to filename. Looks more sensitive to LUN (=1 or not), which makes sense because you wouldn't preserve system files residing on external drives. Data probably not recoverable from this format (probably flash erase).
 $28, which calls $26 and $24
$26

verified
 8-11, 12, 13
 reading from camera:
whatever is specified
writing to camera: should be a multiple of $100		 Writes eventually call the same routine that command $28 does - executes a program immediately. Doesn't return a status byte. Works in bootloader mode.

Reads do something different? Bootloader returns $61 if read, length = 0 & LUN = 1.
 ?
$28

verified
 12, 13, 17-20
Downloads code into SRAM (< $1000 bytes) & executes it. Code is stored at location $90.
LUN should be 0; anything else won't do anything.

Does not work in bootloader mode (returns error $60).
 may call $23
will call $0F
$51

Boot
loader
Only!
 seems not sensitive to LUN or byte 17
 must be <= 0x3F
or much bigger (0x40 hangs).
 Seems to be a bootloader-only command; no support in version 6410 standard firmware. I got this data back:

02 06 00 00 00 27 00 04 50 51 06 00 00 fc 3f 00
and then bytes 0x16 -> 0x4000 of FIRMWARE.BIN

Writes seem to return an error code of $62, even if a good copy of FIRMWARE.BIN (with the correct checksum) is used.
$52

verified
 LUN=0: 13, 8-11, 17-20
LUN=1 or 2: 12, 13, 8-11, 17-20
LUN=4: 13, 8-11*

17-20 is block number (size=256 for LUN=0, 512 otherwise)

* This is sensitive to 17-20,
but I didn't see it in code.

 whatever is specified Low-level data transfer. Four values for LUN are supported:
0 = SRAM memory
1 = FLASH memory
2 = I got an error - perhaps unsupported card memory
3 = Not used by firmware, I got error $b1
4 = SRAM memory?

Writing to FLASH memory works. I have only tried a 512-byte writes, which work perfectly.
When in bootloader mode (you'll know this because the camera doesn't power up and gives only two low beeps), the LUN doesn't matter and you'll  get back data from the file FIRMWARE.BIN. It always starts from the beginning, so adjust the data transfer size appropriately (typically 0x1f200 - 0x20000). Not sure if this is actually read from FLASH at the time of the command, or if it is left over from when the file was copied into SDRAM and failed the checksum check.

Writing seems to always return an error code of $60, even when the firmware checksum is correct & the length is 0x1000 or 0x1f200. If I can get this to work, it might be what's needed to restore a broken camera.
 may call $23
will call $0F
$54

verified
 		8-11, 12, 15.
17-29 is a null-terminated filename
 whatever is specified Open file for Read/Write.

Didn't work for me, but worked for others (thanks BillW). Returns status.
 $28, which calls either
write: $0b (delete file), $1b (write file)
read: $14 (read file)
$56

verified
 8-11, 12, 15.
17-29 is a null-terminated filename
 whatever is specified Delete file (verified).
The pictures-remaining counter increments, but the image serial number still increases.
 $28, which calls $0b
$57

verified
 8-11, 12, 15.
17-29 is a null-terminated filename
 whatever is specified mkdir (verified).
 $28, which calls $1A
$58

verified
 8-11, 12, 15.
17-29 is a null-terminated filename
 whatever is specified
 chdir (verified).
First do a chdir "/", then the filename (like "DCIM").
Use LUN=1 for the flash file system.
 $28, which calls $15
$5D
partially
verified
 12, 17, 18
 variable
 Calls a complicated function based on byte 17. See chart below.

Does not seem to work in bootloader mode (len > 0 hangs, otherwise returns error $64)
 $1E
$5E
partially
verified
 8-9, 12, 13, 17, 18
 should be 4
 Calls a simpler function based on byte 17 & returns a 32-bit word. See chart below.
 $2A
may call $23
will call $0F
$80

verified
 12
 $80
 Initialization routine needed before doing any other commands (except buffer overflow method)

Reading $80 bytes gets the challenge (either from NVRAM or FIRMWARE.BIN). You must then write back $80 bytes of the correct response before it will acknowledge any other commands.

Does not work in bootloader mode, but isn't needed.
 $32
The "may call $23, will call $0f" routine may be common to more commands than listed above; this could be generic or often-used.



Command $5D can call a variety of routines. If there is a webcam mode, I'd expect it in here.

Byte 17
 Calls function
04
 (related to 0B) maybe transfer something $200 bytes. Use only with LUN=1 (FLASH)
Or may be related to a transfer size of 4.
0A
 Returns some hardware registers:
$f722, $f723, $f726, $f727,  4 bytes read indirectly, $f10, $f71a, 8 uninitialized bytes
0B
 (related to 04) maybe transfer something $200 bytes. Use only with LUN=1 (FLASH)
Or may be related to a transfer size of 4.
0D
 complicated.
0E
verified
 Turns on the screen & displays an image! Write with length $10000, followed by 128 packets of 512 bytes to set the image. Format is exactly the same as in TFT files. Reads will turn on the display with whatever static is residing in memory @ $140000. Waits until the user presses a button, then turns off the screen & returns status block (0=shutter pressed, 1=display or delete pressed)
0F
 Slightly complicated.
10
 Slightly complicated.

BillW: "Appears just to make the pv2's speaker beep high,low,high. I looked at the firmware and I couldn't see anything else in there."
11
 Looks like it does some hardware stuff. It's precise descriptions like these that make my website so great.

BillW wildly speculates on this command: "I'd say it looks like a webcam mode.  After you've sent this command and requested status, the camera's shutter pops open and the camera becomes seemingly unresponsive. I took a look at the firmware - there's a bunch of hardware init, and then a loop with more hardware fiddling going on."
12
 very long function.
otherwise
 causes a beep.



Command $5E returns one of a variety of 32-bit words, least significant byte first. Byte 17 selects what data to return -- many of the values are static, some are based on the LUN, and others are based on byte 18.

By analyzing the code, there were only some values for byte 17 that I thought would be valid -- but when I tried reading things I thought would return an error code, I got data back without an error. Hmm...

Byte 17 Description Based on
 Example (byte order)
07
 Image counter
 LUN=0
 Might be triggered by LUN=0 rather than byte17=07
0D
 Firmware version
 static
 64 10 00 00
13
 hardware reg $F710
=camera hardware version
06 00 00 00
14
static
 06 00 00 00
15
 hardware reg $F13A
=camera type ID
27 00 00 00
16
 Battery strength: $64=full, 0=empty
(thanks BillW)
64 00 00 00
17
 hardware reg $F718, bit 3
01 00 00 00
18
static
 02 00 00 00
19
static
 05 00 00 00
1A
static
 09 00 00 00
1B
LUN
 11 00 00 00
1C
static
 00 00 2c 00
1D
LUN
 00 80 00 00
1E
LUN
 20 00 00 00
1F
 hardware reg $F30B
00 00 00 00
20
LUN
 00 00 00 00
21
LUN
 73 00 00 00
22
 Query if a particular LUN is supported. (thanks BillW)
This way you can tell if the camera has internal memory
and/or a memory card.  1=supported, 0=unsupported.
Uses LUN 1 or 2.
 LUN
 01 00 00 00
3A
LUN
 01 00 00 00
3B
LUN
 1e 00 00 00
3C
 not expected.
05 00 00 00
3D
 not expected.
01 00 00 00
3E
 not expected.
00 00 00 00
3F
 not expected.
00 00 00 00
otherwise
 return error $B6 (not seen!)




Sample Transfer - buffer overflow before enabling full communications
Looking through daBass's similar-camera trace,  we found a command that would return data back from the PV2.

Command to camera (31 bytes):
4c 61 4d 53 1d ba ab 1d 00 02 00 00 80 00 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Assuming this fits the Bulk-only protocol, the transmitted data looks like:

The Command Block Wrapper (CPW):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature
4c 61 4d 53 = "LaMS"
 4-7
 dCBWTag
I used 1d ba ab 1d
8-11
 dCBWDataTransferLength
00 02 00 00 = 512 bytes (LSB first)
12
 bmCBWFlags
80
13
 Reserved (0)
0
 bCBWLUN
0
14
 Reserved(0)
0
 bCBWCBLength
00
15-30
 CBWCB
52 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

The camera returns (525 bytes):
40 00 00 00 ce 29 15 a2 7a d8 d2 40 0c e3 8a 9a 84 93 2d ae ef c1 99 ab 6c 85 ef f7 d9 4d a1 5e
2a 40 67 f2 0f ff be 46 2d 2f c5 c9 ed c0 0c fc 6e ec cc f8 e1 eb 2c 03 64 df 1d a3 b3 0b 42 fc
40 be 07 19 1c ac c4 e2 93 ed 3a 04 55 31 f3 92 23 f7 65 fb 59 7c e0 b6 97 d3 78 2f b1 70 b5 04
81 9a a2 79 75 e4 ba 12 0f 49 6b 21 09 4d aa c6 98 02 93 e9 aa 7c cb 24 a5 39 b0 8a 63 4c 4b 79
33 33 b1 f3 33 13 33 23 12 33 32 d2 31 33 26 27 13 57 a2 b6 33 33 73 33 33 12 9a b3 33 33 33 13
31 19 a2 77 73 00 23 33 33 33 23 33 33 17 33 33 57 37 72 7a b3 13 6b 28 33 37 37 13 93 3f 22 23
b3 bb 33 31 33 33 36 0b 33 f3 21 33 37 31 35 32 33 33 77 32 23 9a 7b 33 35 33 27 23 13 3b 22 3a
63 23 23 22 3b 13 75 37 1b 33 62 63 31 31 73 b5 b1 33 22 33 23 31 22 33 32 39 32 f3 13 63 32 2f
cd cd 6c 6e 80 6c ec ee 5c cd 0e ce ce cc ee 86 cc d8 cc cd 55 cc ce ef cd d9 4c ec 84 dc ec cc
d4 cd e8 6e c7 cc de 8e 4e 4c 56 cd ec c4 8c c8 4c cd ce 8c 48 8c cc c6 ce d8 ed cd 8d 8c d8 88
97 c5 c9 cc dc 8f cc dc dc 4d ce ce 4c cc 4c ee 10 5c ce cc cc c8 fc c8 cc c4 ec ec dd ca cc 8c
c8 c8 ce 4e 98 8d ed c4 cc cc ee 4c cc cc cc 4c cc 55 ec cc d8 89 c5 6e cc c1 ce 5c d8 9c dc 8c
de e9 e4 cc 8d cc 4c c4 8c dc ee cc c4 cc c4 cc 4d 4c ec cc ce d9 cc 4c 54 cc ce ae 9c 84 84 44
e8 5c cc cc 48 c8 ec c4 c7 dc ce ce 9d 5c ee 8c 5d 0c ec cc e9 cc cc c8 d5 84 e5 cc 9c ce c2 ce
dc ce 0e c4 9c 5d c4 cd 6f d8 cc cd cc d4 b4 cc cd 4c cd ce c8 9c 4c 4c cc fc cc ac d4 88 88 e8
ec c2 44 cc 58 cc e4 cd 0c cc c4 ec 4c 8d cc cd cc dc cc ac 8c 4c ee c4 9c a9 dc cc 4c c4 4c ec
4c 61 4d 53 1d ba ab 1d 00 02 00 00 64

The Command Status Wrapper (CSW) that was returned (in purple, at the end of the data):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature ("LaMS")
4c 61 4d 53
4-7
 dCBWTag
1d ba ab 1d
8-11
 dCSWDataResidue
00 02 00 00
12
 bCSWStatus
64


Before the full transfer mode is enabled, limited communication is possible. The command code is ignored (unless it is $80, see below), and status code $64, indicating that full transfer mode has not yet been enabled, is always returned.

I suspect that this mode only meant to send back 4 bytes (the $40 00 00 00 seen above), but if more data is asked for (up to about 2.75 MB), it will be transfered.  The data sent always begins at address $140000 in SDRAM, so you are limited to items in memory that are stored at higher addresses. This data includes both compressed and uncompressed versions of the most recent picture taken, plus the a TFT thumbnail of the picture. This is of limited usefulness since it returns only the last picture taken, and only if the camera has not been powered down since then.



Authentication Method Analysis
This method of restricting a photographer's access to their own pictures is very similar to the method previously used.  A secret handshake, or authentication procedure, is used. Without knowledge of this method, it would be impossible to make the camera interoperate with a other devices, so a photographer couldn't retrieve his or her pictures. For those interested in the legal ramifications of this, please see my DMCA page.

This authentication method differs from the older camera in two ways:
So, on the face of it, the security looks pretty good. There are countless challenges and responses possible, and no algorithm is stored in the camera to make any sense of it. A code analysis shows that the correct response is only stored in an area of memory retrievable without authentication for only a split-second -- as soon as the program determines it is invalid, it is erased from this section of memory.

One major weakness is that, while they have the ability to make every camera use different challenges and responses, it appears that many (in fact, all four that I've seen) use the same values. This is probably something done to make manufacturing of the initial units easier -- I fully expect newer cameras to use varied values.

There are always the possibility for side attacks (and I've identified two well-known ones as feasible right off the bat), so this isn't NSA-level (or even ATM-level) security, but it is enough to deter most users. The most determined ones (like me!) can always get the necessary correct response by desoldering the FLASH memory and examining it closely.


Enabling the Full Interface - Command $80
Like the previous version of this camera, a special handshake must occur before regular commands. The basic transaction consists is still a two step process: first, the user asks the camera for a 128-byte challenge message (a challenge). Then, the user determines the proper 128-byte to return to the camera (the response). The camera compares what it got with an expected value (kept secretly in memory), and if the two match, data transfers will be enabled.

Challenge
The challenge is requested by issuing a read command $80 of $80 bytes:

Command:
4c 61 4d 53 1d ba ab 1d 80 00 00 00 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Interpreted as a Command Block Wrapper (CPW):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature
4c 61 4d 53 = "LaMS"
 4-7
 dCBWTag
I used 1d ba ab 1d
8-11
 dCBWDataTransferLength
80 00 00 00 = 512 bytes (LSB first)
12
 bmCBWFlags
80 (read)
13
 Reserved (0)
0
 bCBWLUN
0
14
 Reserved(0)
0
 bCBWCBLength
00
15-30
 CBWCB
80 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

For my two cameras (both are firmware version 6410, but they were bought 2000 miles and many months apart) both returned the following 128-byte challenge (along with, of course, a 13-byte command status wrapper at the end). There have been reports that one camera with firmware 6420 returned the same thing, but one camera with 6430 returned something different. (update: at least 6-8 challenge & response pairs have been identified)
02 29 23 be 84 e1 6c d6 ae 52 90 49 f1 f1 bb e9
eb b3 a6 db 3c 87 0c 3e 99 24 5e 0d 1c 06 b7 47
de b3 12 4d c8 43 bb 8b a6 1f 03 5a 7d 09 38 25
1f 5d d4 cb fc 96 f5 45 3b 13 0d 89 0a 1c db ae
32 20 9a 50 ee 40 78 36 fd 12 49 32 f6 9e 7d 49
dc ad 4f 14 f2 44 40 66 d0 6b c4 30 b7 32 3b a1
22 f6 22 91 9d e1 8b 1f da b0 ca 99 02 b9 72 9d
49 2c 80 7e c5 99 d5 e9 80 b2 ea c9 cc 53 bf 67
4c 61 4d 53 1d ba ab 1d 00 00 00 00 00

These numbers were made with the low-quality random number generator built in to many Microsoft products -- googling for portions of it returned the same sequence in a variety of uses.

Response
The second part of the handshake is returning the correct response.   I found the challenge value stored in the file "NVRAM.DAT" in the camera's flash memory. Analyzing the code indicated that this value was tagged with the identifier $0011, and that the proper response (also stored in the same file) was tagged with $0012.

Although this looks random, too, it was not generated by the same random number generator used to produce the challenge. It probably generated by some secret mathematical algorithm that uses the challenge as an input. (This sounds obvious, but Pure Digital could have used other random numbers here.)

Transferring the response over USB actually requires a few steps.

The first step of the response is to issue a write command $80 of $80 bytes:
4c 61 4d 53 1d ba ab 1d 80 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Interpreted as a Command Block Wrapper (CPW):
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature
4c 61 4d 53 = "LaMS"
 4-7
 dCBWTag
I used 1d ba ab 1d
8-11
 dCBWDataTransferLength
80 00 00 00 = 512 bytes (LSB first)
12
 bmCBWFlags
00 (write)
13
 Reserved (0)
0
 bCBWLUN
0
14
 Reserved(0)
0
 bCBWCBLength
00
15-30
 CBWCB
80 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Next, send the 128 bytes of data. For my firmware (and the above challenge) I found the correct response was:
14 37 1d 0f ce 29 15 a2 7a d8 d2 40 0c e3 8a 9a
84 93 2d ae ef c1 99 ab 6c 85 ef f7 d9 4d a1 5e
2a 40 67 f2 0f ff be 46 2d 2f c5 c9 ed c0 0c fc
6e ec cc f8 e1 eb 2c 03 64 df 1d a3 b3 0b 42 fc
40 be 07 19 1c ac c4 e2 93 ed 3a 04 55 31 f3 92
23 f7 65 fb 59 7c e0 b6 97 d3 78 2f b1 70 b5 04
81 9a a2 79 75 e4 ba 12 0f 49 6b 21 09 4d aa c6
98 02 93 e9 aa 7c cb 24 a5 39 b0 8a 63 4c 4b 79

The camera will then send back a command status wrapper:
byte \ bit
 7
 6
 5
 4
 3
 2
 1
 0
0-3
 dCBWSignature ("LaMS")
4c 61 4d 53
4-7
 dCBWTag
1d ba ab 1d
8-11
 dCSWDataResidue
00 00 00 00
12
 bCSWStatus
00

The Status byte of $00 indicates the handshake was successful; $b9 indicates that it was unsuccessful.

If your camera has a different challenge, then you are partially out of luck.  Drmn4ea has a posted a method of reading the FIRMWARE.BIN file by shorting out pushbutton SW1 (that's a button that has a space on the camera's printed circuit board, but isn't installed). I suspect that his method will also be able to retrieve the correct response.

I've got some ideas here I'll organize and post.


Reading Flash Memory - Command $52
Once authenticated, it is relatively simple to read the contents of the FLASH memory. This image can then be mounted and read as a virtual disk. On Mac OS X, simply give the name an extension of ".iso" and double-click on the file.  Linux can mount files easily, and I'm not so sure about Windows. You will get the same image that I got when I removed the FLASH memory chip and read it with a dedicated reader -- this includes the files necessary to run the camera (FIRMWARE.BIN & others) plus the photographic image data. This data is stored in a proprietary compressed format, so it is not usable yet.  I've got more details on the flash memory.

Command $52 is a low-level data transfer. The transfer length, in bytes, is stored in (surprise!) the dCBWDataTransferLength field. The starting address, specified as a 512-byte block number, is specified in bytes 17-20. The LUN specifies what kind of memory to access:

0=SRAM memory
1=FLASH memory
2=I got an error. May be some sort of memory card that is not supported with this version of the camera.
3=I got an error. Ditto.

I was able to read all 16 megabytes of flash memory by reading 128KB chunks. Writing works, too, but I've only tried 512-byte blocks.

Brite_eye adds: "In an effort to get uncompressed bayer image off my unlocked Ritz camera using old USBpoker method I found that offsets were different due to firmware unlock patch of 01 to 02. Before unlocking a $52 works the same for LUN=0 or LUN=4 both returning compressed image at $12000 and bayer at $120000 for SDRAM. After firmware unlock patch, LUN=0 reads SRAM, while LUN=4 reads SDRAM starting at 0 with compressed image at $152000 and bayer at $260000 as shown in morcheeba's SDRAM memory map. A locked camera is forced to start at $140000 hiding firmware code. All offsets are for 6410 only."


Credit: daBass captured the magic data from his camera, and then was the first to get a response from the PV2. Great work! Knowing that "LaMS" was part of the command structure immensely helped me find the corresponding code in the firmware.

BillW did lots of exploration and more USB captures from similar cameras and explored the commands.

Missing from this page: a description of which pipes/configurations to send data to. See daBass's post on the LinuxHacker BBS. I'll eventually post my OSX program once I get it to do something useful.


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