I-Appliance BBS
The Official Source for Internet Appliance Upgrades and Mods

Click Here!
BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.netReply to Thread | Printer |

Home / MISC Areas / Cameras
Hacking the RED Dakota PV2 (with LCD)
The new red PureDigital Dakota with preview LCD are available and ready for the hacking

New MessageHacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
The 150+ post Dakota thread seems full enough...how about we discuss the new red one here?

Morcheeba's initial snooping is covered here:
http://www.maushammer.com/systems/dakotadigital/DakotaDigital.html#lcd

with pictures of teardown here:
http://www.maushammer.com/systems/dakotadigital/pv2-disassembly.html

The chip is made by SMaL of "Ultra Pocket" fame (really thin cameras):
http://www.smalcamera.com/products.html
Given the specs of the camera, the SMaL 'kit' used is the Ultra-Pocket 3.

I've checked SMaL's whole web site and found no useful technical information of any kind...the best thing is the PDF for the kit, which just lists stats.

Regarding the camera's design: as discussed earlier, it sports a totally new case and new internal design. This design is much smarter, in my opinion. The components appear to be of a high quality (an actual metal button instead of a piece of copper that slides back and forth for a power button). The battery compartment was frustrating until I re-read Morcheeba's teardown (stick a pin in the hole and slide the piece of plastic inside there). Taking the cover apart is quick once you find the screws. The main board includes the SMaL chip (which appears to do everything but control the LCD), the flash system (no more flash daughterboard), and so on. There is one perpendicular narrow daughterboard that includes the battery connection and the shutter button. The USB connector is the same. I had to dremel mine a bit wider (as I've done to my original Dakota) to make it fit my M100 connector. It does a double-beep on connect and disconnect. My SMaL chip is labeled:
(SMaL)
AIC0021B
02TWN503
C66051 00

Sadly, google has never heard of a "AIC0021B".

Regarding the camera's operation: I like it. The flash seems to charge faster, the LCD is fairly decent, and the picture quality seems about the same (as far as I can tell from looking at the LCD). All the original Dakota features are here, just with an LCD. As found by Morcheeba, pressing all three buttons during power-on gives you some information. I got:
FIRMWARE 6410
HARDWARE 06
TYPEID 27
ID DAA041940523
Once again, TYPEID is the USB Product ID 0x0027.

Regarding actually getting the thing to work: the first place I went was gPhoto. As you'll find out, this wasn't fruitful. gPhoto supports some SMaL-based cameras, but looking at the source code, these appear to be the original Ultra-Pocket-based cameras, which have a max resolution of 640x480. I thought I'd try using it anyway, so I told gPhoto to use the Red Dakota's USB information. The vendor ID is the same (0x0DCA), but this camera's product ID is 0x0027. So I set USB_DEVICE_ID_ULTRAPOCKET to 0x0027 in camlibs/smal/smal.h, recompiled libgphoto2, and tried it out. It now detected that I had the Fuji Axia Eyeplate (which is the name of the entry I fiddled with), but it can't do anything at all to it (I get error -35, "Error writing to port"). Hence, this was a total bust; the interface just isn't compatible.

When I bought the camera, I asked the clerk about the "developing" process. They do use the same machine to dump the new Dakota as the old one. However, they required a software upgrade to support it. "A lady came out" to upgrade the software on their equipment. So the good news is that the only change needed is in software, the bad news is that we have no idea what this is.

Any ideas where to go from here?

05-31-2004 22:38:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
Incidentally, here is the listing for the camera from /proc/bus/usb/devices:

T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 6 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=0ms

05-31-2004 23:00:14

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Silver
Profile
I also picked up one of the new red PV2 cams today in Seattle. Doing a three-button power on gets me the following:

FIRMWARE 6410
HARDWARE 06
TYPEID 27
ID DAA041901004

Looks to be a fun camera. I hope we can find a driver for it.


Silver

06-01-2004 00:56:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) DrDootz
Profile
All,
Just got a PV2 in South Florida at a Wolf camera store. Girl didn't know anything about processing. Preview LCD is pretty good quality of last picture taken.
Tried Blue camera Dakota cable and Windows discovered new device Digital Camera looking for driver. Tried bunch of drivers from Asian web sites but none worked.
Hopefully a software hack will be discovered as they become more plentiful.

Regards,

Dr. Dootz

06-01-2004 08:22:22

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) shiny_razor
Profile
Silver,
where in Seattle did you find them?
06-01-2004 17:37:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) shiny_razor
Profile
I found out one of the vendors that made a cam using the Ultra-Pocket 3 kit:
http://www.letsgodigital.org/en/news/articles/story_1209.html

Of course they don't have the drivers for the Foxz1 on their webpage. I tried to write them and ask for it, but their feedback form geeked on me.

I read on their parent site that they started selling these at Target... I'm contemplating buying one, copying the driver CD and then returning it. It would serve them right for not putting drivers on their site. That is just idiotic.

06-01-2004 18:21:56

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Silver
Profile
shiny_razor, I found them at Kits Camera in the Alderwood mall; $18.99. They were shown in the Kits ad in this Sunday's paper. They didn't even mention that I should bring the camera back for processing.

I also found an old USB-PS2 adaptor that I'm going to sacrifice to make an interface cable. Next stop, Radio Shack.


Silver

06-01-2004 22:07:31

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Kudzu
Profile

It would serve them right for not putting drivers on their site. That is just idiotic.

They did have drivers available at one time, on their Japanese language site.

http://www.che-ez.com/download/driver/che-ez!foxz/

They were supposed to have been introduced in March, so why they would take them down is anyone's guess.

06-02-2004 01:34:52

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) 02U2
Profile
Alderwood mall you say...

less than 15 minutes drive away!

Naw, I'll let shiny razor buy it (them) I've got WAY to many cameras.

06-02-2004 09:07:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) 02U2
Profile
BTW LOL, I'm sitting about 50'away from a small Kits camera BM right now while using the malls free WiFi internet access writing this! AWESOME download speeds!
06-02-2004 09:11:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
Regarding buying that Ultra-Pocket3-based camera: If you do buy it with intent to return, you should do more than just copy the driver CD. It would be much better if you took some pictures, ran a USB snooping program like USBSnoopy, and logged the dumping process. That way, we know the basic protocol the SMaL chipset uses and could start poking at the Dakota. It would be much harder to coax this information out of inert drivers we can't run (for lack of the camera).

Does the firmware reside on the separate flash chip (the one under the LCD) or within the SMaL controller? If it is the former, we could dump the whole thing and step through it, as was done for the blue Dakota. If it's on the SMaL controller, it's unclear how we would dump the firmware given that we lack the pinout to the controller.

06-02-2004 12:39:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 1 times) rangita
Profile
Also, I've found it's possible to get some drivers to think they service a different USB device. USB drivers seem to only care about the Vendor ID (VID) and Product ID (PID), and will try to drive whatever matches the expected VID-PID values. The Creative CardCam (which is based on the Ultra-Pocket 1) has drivers that store this information in a few INFs, and once in plaintext hex within a binary file. The VID was the same (since it was still SMaL based), but the PID for the CardCam was 0x0002 instead of the Dakota's 0x0027. I replaced all the instances of the PID with 0x0027 and the drivers suddenly thought the Dakota was its baby. Of course, the drivers didn't work at all, but this technique could possibly work on these UltraPocket3 drivers. We probably couldn't get pictures straight-away with this method, but we may get our foot in the door.
06-02-2004 12:47:16

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) shiny_razor
Profile
Hehe.

http://www.target.com/gp/detail.html/ref=br_1_5/601-4314602-2720932?%5Fencoding=UTF8&asin=B000216HQS

coming soon to a hack near you!

06-02-2004 17:21:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Synlor
Profile
I found the foxz drivers, they were still on the japanese website. http://www.che-ez.com/jp/download/ scroll down till you find the foxz thing. The files are all encoded or something, but once you run setup go into Program Files\Che-ez! Foxz\driver you can edit the inf file, which is in plain english. I did what other people mentioned above, changing the pid to 0x0027 in every location in the file. Finally I plugged the camera in, the install new hardware thing came up, I pointed it to the afermentioned directory with the edited inf file. It found the drivers and isntalled just fine. So now when I plug my camera in it shows in my computer... but once I click inside no files are found. So the computer is recognizing the camera, but no go for reading from it. Either we need to do more than changing the inf file for these drivers, or they won't work.
06-03-2004 19:05:16

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) shiny_razor
Profile
Yeah, usually just hacking the inf doesn't give you complete access to the camera, but at least it's a start!

Good find!

06-03-2004 19:14:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
I have found a thread that has a link to a generic photo transfer software on it. It might be useful in trying to get the pictures off the camera. I just got the new red one and the original blue one, but still waiting on the cables that I ordered off of e-bay (shipping takes too long).

Anyways, here's the link from the thread:

http://www.dps.uk.com/freeware_transferer.htm


Another thing, if the computer detects the camera but can't find any pictures on it, I would think that when PureDigital said they "will shortly release a model that incorporates stronger security measures aimed at preventing this sort of hacking." The security measures they might be talking about is changing how the contents of the memory are written and read instead of changing the entire process of extracting the pictures out of the camera and into their processing machine and only having to upgrade software.


Quoted from rangita:


When I bought the camera, I asked the clerk about the "developing" process. They do use the same machine to dump the new Dakota as the old one. However, they required a software upgrade to support it. "A lady came out" to upgrade the software on their equipment. So the good news is that the only change needed is in software, the bad news is that we have no idea what this is.

Any ideas where to go from here?


Well, the "lady that came out" to upgrade the software on their equpiment could have patched the software to decrypt the contents of the extracted memory. Or instead of the memory being encrypted, the memory could have a certain part missing in it. Rendering it unreadable to a computer without the software that would add the certain missing part based on an algorithim or just the same "piece of data". Whether the missing piece is at the beginning of the entire contents, every picture, or sector. Something like when you delete a file on your hdd, it only removes the first part of the file, pointing to where the rest of the contents are. Or something to that extent. Another possibility is that they might use a different cable wiring that has a switch on it to be able to switch from the old cable layout to the new cable layout, still using usb port and the such. If you want to take the easy route out, you could always become REALLY good friends with one of the managers or employees and get a copy of the software


Quote from rangita:


The 150+ post Dakota thread seems full enough...how about we discuss the new red one here?

Wonder how many total are going to be here when this project nears an end ?


My brain hurts now after thinking for quite a while and having a rough day. If any of this doesn't make sense, or is grammatically incorrect, I am too tired to fix it, figure it out on your own... Good luck on the project and keep up the good work!

06-03-2004 23:09:11

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
BTW, the little sticker covering up the connection port on the camera says "Camera does not connect to home computers." on blue one and a similar saying on the red one. Wonder if the blue one that I just picked up has the "new security" in it?
06-03-2004 23:15:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) zbeth
Profile
The first/hackable blue one had the same (or similar) sticker.

(Has anyone had success with the new blue?)

06-04-2004 11:36:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
What do you mean the "new blue"? From what I understand, there is only one blue make / model. What I mean by that is the electronics inside the old one is the same as in the new one with the same type case. If I'm not mistaken, of course. I wonder if they both got an upgrade, got a new case, but the processing machine still only needed a software upgrade. I have the original blue one with the chrome accents on the outside around the lense and where you put your fingrers in the front, not the one shown on the back of the Ritz catalog. The possibility doesn't surprise me.
06-04-2004 19:49:55

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
Found a site that has some USB developer tools on that could be of some help to you people out there until I get my cables.

http://www.usbdeveloper.com

It's got software as well as hardware tools that might be helpful. (not meant to be advertising)

06-04-2004 19:57:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) zbeth
Profile
Has anyone spotted a blue Dakota that looks like the catalog pic, marked PV2 and all?

I just bought one (from a Ritz in MA that had the red PV2s in stock) that _looks_ like the old blue Dakota..

06-04-2004 20:30:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Scapegoat
Profile
"you could always become REALLY good friends with one of the managers or employees and get a copy of the software"

...OR, has anyone considered trying to get a job at one of these places, working your way to the camera-reading machine itself, and then making like a corporate spy and running off with the software? The PC obviously has USB ports, A memory dongle would be all one might need, or perchance the install CD is even lying around the office.

I've been thinking about doing this, unfortunately I don't know as much as you guys (as far as what I would need to get.)

...or is this wrong??? Is it even possible? Anybody have any suggestions about this, because I'm quite serious about the prospects of this path.

06-04-2004 20:45:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) zmoz
Profile
I think you're taking this a bit too far. The point here is to get a cheap camera and have fun hacking it. You could just go down and buy a camera that works out of the box you know...(gasp)
06-05-2004 00:36:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
Quote from Scapegoat:

...OR, has anyone considered trying to get a job at one of these places, working your way to the camera-reading machine itself, and then making like a corporate spy and running off with the software? The PC obviously has USB ports, A memory dongle would be all one might need, or perchance the install CD is even lying around the office.

The problem with that is that is "stealing", but if you do manage to "run off with the software", if you distribute it, the Ritz or PureDigital people will try to sue you, put you in jail, and mangle you in any way they can legally... (or if nobody hears about it illegally)

The alternative would be to "permanently borrow" or temporarily take the software, make a copy (using a laptop in your car or w/e), put it back and use the stuff that's in the software after de-compiling it to create your own program. Without using their code or telling anyone that you looked at the program, of course, which would be an infringement of the copyright laws. (or something like that if I'm not mistaken) But the problem with that is it takes all of the fun out of figuring it all out on your own. I'm really eager to get into this as soon as I get my freakin cables that I ordered from e-bay.

Another thing, I'm downloading Linux (RedHat 2.1gb, Mandrake 2.1gb, and the College version 615mb) http://www.linuxiso.org and I was wondering if there is freeware out there that I could use to partition my hdd on the fly without using something like PartitionMagic. If anyone could offer some help, I would be much obliged.

06-05-2004 15:05:30

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
I have opened my PV2 up and I noticed that where the data port is, there only 7 out of 10 gold connectors actually connected to the circuitry.

Here's how it is layed out if you look at it from the front with the connectors on your right side, just as if someone were taking a picture of you with it:

1: Connected
2: Connected
3: Connected
4: Connected
5: Connected
6:
7: Connected
8:
9: Connected
10:

Also, there are some switches or something, that are missing there are 4 spaces for them under the SMaL chip, and one space is vacant. There are also some missing above the chip to the right of the silver capacitor (or at least I think that's what it is). Maybe if you connect them, they might do something like do a live preview or something to that extent (flashing the rom).

When I was trying to undo the lcd panel from the back, I tried to move the insanely huge flash capacitor out of the way and I heard it crack. I unscrewed the panel and moved the capacitor back, put the batteries back in and turned it on. (with the cover off) It started up, I took a picture and deleted it, turned it off and picked it up again. When I turned it around to look at it, it shocked the crap out of my finger. Those little things can hold quite a charge. I put my screwdriver across the two solder points to try to get it to get rid of the charge, when the screwdriver got to about 2/16 of an inch away from the two solder points, ther was a huge spark that sounded like a cap gun. It MELTED THE SOLDER that was there and left two gouges where the sparks were on my screwdriver. Now there are black burn-like marks around the solder points on the camera as well as the screwdriver. I thought I just fryed my camera in style, but all it did was pop, leave burns on the camera and screwdriver and leave a funky smell in the air. Anyways, I'm going to e-mail PureDigital to see if I can get the specs for this little monster and / or anything else.

06-05-2004 19:17:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Just got my hands on one of these at the Ritz in downtown Boston (Boylston st). Was going to try and interrogate the salesperson a bit about the reader device/software, but she was pretty busy. Haven't had time to play with it much yet, only immediately take it apart

One disappointing thing I notice is the lack of a ROM. Unless the firmware is stored on the NAND flash (which I doubt, since this flash requires that funky bad-block-mapping stuff), there will likely be no way of getting at it.

As madpyro mentions, a number of spaces left unpopulated - in particular, there are spaces for 2 extra pushbuttons, and of the others, the empty spaces for R4, R5, R7, R8 (leading to the SMaL chip) look the most interesting. When the camera is 'ready', shorting the contacts of SW1 causes the camera to beep 3 times, but I haven't noticed any other effect. (The camera still seems to work, so at least it wasn't a hacker trap - if I were a sufficiently malicious hardware designer, I'd leave an unpopulated switch just begging to be messed with, which would trigger a self-destruct.)

To madpyro - I didn't manage to zap myself on the original Dakota, but to this day there are weld-marks on my pliers where I used them to discharge the flash capacitor. Sounded like a gunshot and produced a blinding flash, our cat nearly hit the ceiling, and (when my vision returned to normal) there was a nice little charring pattern across the board. This time I got smart and used the pliers to nudge a 1 M-ohm resistor across the cap leads (then a 100k, then pliers) to avoid scaring the crap out of myself again.

06-05-2004 23:11:48

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
I discussed the red Dakota problems with a friend of mine (a computer engineer), who looked at the camera and some related datasheets. He came to the following conclusions:

- Regarding the firmware: The flash memory is byte-serial for both address and data, so the firmware couldn't be there. Thus, the firmware must be stored in an internal ROM within the SMaL chip. The SMaL chip is custom designed, and likely had to be flashed with the firmware after production. Since SMaL claims the chip can be programmed via USB, we may be able to read the firmware via USB (for verification).

- Regarding the physical chip: The chip, though it's innards and firmware are custom, is almost certainly in a standard package. It may share a pinout with similar, known chips. If the chip contains programmable memory, then there probably exists a standard reader for this package.

I think that if the USB-flashing is unavailable, the connector lines that aren't USB may be a firmware programmer connection of some sort, which could facilitate reading of the firmware.

madpyro, if this is your first install of Linux, you probably want to do this on a scratch machine. Contrary to what the zealots say, installing Linux isn't usually a romp through Happy Always-Works Land, especially when resizing of existing partitions is involved (resizing partitions is always a crapshoot, in my opinion). As for partitioning software, there appears to be a free trial of Partition Magic which should do what you need. I wouldn't trust any freeware to do something like that.

I'm going to try to figure out SUCR enough to write a command-line "USB Terminal" so we can try manually blathering incoherently to the camera.

06-06-2004 11:45:38

New MessageI just guessed the two "to be populated" switches are for "prev" and "past" buttons. (modified 0 times) newbee
Profile
When I saw those two empty spaces for switches, I instantly thought that they are for prev and past buttons because
1. I thought that it is possible from their ad.
2. the two buttons are placed right beside 'display' button, which makes them perfect candidates for "arrow" keys.

Oh well, just a thought.

06-06-2004 13:06:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
Rangita, I have an old system (350mhz, 64mb ram, 10gb hdd) that I will connect to my computer via an ethernet cable to back up my "important files". But the problem with that is the old pc doesn't have an OS on it because I planned on re-installing it, but it just freezes up or restarts on its own when I am in the installation process. I hav found a Windows Pre-Installation invironment boot cd. http://www.nu2.nu/pebuilder/ created by a very smart windows programmer up in denmark, I think. After I copy the files to the hdd of the old pc, I will re-partition the hdd (using fdisk on the new one) and install Linux. I think the Partition Magic trial doesn't let you save any changes. And yes, this is my first install of Linux (yay!). I have also heard of a boot cd for Linux that runs off of the cd much like the pre-installation environment. Also, I think if you tried every one of the unpopulated spots, there might be one that either flashes the rom or the other memory, or it could give you a live lcd preview. About the switches, newbee, I kindof aggree with you about that but the problem is figuring out which solder points to connect to each other to do that (4 solder points) which would be 6 possibilities, I think. but I can only see two of the soldier poinst acctually connecting to the copper in the board. If I remember correctly, it is the very left two on both. That could be a possibility, though. I might try to write a prog that gives the camera some commands and "snoops" around or whatever, but since I know only a little bit of Visual Basic, I will mostly use the dll's and ocx's to get the job done. I might not even write the prog since I am going to be busy installing Linux and reinstalling XP after I repartition. Keep up the good work people!
06-06-2004 14:33:56

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
The dump-out from testlibusb, if it's of use to anyone:

actually, forget it, this board totally messes up the formatting. I'll try to post something more legible (maybe SUCR commandline listing, if I can get one...perhaps a reboot is in order) a little later.

One thing I notice is there doesn't seem to be the composite-device structure like with the classic Dakota. Consistently 'No Packets' in USBSnoopy, although Windows recognized it as a Digital Camera and asks for drivers (I put it on libusb). The camera doesn't seem to give any indication (for me, at least) that it's connected to a computer, unlike to classic. Unless I unplug it and plug it back in; then it beeps once and the LED comes on for about 10 seconds, then goes out again.

06-06-2004 16:56:53

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Here we go... output of SUCR and testlibusb showing how the USB interface is laid out: http://cexx.org/dakota/pv2.htm (scroll down to 'USB info'). The usual Bulk In/Out interface, just like the classic Dakota, but lacking the Interrupt endpoint (hasn't been used, not by any hackers I know of anyway) and the Isochronous endpoints (Webcam data-out). Two possible configurations: one for 100mA of power from the USB port, one for 200mA...they seem identical otherwise.

When one of the configurations is set, the camera emits a two-tone beep, and the Ready light comes on and stays on. However, writing any commands to the cam results in an error message from libusb-win32 (probably indirectly; it's most likely generated by the Windows USB subsystem) :

LIBUSB_DLL error: error sending control message: win error: Data error (cyclic redundancy check)

Control transfers in USB include a CRC at the end (5-bit or 16-bit, depending on packet type, according to USB-in-a-nutshell), which as far as I know is generated at a low level (libusb...or even Windows itself?), and "should be" correct. Maybe this is one of the "enhanced security measures", the camera expecting bogus/encrypted/DMCAed CRCs generated by custom/hacked USB driver on the Ritz download box?

Or maybe I'm just talking out of my @ss, of course - can any USB experts shed some light on what would cause CRC errors? (Is the camera just taking the data as-is, and throwing back "Bad CRC" errors just to throw us off?)

Rangita mentioned the following error while trying the camera under gPhoto: error -35, "Error writing to port". Is it documented anywhere what an error -35 is...is this also the CRC error? (Then at least I know it isn't just me

06-06-2004 18:50:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
I've tested Drmn4ea's button observations and am getting the same effect. SW1 results in 3 beeps, SW4 nothing. In addition, SW1 does its 3 beeps regardless of state, even while doing the tutorial screen at boot-up. I propose that when we are prodding it over USB, we take a moment to try pressing the mystery button and see if it effects the camera's responses.

I have a (wild, unsubstantiated) example of why it may be related. I suspect designers implemented a "special state" the camera has to get into before allowing useful USB interaction. On the old Dakota (if I recall correctly), you had to "log in" with a four-byte code before it operated normally. It may be that the button puts the camera in this authorized state (in addition to the right USB action). This way, programmers could test the higher USB functions without having to "log in". I have no evidence for this idea whatsoever, and present it merely as an example of why the button may be related.

madpyro, if you don't have any NTFS partitions, you may be able to use "fips.exe", which I found with SuSE Linux. According to the SuSE readme: "Use this tool to change the size of DOS partitions...Two versions are available: fips15 [for FAT16] and fips20 [for FAT32, new]." You can get it here: ftp://ftp.sunsite.utk.edu/pub/linux/suse/i386/9.1/dosutils/fips/

06-06-2004 19:38:52

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
Drmn4ea, I have no idea what the root cause of the gphoto2 error -35 (known in libgphoto2 as GP_ERROR_IO_WRITE) was. Looking at the source for libgphoto2, it can only be caused when the libusb function usb_bulk_write() returns a values less than 0. The libusb documentation says that the function will "[Return the] number of bytes written on success or < 0 on error." Tearing open the libusb source, I find that a negative is returned if a ioctl() call returns a value less than 0, in which case it returns the negation of errno, the standard error number. This ioctl error number is what we need to confirm your hypothesis, but libgphoto2 throws it out. If one can tell libusb to be in some sort of debug mode (usb_debug >= 2), it will announce the ioctl error code. I'll see about making that happen.
06-06-2004 20:19:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
I have more information on the gphoto2 error. I tried it again after modified the libgphoto2 to announce the return values and call perror(). Last time I did it, I didn't notice that the FIRST time I try to talk to the camera, the write goes fine, but the expects a bulk read directly thereafter (which doesn't happen, of course). Thus, during this first run, I actually get an error -34, "Error reading...". Subsequent attempts result in the previously reported error -35 ("Error writing..."). The usb_bulk_write() call returns -1, and perror() prints "Broken pipe" in both cases.

This could be the same thing as the CRC failure...I have no idea how to compare those apples to these oranges.

06-06-2004 22:37:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
A little more playing... finally looked at the GPhoto code for the "similar" SMaL, it doesn't seem to use the bulk control endpoint at all--just send a 16-byte command packet directly on the bulk out (to the camera) endpoint, and slurp data back in on the corresponding in (from camera) endpoint. Emulating this in sucr, the write to bulk out works exactly once; then, any subsequent reads OR writes to the appropriate endpoints result in the familiar CRC error.

The data write seems to go "ok" up to a data length of 36 bytes. Attempting to write more than 36 bytes to the camera results in an error after the timeout period specified in usb_bulk_write:

LIBUSB_DLL error: timeout error writing to bulk endpoint 0x1: win error: Overlap
ped I/O operation is in progress.

Once this happens, all reads and writes produce this until it's unplugged and plugged back in.

In all of these cases, clearing a stall (usb_clear_halt) or resetting the endpoint (usb_resetep) has no effect.

I brought the cam into work where we happened to use the exact same little surface-mount switches for a past project (can rustle up part # if anyone wants it), and populated SW1 and SW4. If SW1 is held down while attaching the USB, the 2-tone beep upon setting configuration is replaced by a single high-pitch beep. No other effect apparent, unfortunately. Holding down other buttons doesn't seem to do anything.

To any USB gurus...is there anything magical about the number 36? Or is this likely to be a limit set by the camera?
Next steps....whoever's first finding a way to quickly clear/reset this thing in software, so that more bytes can be sent to it without replugging, gets to try maybe a "brute force byte stuffing until the CRC error goes away" approach. Snowflake's chance of this actually working, of course

Finally, I am wondering if a CRC error in Windows doesn't just mean that there was no response at all.

06-08-2004 23:19:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
When I took off the back of the camera, I noticed a little screw with this red, gooey crap on it. I messed around with it hoping it would do something, but all it does is adjust the brightness of the screen. But, there's an unpopulated spot next to it named VR1 while the one with the screw is VR2. I shocked my self twice yet again. First time, I didn't even touch the capacitor, which puzzles me, the second time, a spark reached out and bit my finger, leaving a blister that still burns 2 1/2 hours after it happened. I shorted out VR1 and all it did was turn the screen different colors.
06-09-2004 13:26:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
I too found the 36 byte limit. I modified the SMaL gphoto2 driver to allow me to specify command values via environment variables (a hack, but it was quick). I then left it cycling through the first & second bytes overnight - the rest of the bytes were zero. To get past the apparent locking up of the camera after the first write I unloaded and reloaded the UHCI module (usb-uhci). This seems to work, though not with 100% reliability.

Didn't get a single response from the camera all the way up to 0x03 in the second byte (when I killed it), but I noticed at some point later on that my camera's ID number had changed to 'LAMSSMAL0000' - I guess one of those commands affected the camera's ID somehow, but I don't know how.

I now have a small tool that I knocked up for Linux based on the libusb code in gphoto that allows me to send arbitrary strings of data to the camera's bulk endpoint. Thinking that I could try to set the ID back perhaps by writing a command followed by the string needed for the ID (thinking that perhaps LAMSSMAL0000 is what it does when the ID is nulled out), I tried to write the same commands. Haven't finished that yet, but so far I haven't had any luck here.

I was actually thinking that a simple little relay circuit controlled by the parallel port or something might solve the reset problem more elegantly too - the module trick eventually seems to stop working. I would guess that pulling the power line on the USB would essentially reset the camera. Might have a go at this (unless anybody knows any way of getting a UHCI controller to power down specific connections).

06-10-2004 00:18:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
I think the error "Data error (cyclic redundancy check)" may be the Windows catch-all for IO weirdness. I've had it on every IO device on the system at some point or another (bad CDROM drive, prematurely ejected floppy disk, etc.). I'm thinking that it just means "general error" with respect to USB.

Perhaps the device has a very dumb command buffer (for either laziness or security reasons). That is, once 36 bytes is passed, you should have sent all the commands you needed by now (HELLO, DUMP, DELETE, BYE), and the camera is going to clam up if you haven't.

j94501, I agree with the parallel port relay idea: toggling USB power (possibly with the batteries out) should do the trick. Can you make available your USB poker?

06-10-2004 10:22:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) madpyro
Profile
Finally got my cable and got the camera working. I'm fixin to re-partition my hdd and install linux, cross my fingers and hope all goes well. I have looked all over for a program that will read the data comming from the camera in webcam mode, but I couldn't find one. When I get through installing, I might even write a prog for the pv2. Be back after installation.
06-11-2004 15:11:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
After some days of having the cam torn apart and batteryless, I ran it in "camera mode" today for the first time since all the USB-messing...and now my serial also reads LAMSSMAL0000. It might be the USB playing, but I didn't do *too* much of that...think it might have something to do with the mystery buttons - did you mess with them too?

Some discoveries: Apparently it camera doesn't like to run with its flash capacitor removed - took it off to reduce the likelihood of nasty surprises, and the camera wouldn't come up. (Smaller couple-of-uF cap with bleeder resistor across it seems to do the trick...barely.)

That done, I powered it up on a current-limiting supply (forgot that it was current limiting, and this limit was set ridiculously low). About a second after powerup, while displaying the Big Print logo, the camera draws a large amount of current, which tripped the limit and the voltage briefly dropped to 1.8 or so, causing the display to scramble up a bit (top 3/4 of screen ok, bottom 1/4 flickering in and out in an analog-looking way, you'd swear the connector to the LCD was just pulling out). On attempting to switch to the next screen, the display scrambled completely, resulting in what appeared to be the text "? ? ? ? ?" underneath a field of random pixels. This might be something to play with if all else fails - play with the voltages and see what happens. On a recent PIC-based project I worked on, a brief undervoltage or powercycle could cause the chip to start executing at an arbitrary code location, and e.g. start jabbering text strings to the serial port. (Hopefully, it wouldn't arrive at "Erase the firmware"...if the firmware in this one is indeed rewritable at all...)


The unpopulated resistors around the SMaL chip are pullups for data-out lines...there's a bunch of repetitive data on each of these, from startup to just when the "Shutting off..." message appears. (Too much to 'scope, at least for me. Logic analyzer, anyone?) Might be for the LCD, but the continuous transmission (even when the LCD is 'off'), and no data while it's still showing an image makes me doubt this. Image sensor communications? Something completely different? Another engineer at my work is also very interested in this camera; we're planning to come in tomorrow and attack it with soldering irons (maybe attempt to pull and read the flash memory).

Just had a thought - the cam has 2 configurations (100mA, 200mA) - think changing the active configuration would effectively reset its USB communications? Left it at work, so I can't test this myself tonight.

BTW...has anybody figured out what image sensor is in this cam?

06-11-2004 21:59:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
I didn't try anything with the two missing buttons, so it must be the USB commands that changed something. I did try the control messages as well as the SMaL type bulk endpoint messages though. All I got back from my stream of read messages was the read content 'reflected' back at me though, so I just assumed that they were being ignored. What types of operation did you try on the USB?

I will see if I can try the re-config option to reset the camera later tonight - I'm going to be up working so I might as well do that too I will also try to put the code for my little USB poking tool on a web page somewhere tonight or tomorrow morning.

I was wondering whether the missing resistors might in fact be a console/serial port - I suspect it would be brought out to the edge connector, but only if certain resistors/links are fitted - I've seen this trick on other devices too.

06-12-2004 00:24:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Basically, what I did at first is try sending read / write messages using libusb's usb_control_message(...), each containing an arbitrary control command (actually, copy-pasted right out of sucr for the old Dakota) and data length of 0 bytes. These all produced the CRC error mentioned above, so I tried reads and writes of various lengths (between 1 and 64 bytes) to the Bulk endpoints, with results as mentioned earlier (more CRC errors, etc). The data buffer used was uninitialized (garbage) at first, because I was just trying to check success/failure of the physical write (e.g. maximum length) and didn't figure any particular combination of data was more likely to be interesting than any other. Subsequently I started initializing the buffer to all 0x00s. Maybe 0s is what did it? Otherwise, the odds of us both hitting the same magic combination (your bruteforce on the first 3 bytes(?) vs. my whatever-crap-was-in-memory) seem slim.

I don't know about serial; the signal on these pins was pretty darned fast ( >>100 KHz). The other end of the resistor seemed to just have Vcc on it. Hopefully by tomorrow night I'll have something more useful to report

06-12-2004 02:04:53

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
Regarding the LAMSSMALL id, my camera still has the regular ID. There are two things you've done that I haven't:
1. I haven't done any manual USB poking beyond gphoto2 yet
2. I never held the SW1 during hookup, but I have pressed both SW1 and SW4 during use

I also noticed LCD oddities when I had it hooked up to a transformer. There was an odd banded flicker, perhaps the small AC component of the regulated power?

Regarding those unimplemented lines, if the transmissions are slow enough, you could potentially build a logic analyzer using the input lines of the parallel port. Just have the system sample the lines at the clock rate you measure and dump to file. According to this page, you can potentially get up to 1MHz sampling rate ( http://www.xs4all.nl/~jwasys/old/diy2.html ). I've been meaning to build a dedicated machine for something like this forever...

06-12-2004 11:08:32

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
I emailed SMaL with questions about the Ultra-Pocket 3 kit (who uses it, etc.). They took quite a while in responding. Here is the relevant part of the reply:

"Thank you for your inquiry. A camera that leverages that Ultra-Pocket 3 kit (1.3-megapixel) is the Foxz1 by NHJ Limited (headquartered in Japan). They
have also released a 2-megapixel product, the Foxz2, based on our Ultra-Pocket 4 kit."

He went on to ask about my interests in developing a camera product. Too bad we pretty much already knew that.

06-12-2004 11:31:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Hi everyone ... good to see so much hackin' going on!

I looked at the mac drivers. First off, it's from Sep 2000 and it's a 428KB self-extracting file. The file that it extracts... hold on, here's the punchline you know is coming: 348KB. Ok, I'm expecting the driver to have some seriously good engineering It's copyrighted 2000 by "virtual fx". The driver internally refers to a DCA1 camera, which might be a ST chipset (it could be that virtual fx based the SMaL driver on the older one and didn't totally clean it up). There's lots of stuff in there, but nothing too useful-looking.

madpyro - sorry you got zapped. This camera doesn't have to protective gob of glue that the old one did. That smell you smelt afterwards was ozone, which AFAIK, is named from the greek word "to smell sharply". Thanks for contributing to smog!!

True story: I was actually offered a job at Ritz Camera about 10 years ago. They saw what a cool person I was and that I knew my stuff about cameras. If only I had stayed with them instead of persuing engineering... argh. Nah, just kidding. I want to hack this in a clean-room environment, just like the last one. Since I write software for a living and I'm an avid photographer, I respect copyrights. (although some of the platforms you'd need to run my software are pretty exotic, so I don't have that much to worry about). I haven't been sued (nor have I broken any laws), and I'd like to keep it that way. Unauthorized use of Ritz's printing machine (even if by an employee) would be wrong...

06-12-2004 11:53:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
I tried to see if I could get the camera to reset by simply setting a new configuration number, but so far I am not convinced that I have been able to even set the configuration successfully and then send commands - any time I set it, even to the default, the command fails immediately.

Anyhow, I've dumped the source for the little tool I have on a page on my website: http://www.bluedonkey.org/cgi-bin/twiki/bin/preview/Linux/DakotaPv2Camera - feel free to hack on it and add more features etc. If anybody knows for sure how to get the config & alt setting working I'd love to see that added properly.

The reason for my probing in the first three bytes was more from looking at the regular SMaL driver which seems to use 16 byte commands, with the first three bytes reserved for some kind of command information (for example, filenames always start in the fourth byte of the command). The third byte is always zero as far as I could see, which made me wonder if the format was something like this:

1 - command byte
2 - 16 bit argument
13 - 13 byte string

The ID string shown by the camera, even once it has lost the real value, is 12 bytes long (13 bytes including a NULL terminator). Might be coincidence, but it all seemed to fit rather well.

Finding a serial console for the device would be very handy, but as you say lines that can be pulled up are probably not the ones. Might try pulling mine apart again and see if I can find anything useful (a reset line would be kind of handy too - might be simpler to drive than switching the power on the USB).

06-12-2004 12:50:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Just talked to our resident chip-pulling guru. Contrary to what I thought, pulling the chip off is a fairly easy process. Actually reading it will be the bitch; we don't have equipment here to just pop the chip into and suck the data out of it, so I'll have to build some kind of reader. Is there anyone out there who DOES have a reader?

To j94501 (and anyone else whose camera ID is now reading LAMSSMAL0000) - were there any pictures on it? Are they still there?


Regarding a reset line- if there is one, I'd start looking for it on the connection leading to the flash board (high-voltage zappy kind, not memory kind). Somehow the camera "knows" if there's a problem with the HV generator and refuses to start up.

06-12-2004 22:18:32

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
The camera did not have any photos on it at the time I was playing with it, but I can still take and delete a photo even though the ID is not what it used to be. It doesn't appear to have affected the camera's behaviour in any way apart from changing the displayed ID. It would be interesting to know if any pictures would have been lost too. Might try leaving one photo on there for the rest of my USB hacking.
06-13-2004 00:11:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Here's an updated url for j94501's wiki: http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Linux/DakotaPv2Camera -- looks like a good start!
06-13-2004 09:40:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) KalSeth
Profile
The Weekend Paper with all the flyers in it has a Ritz/Wolf camera flyer. There is a coupon good for $2 off the PV2 with LCD, putting the price at $16.99. Expires June 19th. Got mine in the San Francisco Chronicle.
06-13-2004 13:57:27

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
I completed a full scan of all 65536 index values for all 256 request values in control pipe reads. All the camera did for every one was echo back 8 bytes containing the control message it had been sent. Nothing else.

Next I want to try reading some of the descriptors (to see if there are any hidden ones in there), but I'm not going to have much time this week.

Many thanks to morcheeba for correcting the link to my twiki page. I will try to update the USB tool there as well as I now have control reads and maybe writes working (haven't played much with those, but they seemed to be doing something).

After that, I suspect it is time to come up with a reset circuit for the camera so it can be autonomously probed. That said, with all the possible combinations in a 36 byte message this will take an eternity

06-14-2004 23:34:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Accelleron
Profile
Since the reading unit and the pinout of the old and new cams are the same, there's a snowflake's chance in hell that the same USB output for 'reset' is used (i.e. the coders for Ritz didn't bother re-coding one or more of the signals). I have a PV2 on hand, but I cannot try this because I made my USB cable and my blue Dakota Digital talk via a piece of an IDE cable from an old hard drive I had on hand.
There are only two truly infinite things, the universe and stupidity. And I am unsure of the former.
06-15-2004 21:32:31

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Havien
Profile
Ok, I've noticed everyone making custom connectors for the dakota digitals... The best way I found (requires no opening of the case at all, except the little sticker over the port) What you need is: a peice of plexiglass or lexan 3/16" thick (clear is the cheapest for me,) a few inches of ethernet wire, and a spare usb cable.

The plexiglass I used can be cut with a hacksaw to the right size. Use sand paper if necessary.

To mark where the wires go I used a ball point pen (a sharpy would work better as long as its a fine tip) with the plexiglass inside the port.
Remove the plexi and take a peice of the ethernet wire (one strand) and strip off enough to wrap from one side of the plexi (about the center) to the top side.
To bond the wire with the plexi just use a standard soldering iron and heat it up while pressing it against the plexi at the end of the wire untill it sinks in a bit.

Then wrap the wire around the end of the plexi and back twards the other side. then attach the 4 wires spaced at the right distances to your usb cable.

Now you have a custom connector thats plug and play with no tampering required.


If you have issues making one please post and I can send a picture of the one I have made.

06-19-2004 03:36:19

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Steveo
Profile
I like to see youre conector. do you have a link?
06-20-2004 19:49:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mako
Profile
I made a cable much like Havien's ... except it uses cardboard =P.

Cut a piece of cardboard to fit into the Dakota's slot, and use a pen to mark the connections. Then strip some wire and superglue/tape it down in the right places. It works, but you'll probably have to wedge it in place when in use.

For me it was a temporary measure. I got a USB-B connector as soon as I could (out of a broken printer) and fitted it under the lens assembly. It's the best way to do things, IMO, because you no longer need to rely on proprietary connectors. If you want to show a friend what's on your camera, for example, s/he just downloads SUCR and chooses a random USB peripheral to borrow a cable from.

06-20-2004 23:52:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
hello,
I just got 2 cameras from Wolf/Ritz cameras, in the Bay Area.. one, the red one, with the LCD display screen, _is the PV2 model, its printed on it, and, from reading, and reading.. here, seems, it is NOT Yet hackable.. but, the other one I got, a blue one does NOT have "PV2" printed anywhere on it, so, my Question, is my blue one "a Classic" that I can make the adaptor, load the software, and have my way with it? :) I sure Hope so!
In other words, do the "newer" blue ones, have "PV2" printed on them? (the un-hacked ones) ?? Thanks!
06-21-2004 14:17:23

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
Whoopie! I think I _FOUND my answer! .. its a Classic! .. well, I wanted some Success here.. I will make an adpt, and wait for you Experts to crack the "PV2"s :) Thanks for all this great info... sometimes, TOO Great!
06-21-2004 14:58:07

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Hondaman900
Profile
Hoping for any updates/success in hacking the red PV2. Looking at it here on my kitchen table, wondering what to do next with it.

Any news yet?


Hondaman900
www.MediaQ.net
06-26-2004 01:19:48

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Hondaman900
Profile
Actually, I was hoping to find out here if the PV2 was ahcked yet and if I could interface it with my PC. Reading through it doesn't seem to work with the older blue camera software. Is this correct?

I'm thinking of holding my red pV2 until the hack is developed, and in the meantime buy a blue one. My local Ritz doesn't carry them, but a nearby Mall Ritz did. Looking at the posted pics looks like the non-LCD preview version is the older (hackable) blue version. While I'm a proficient VB programmer, this low-level stuff is beyond me. Let me know if anyone needs help developing a user-friendly interface though. :)

SMaL site has drivers for the Creative Labs Card Cam and Oregon Scientific's version. Has anyone tried these to see if they'd work?

Stephen

06-26-2004 18:59:27

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
hondaman,
there are pics online, of the 'old' blue, and, the 'new' blue with the red one.. the blue/red pic shows PV2 on the front...
I managed to get a red PV2, and, the older blue one, But:
I, along with a couple of recent posters to the other thread are having Problems... my guess is, the Actual software was removed for fear of being sued...(maybe I'm wrong?)
If you happen to get the Old blue, and have success, Please post for us!
my GUESS is, the libusb-win32 needs to be modified (" Rename and edit the sample inf-file 'libusb.inf' to match your device(s) (modify the vendor and product IDs, strings etc.). Create different inf-files to install different types of devices (devices with different IDs)"

well, I'm NOT smart enough for this stuff, but, I'm _usually good at following instructions...
sooooooo, if you can look at _that part of this, perhaps we can get this working!

06-27-2004 09:00:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Hondaman900
Profile
Redwood,

Did you get the SUCR application from http://cexx.org/dakota/sucr.htm? This would seem to be the best source. There's a guy on eBay selling the camera and cable kit for this purpose. His link to the software is to this page. What exactly were the problems you found that prevented you from getting the older version working?

My wife is going to Reno today and will stop by the Ritz there and see if she can get me a "non-PV2" blue version. Once I get the older version working I'll start playing with the red one. The cool thing is that these devices are cheap enough to play with. No one is doing this to "cheat" Ritz, it would be cheaper to buy a 1.3MP digital cameran incl. software and cable from Pep Boys (<$50). It's just a lot of fun to play around with these.

I read the packaging, and found no user agreement or license details that would indicate that this was a "rental" and the ownership of the product remains with Ritz. Therefore once bought I believe it's ours to do with as we please.

Stephen

06-27-2004 11:12:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
hondaman: yes, I got the files from there... sucr.exe seems to run fine... its the libusb.inf file that I believe is the problem...

"Method That Worked For Me
------------------------
Don't plug in the camera just yet. (If you already did; make sure Windows doesn't try to install any drivers for it yet. If it did, remove them, then unplug the camera.)


Find "libusb.inf" in the directory you unzipped sucr.exe to. Right-click on it and choose "Install", wait for installation to complete. Now REBOOT THE COMPUTER."

that was from the instructions... but, when _I right click, I don't really get the installer.. but, I do, when I install libusb-win32 from http://libusb-win32.sourceforge.net/ I _DO get a full install.. but, I think, the file, "libusb.inf" is customized for this camera, and, libusb-win32 is just a general driver that needs to be customized..

hope you get an 'old-blue' so you can try this out... Good Luck!

06-27-2004 21:34:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) coolnetdude
Profile
Hey guys, I'm new to the thread. I'm just a 16yr student VB programmer (medium skill). My experience with digital electronics is light to medium (I've done some microcontroller/serial(usb and RS32) interfacing). So, maybe I might help. But most of all, I just want to be a part of this and watch people better at this at work. So here's my scope of things:
1)New versions are now out of Dakota called the PV2, available in blue (no LCD) or red (w/ LCD) chipset based on SMal
2)Red is preferable for the feature of LCD
3)Commands can be sent but only up to 36 bytes b/f a timeout, after which the camera must be reset by i/o the pwr (I assume through a make shift USB connection probably on Linux written apps)
4)The camera most likely needs to "unlocked" before we can send real commands to it.

As far as the "unlocking" goes I'm not quite sure where to go. Except one thing hit me. I bet it turns out to be nothing, but it's worth a try. Someone said:

"you had to "log in" with a four-byte code before it operated normally."

when talking about the "old" blue camera. Perhaps, you must do the same on the new PV2 reds. I think I heard that that code was the USBprodID or something. But, if these new ones are increased security, then it's probably not that easy. Then I noticed many saying that their device ID was originally DAA04190nnnn but then after fiddling with USB stuff it changed to LAMSSMAL0000. This leads, obviously, to questions.
Maybe "nnnn" is some type of unlock code like the old versions?
Perhaps this is an indication of a memory flash. The firmware obviously isn't flashed b/c the camera still works. But what about the other memory. There's three memory modules: 128kb, 8mb, and 16mb. One for pic storage, one for firmware, and another probably for like scratch pad RAM-- or setting storage seperate from the firmware. If this was possible, then that means this device ID reset could mean you flashed one of the mem modules just not the firmware. I'm not sure if the pic storage is flashed when this ocurrs though. Because the SMal processor looks for info like device ID after being flashed and doesn't find it so it gives a defualt of LAMSSMAL0000. If so, it's possible that this could render device interface impossible. Has anyone fooled around with the nnnn? Just a guess, I'm probably in way above my head and just wrote a bunch of crap so just let me know if I did. This is just my immediate pondering. Keep up the good work.

06-29-2004 20:26:31

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
To redwood: Don't worry, SUCR hasn't been DMCAed. But Windows does seem to make things unnecessarily confusing and nondeterministic, both for the end-user and the software developer :) In the instructions there are two different installation methods - which did you use? And did you try the other one? It seems that for different people, Windows (even the same version, etc.) will decide that it likes one method but not the other. I tested various versions of SUCR on Windows 98/98SE, 2000, and XP, and it "worked for me" in each case, but I have heard plenty of cases where it didn't work for someone else. :(

(If some drivers are installed or partly-installed already, they may have to be removed first, e.g. remove the libUSB-win32 "filter driver" that comes from libusb-win32.sourceforge.net and has a nice GUI installer (SUCR doesn't require or use this). There are instructions in the SUCR documentation to completely uninstall existing libusb-win32 drivers and/or phantom devices, but this involves Registry editing, not recommended for novices. I recommend doing this only under the supervision of your neighborhood guru.)

When you right-click on the .inf file and "Install", you won't see anything to indicate that it's actually been installed--e.g. there's no installation screen or any message that pops up. If you're lucky, you'll might see your mouse cursor turn into an hourglass for a moment.

To test if the libUSB stuff is installed properly, run testlibusb*.exe included with the package. You should see the device IDs of your USB devices listed along with a long page of garbage describing their interfaces, power requirements, etc. You can also check the About > LibUSB Version... menu in SUCR to see if both libUSB files can be accessed by it (and the version of each). You should see "0.1.8.0" or similar there; negative numbers will indicate an error.

Good luck!

06-30-2004 21:18:16

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
To coolnetdude: I wondered something simiar-ish when I saw LAMSSMAL0000 - it seems like a strange thing to re-initialize the ID to. Why not SMAL00000000 or simply 000000000000?

(Note from Captain Obvious: LAMS is SMAL spelled backwards)

Although again a snowflake's chance, it would be really nice if this turns out to be a hint placed in the firmware by a sympathetic PV2 developer, which is "triggered" by ham-handed hacking attempts like those a few of us have tried already. For example (since the similar SMAL cameras take a "command" of always 16 bytes, and the PV2 takes 36 bytes)...16-byte command backwards + 16-byte command forward + 4 zeros (or perhaps a 4-byte checksum) = 36 bytes?

I haven't tried it yet since my PV2 is still torn apart in the EE lab where I work, awaiting a FLASH-ectomy. I'll wear a dress^H^H^H^H^H tie to work if it turns out to be that easy, though.

06-30-2004 21:34:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
Great Googaly Moogaly!!!!!!!!!!!!

I have a Working Camera!!!!!!!!!!

thanks Drmn4ea, you helped PUSH me into un/re/un/re/un/re-installing.. untill I had Success!!!!!

Thanks to Hondaman, for keeping me on track...

Thanks to all those who have contributed to this hack!

Thanks to T.R.Gipson, for writing sucr !!

Thanks to John Maushammer for the Driver !!

and, forgive my Wild posts while I was Frustrated!! :)

07-01-2004 12:21:11

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) coolnetdude
Profile
WAIT!?

Redwood: Are you saying that you have finished the hack for the red PV2? If so, leave the instructions for us. And, if possible, leave source code to see it (or just explain). Thanks!

07-01-2004 15:54:50

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Hi guys

I'm new here, I've been reading your thread with great interest and I'm currently awaiting delivery of 2 PV2 cameras with LCD. You can order them off Ritz Cameras website now. Unfortunatly they only have the red PV2. Considering the price of these babies they're perfect for risky things like kite fotography, hobby rockets and homemade underwater cases. Plus I can't resist a good hacker challenge :)

@coolnetdude
You mention a 128kB memory. I haven't seen any references to that anywhere else. Are you sure? and if so where on the PCB is it located. This memory would obviously be the program memory which is of great interest.

@all
The limited documentation available suggests that the firmware is USB upgrade-able, this is significant since it means the firmware is stored in flash somewhere. The documentation doesn't mention anything about internal flash for program storage so hopefully we can find the code on the external flash memory.

Hmm, is there any firmware update for the fuji axia eyeplate? It would be interesting to see what happened if you tried to upload it to the PV2


Regards

07-01-2004 15:59:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Daskins
Profile
i am also reading this thread with excitement beacuse maybe someon found a hack for it :)

umm sorry to ask this dumb question but, how in the heck do u turn of the flash on this camera lol i did not save the instructions booklet or antyhing

07-01-2004 16:02:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) coolnetdude
Profile
LOL! I just realized this. Hondaman900 said the following:

"it would be cheaper to buy a 1.3MP digital cameran incl. software and cable from Pep Boys (<$50). "

Pep Boys? I'd like to see anyone go into Pep Boys and ask for a digital camera. HA! That's a car repair shop! Unless you're talking about a local place! HAHA!

07-01-2004 16:13:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) coolnetdude
Profile
I must correct myself when I stated that there was a 128k memory IC. I could have sworn I saw that somewhere, but now I can't seem to find it. Thus, I must have just been stupid. But that still doesn't remove the quite highly possible idea that the SMal chip has internal program memory. Too bad this is a custom SMal or else we would know from specs. I don't know what everyone's jobs are but maybe someone has access to equiptment to open the SMal IC and scope it out with a high-power microscope. Maybe that's farfetched, but I believe it is possible. We could definately learn a little from that.
07-01-2004 16:27:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) redwood
Profile
I got my 'Old Blue' camera working....
07-02-2004 07:49:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) klothga
Profile
While waiting for iron to heat up, I took a look at the power supply board.

The largish 'chip' under the big capacitor is a TDK transformer,
http://www.component.tdk.com/SRW10EPC-U01H003.pdf

The component under the flash unit is a IGBT from Fairchild,
http://www.fairchildsemi.com/pf/SG/SGU20N40L.html

U2 is a Nc7s04 inverter, also from fairchild.
http://www.fairchildsemi.com/ds/NC/NC7S04.pdf#page=1

07-02-2004 12:43:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Ha! just got my shipment of PV2 cameras. I must say the quality of the LCD is a lot better then I expected.
Now, where did I put that screwdriver....
07-02-2004 17:28:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Just talking to myself here...

One of my cameras lists the following info
firmware 6410
hardware 06
typeID 27
ID daa041942128

Tazlibog is written on the PCB, probably the guy who tested it.
The flash capacitor tickles nicely, but it hardly compares to the 90kV capacitor bank I play with at work.

07-02-2004 18:03:06

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) klothga
Profile
Grr.. well, my attempt to play with the flash failed. I probably could get a decent connection 'dead-bug' style, but soldering to the existing connections, I'd need finer wire and tips for my iron. It's like trying to carve fretwork with a chisel and sledgehammer.

The part placement is off a fair bit, and there seems to be quite a bit of solder for a modern PCB.. wonder what their yield is.

Anyone else manage a flash dump?

07-02-2004 19:07:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
@klothga

I'm going to attempt it sometime next week. I just need to solder up a 3.3 volt interface first. The IO ports on the flash won't handle 5v logic.
I have some new solder tips at work, I hope they're small enough.

07-02-2004 20:12:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Interesting development here.

I just took apart mu 128Mb USB drive, it contains a small controller and a Samsung NAND flash chip with identical pinout to the one used in the PV2 camera.
http://www.samsung.com/Products/Semiconductor/Flash/NAND/1Gbit/K9K1G08U0M/K9K1G08U0M.PDF

With a little bit of luck I'll be able to transfer the flash from the camera to the USB drive and read out the content. This ofcourse depends on wether the content of the camera flash is written in the same format as the USB flash controller expects, probably FAT12.

If not it might still be possible to bitbang out the content, does anyone have any info on accessing the raw data on a USB drive?

The controller is a
LEXAR media
FC1610-TC-AJ
MH28F-LX714AJ
0341

07-03-2004 14:05:40

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
hoppsan - cool idea. What brand usb memory stick do you have? it sounds like it would be easier to solder to a board rather than deadbug.

Only half the pins are used; I wish they had used every other pin so that I could be messy with the solder -- but, instead, it's just the pins near the corners that aren't used. I've got an I/O board to bitbang with; I need to do the 5->3.3v conversion *while* deadbugging.. I may need an adapter PCB so that it doesn't fall apart into a million shorted pieces.

hopefully, someone will get a firmware suck! That should settle the question where the firmware is. (I didn't see any activity one either memory chip while waiting for a shutter-press; there could be lots of reasons for this.)

07-03-2004 15:11:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
It's a simpletech USB 2.0 flash drive. I got it from PC club a while back. It's still listed on their homepage.

The USB board has convenient VIAs on every connection from the flash chip so it looks like it will make the job a little easier if interfacing the flash directly becomes nescesary. They're still pretty tiny though.

07-03-2004 19:12:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) klothga
Profile
Ah, for me the 3.3V interface is easy.. I just flip a jumper on the AVR devkit. I may break down and dead bug, but I was trying to avoid desoldering the sucker, as reconnecting it will be a pain.

I also just got some samples in of Analog's iCouplers to play with. Supposed to make 3/5v level shifting easy.

07-03-2004 20:15:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Come to think of it. It's easy enough to verify if the firmware resides on the external flash or not. If it does it certainly wouldn't execute from the flash due to the crappy random access times. The firmware would therefor have to be copied from external flash to internal ram when the camera comes on. If there's no activity on the flash when the camera starts up the firmware resides internally. I don't have a scope at home so I'll have to wait till tuesday, can anyone else check before then?
07-03-2004 23:50:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Well, bad news. I transfered the flash to the usb drive and nothing happens when I plug it in to the computer. Hopefully I didn't toast the flash when I removed it.


The camera gives off 4 beeps when I try to turn it on without flash, so at least it looks for a flash for some reason.

07-06-2004 14:00:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Scratch that, it was just a bad connection somewhere. I poked around a little bit with the soldering iron and now the computer recognizes the USB drive as a Jumpdrive and asks for drivers.
I'm running on win2000 so no drivers should be needed. I presume the data on the camera flash isn't stored in the right way.
07-06-2004 15:15:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) DeadMan
Profile
Thanks for the hint hoppsan... :)

My pv2 gave 4 beeps after i removed and reinstalled the flash.
(might have erased the flash or changed the checksum?)

I am thinking about buying a usb pen drive and try hooking up the usb-drive to the pv2
with the flash installed and see if that works.

If this works then i would use the pen-drive usb port to get the pictures.

I need to get a fresh flash image or buy another camera to continue.
Anybody know if there are swapped around address/data/control pins on the uC <--> flash?

07-06-2004 19:24:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
Anybody got any information about the power management controls for USB? I was playing with the USBIO tool from Thesycon - http://www.thesycon.de/eng/index.htm - and I found on the "Other" tab that there was a mechanism for setting the power management level on the device. Setting it to anything other than D0 caused the camera's ready light to go out.

I scanned for info on the web, but couldn't find much. The only thing I found suggested that the power management levels were set using a Feature Set message to the interface. I tried this from Linux (having updated my little tool to support more message types) but just got broken pipe errors back. Since there were no power mgmt descriptors, this is perhaps not a big surprise, but I wonder how Windows did it...

If anybody has a decent USB sniffer setup I'd love to see what happens when the USBIO power levels settings are used on the bus - then perhaps I can replicate it in my tool. I'm hoping that it is enough of a power-down to reset the camera (allowing me to do more automated probing of the camera).

I also checked all the string descriptors - nothing there that wasn't expected except, perhaps, for the 'OK' string associated with the configurations. Why have that when they could just have it set to zero if they didn't want to have a real description for the configuration?

07-08-2004 22:07:24

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
The camera gives off 4 beeps when I try to turn it on without flash, so at least it looks for a flash for some reason.[/i

Argh! hoppsan and deadman, you realize what that means? There is at least a bootloader in the ASIC. It might do some sort of crypto decode of the firmware from the flash, but I'd guess that it won't be that tricky (I doubt SMaL would have any other customers that want that level of security). Then again, it might be easy for SMaL to change the bootloader to include that feature.

This, of course, lends itself to a wonderful opportunity. The bootloader should be able to support a firmware upload... if it isn't PureDigital-specific, then it'll probably be compatible with SMaL's other cameras. It may work through USB, or it may work through some serial port that we haven't noticed yet. It would be interesting to see what the USB port reports without a flash memory, and if it is more accepting of commands.

Of course, it could be that all the firmware is in the ASIC and that it's just complaining because it can't get to the start-up-screen picture data (that most likely is stored along with the other pictures).

Any chance of anyone taking detailed close-up pictures of the board with the flash removed? I'd like to know which vias go where so it's easier to probe up and watch during normal operation. If no one else does, I'll probably post some pics next week when my TSOP adapter arrives and becomes the new home for my memory chip.

The USB drive option looks especially good now. Could you get a part number off of the Simpletech control chip (chips) so I can see if it's accessible at a low level (I'd like to read the ECC data. And the code, which probably isn't stored in the filesystem).

good work!

07-09-2004 19:18:22

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
@Morcheeba

http://pulsedpower.usc.edu/newpage/images/IMG_0921.JPG

Some form of firmware does indeed recide internally, only question is how much. It would indeed be most interesting to probe the USB port without flash and see what happens.
The only info I have on the USB controller is what I posted 10 posts up. I haven't been able to find any documentation on the chip. There must be some standard way to read out the raw data though, for file recovery etc. Sadly I'm not an expert on USB protocolls.

@Deadman

Make sure your solder joints are good, prod them a little bit with a tiny tipped soldering iron. It's very hard to accidentally erase a flash chip. You're more likely to have a bad connection or perhaps you fried the flash with some static discharge.


Has anyone else noticed that there are several test points on the back of the PCB (see picture). They look like large vias with exposed copper. There are especially two groups of testpoints that are interesting. One is located close to the upper left corner of the flash and one is located at the lower left corner. They are groups of 5 and 6 test points. I'd bet good money that at least one of these groups make up a JTAG interface.

Currently my bet is on the lower left group as the testpoints connect directly to the SMal chip and they seem to have pullups on them.

07-10-2004 11:46:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Hondaman900
Profile
Bought an old blue model, "installed" a 4-pin connector from the audio link off a dead CD-ROM drive. Built a cable - worked first time brilliantly. I'm saving my Red PV2 for that eventual hack. See other "Dakota $10.98" forum for details of my free hacked connector.

BTW, Ritz in Sacramento (Arden Fair Mall) has loads of old blues. Reno Ritz is sold out.

Stephen

07-10-2004 12:20:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Hondaman900
Profile
Forgot to mention that Pep Boys do actually sell cheap digital cameras in this area - I wasn't wisecracking in my previous post :)
07-10-2004 12:22:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
Hoppsan, I had been wondering about the liklihood of a JTAG interface too. I was also wondering whether it might be brought out to the external connector, but I just buzzed out all the test points around the flash chip and none seem to be appearing on the edge connector.

I also tried quickly shorting each of them to ground & Vcc to see whether that would have any effect (looking primarily for the #TRST signal line that should be in the JTAG collection). None of the lines had the desired effect of resetting the camera. In fact, only one had any effect at all. On the photo at http://pulsedpower.usc.edu/newpage/images/IMG_0921.JPG it is the right hand one of the two closest to the top edge of the flash chip.

On the subject of bootloader code, I strongly suspect that there is something of that nature as only the first block is guaranteed to be error free - that wouldn't leave a lot of space for code, so I guess that there is a loader in there to transfer the code from the "file system" that is in the remainder of the flash.

07-13-2004 22:42:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
A few more discoveries, and thoughts...

Oregon Scientific's DS6628 camera contains a description for SMaL vendor/product pair 0dca/0013 called "Oregon Scientific DS6628 (BTLDR)". When I modify this .inf file to include the 0dca/0027 pair the driver will open the camera device (the LED illuminates which only happens when a configuration is selected). The device status is not read though, and when I tried to get images I was informed that the operation was not valid in bootloader mode (notice the BTLDR in the description string).

So, I went searching online some more and found the drivers for the Che-ez Foxz2 camera (driver download at http://www.che-ez.com/download/driver/foxz2/Foxz2.zip for anybody interested in playing). Inside the .inf for that one were the IDs 0dca/0023 (Foxz) and 0dca/0024 (Foxz2). Once again I added the PV2 ID pair to this file and the driver managed to initialise the camera. Once again though I was presented with the "operation not permitted in bootloader mode" error message and while the TWAIN module started, it did not allow me to do anything (and all the counters etc were zero).

I am now wondering whether there is in fact no USB software on the cameras. Instead, it is downloaded using whatever this bootloader mode is in the store. That might explain why they were so confident that this one would be harder to hack

If anybody has access to a USB analyser, I would love to see what happens between the Foxz2 driver and the camera (once the PV2 ID line has been added to the .inf so it will recognise it). I wonder how it detects that the camera is in bootloader mode... and I wonder what commands need to be issued to download code to it.

Also, if anybody has a camera that still has its original ID (mine has the LAMSSMAL0000 ID now) I'd like to know if the same message appears for you (just in case the bootloader mode is something the camera drops into when that ID is not set - like it might need to when being setup in the factory for the first time).

07-14-2004 01:43:36

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Locosmotion
Profile
Hi all, first post here and sorry if its not up to everyones level as I am just starting my study to become a EE. I plugged in my pristine pv2 camera (Still shows DAA... under the firmware page). I modified the .inf file to reflect the pv2 vendor/product id. The camera took the driver and initialized (LED lights up)however, when I try to initialize the TWAIN I get an error occured while retrieving pictures (could be the image editor giving this error rather than the TWAIN) then if you try again it "gives operation not permitted in bootloader mode". After I did this I checked the serial on the firmware page and it still reads DAA... I hope this helps some.
07-14-2004 19:56:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j94501
Profile
Locosmotion, thanks for that confirmation.

I would like to find out if any of the other cameras based on SMaL chipsets have shipped firmware upgrades. I couldn't find one for either of the two I downloaded drivers for, but perhaps there are some out there. Also, if anybody has a USB bus analyser and can capture the trace of one of these drivers during startup and when you try to download photos, I'd love to know what it is doing to determine that the thing is in bootloader mode.

I seem to remember that there was a software USB bus analyser available for Windows, so when I get a chance to play some more I will try to find that and install it.

07-14-2004 23:44:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billwiley
Profile
Has anybody considered the possibility that Ritz is using 2 firmwares for the camera?

Maybe there's one limited firmware that is on the camera when you purchase it - it has all of the code for regular picture taking operations and firmware updates, but no bulkload facility.

Then when Ritz gets the camera, their software updates the firmware in the camera to a version that contains bulk download code. It does the bult download, and finally restores the limited firmware back to the camera again.

To hack such a version you'd either need to write your own bulkload routines and update the firmware with them - a huge chore, especially compared to the original Dakota hack.

I don't really have the skills to follow up on analysing the existing firmware, but I thought I'd throw this out there as something to keep in mind.

07-16-2004 10:52:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 1 times) mako
Profile
I found this USB snooper through Google:

http://benoit.papillault.free.fr/usbsnoop/doc.en.php

07-16-2004 14:48:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) sarain
Profile
I haven't purchased one of them yet but has anyone tryed to look up FCC info on it.
If someone could post an FCC id (if it has one on it) ill go check it out.

Ive found schematics, manuals, and other valuble info for products, accessable from the FCC site.
Who knows, they might have sliped up and forgot to request that some of that info be kept confidential.


Time travel is real, unfortionatly my reverse is broken and im stuck in 1st gear.
07-20-2004 03:36:16

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
hi there!

i don't have a PV2 and i'm not planning to get one. probably the people at SMaL did or at least helped with security, and i think it's fair to say that if they can design a cam, they must be able to implement some simple security right. it's really easy to make the cam "unhackable". the NSA could have the whole firmware listing and there would be no chance in hell they'd be able to download the pics if security was done well (that is, just by writing software on a PC, without resorting to supply voltage spikes, signal injections, etc...). and you don't need getting into public key criptography for that, SIMPLE code would do (i'm not giving more details just in case they didn't bother to implement security right, and they still don't know how to --we should be so lucky!).

what will probably happen is this, someone will pull the flash out and read it, and find no firmware there. or else he'll find it encrypted. to do this you can try a smartmedia usb controller and use some hidden raw commands that should exist, as some people have suggested. but the "do it today" method is simpler: breadboard, 3v source, voltage converters, some surface mount test board where you can put the flash, and connect the whole thing to the paralell port. crude but simple. an even simpler way would be to just stuff the flash into a dakota an read it through the usb. the firmware would have to be patched in the 2 or 3 places where the flash is written, so as to do nothing and return an OK status (i'm familiar with these routines so i could do this).

still, like i said, i think you'll find nothing there. somewhat more promising would be a snoop of the cam talking to the developing station. however if security is done right the cam should be defended correctly against playback attacks and this wouldn't be useful either (the sure thing would be to get the station software of course, how about THAT for a brainstorm!) what i mean is, if security was done right we're gonna need inside info or we're busted. otherwise we'll be stuck with the unatractive option of a hardware hack to access the flash ourselves, which maybe someone will like but i don't.

as a side note: if the firmware is indeed downloaded form the flash it wouldn't make much sense to have some "big" internal ram to place it for execution (except for security reasons, but remember this is probably not a custom "single-use" chip and it wasn't designed with security as a first priority). a better option would be to use the dram, which has enough bandwidth for this purpose. so if the code is encrypted in the flash, maybe it's decrypted when copied to the dram. (but again, even while having the firmware listing with nice comments and all, the cam may be impossible to hack.)

but here's a downer: as i said, the controller is probably not a custom chip. it's probably designed to use standard interchangable smartmedias that don't have any firmwares on them. chances it's there on the PV2 are slim. even so, the design could have an internal short bootstrap that normally loads from an external dedicated code flash, and that was changed for the PV2 to download from the picture flash. that's a reasonable change. but think of it, if you have a code flash why bootstrap from it in the first place? why not just run from there?

sorry guys, it seems higly probable you'll find nothing in the flash. but there's only one way to be absolutely sure....

meanwhile i'm saving my money for a proyect with better prospects :)

-R

07-20-2004 04:14:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
I disagree. DVDs were supposed to be un-hackable, now you can deCSS a dvd with 6 lines of obfuscated perl code. This is a simple device, and we'll hack it. Remember its not the money, I'll invest $6000 worth of engineering time to get what amounts to a $75 digital camera. Its a hobby.

Which brings me to my next idea: Lets get organized. We've got a lot of people messing around with this thing, lets not all reinvent the wheel. I can see a lot of what's done earlier in the thread, what can we do next? If nobody has any other advice, I'm going to try to dig up the datasheet for the SmaL Asic. It looks like our best chance of success is to reprogram the Asic to do what we tell it to do. The hardware is simple (and standard) enough, and from my poking around, it looks like any encryption must be software based. If we can get a datasheet for the Asic, we're well on our way to a useable camera.

Now, some manufacturers (especially cellphone-type devices) require an NDA before they release a datasheet. If this is the case, we're outta luck.

I bought one of these things 2 days ago at a local CVS. If I can't hack it, well, the LCD is nice, and will become part of a hobby project someday.

07-20-2004 07:04:50

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) DrDootz
Profile
All,

From reading the thread, the bootloader term is interesting to me. Working with uP's in bootloader mode, you had to load a "talker" before the unit would communicate over the RS232. Maybe this camera requieres a USB talker to be loader before it can communicate over the USB. It could be that the first thing it looks for in the bootloader mode is the USB talker. If it doesn't get it then it hangs until the camera is reset again. Once the talker is installed, the camera would accept standard USB commands from the PC to download the pictures.

Just an idea,

DrDootz

07-20-2004 11:59:50

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
No luck. SmAL will not even send you purchase information or datasheets for the development kit unless you're a current customer and have an intended volume of 10k or more.

Any ideas on what to do next? Would be nice if somebody had a usb sniffer between the camera shop's equipment and the camera. Otherwise I'm going to take a few pictures and try downloading a flash image manually.

07-20-2004 12:09:25

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
when you decide how you'll try to physically extract the data from the flash, please tell us, i'd like to know.

(BTW, i think CSS was "hacked" after you could download a software DVD player to you PC and reverse engineer it. otherwise, the CSS must have been ill designed. (i understand both are true, software players were available, and CSS wasn't well designed.) by analogy, if we had the developing station software we wouldn't have any troubles... :) )

07-20-2004 15:53:33

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) sarain
Profile
Could someone please post the FCC ID# found on the device (assuming there that it is there).
07-20-2004 19:35:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Lanchon: I'm soldering on about 22 leads (its a 48 pin package, but most are NC) and I'm going to read it through a breadboarded PIC microcontroller, and feed the results serially to a PC through a level translator. I'm hoping that I can discern something that looks like a .jpg when I start slicing up the data dump that I get, but basically I'm looking for jpg headers. I'm going to lift the vcc lines and solder onto the chip while its on board. With any luck I won't backpower the asic through the data lines or this will be harder.

Sarain: No FCC ID on the device, just a label that claims it complies with FCC part 15. It probably does, I think the crystal on board is pretty slow. It only needs an FCC ID if it connects to the telephone network, or if its an intentional radiator (like a radio transmitter).

07-21-2004 07:27:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Update: I'm still soldering at the moment. Its slow going because 1- I've got family in town and 2- I almost sliced the last 2 fingers off of my left hand cutting onions 2 nights ago. On the other hand, I've got a friend of mine (a firmware engineer) interested in the project and he's going to be writing the uprocessor code to read the flash and feed data to the PC. Incidently, does anybody have a good tool to read a hex data dump that's poured into a PC serial port? It would save us some effort.
07-22-2004 07:09:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
Drmn4ea, you mentioned that you had access to sm soldering/unsoldering equipment. would it be possible to solder the flash in an "old blue" dakota in order to read it? the flash of both cameras are same package type? (i don't have a PV2)
07-22-2004 09:43:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Great idea. I've got the equipment here, as well. Anybody have an 'Old Blue' camera in the Atlanta area? If so, look for K9F2808U0C YCB0 or similar.
07-22-2004 11:00:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mycroftxxx
Profile
@piles_of_spam

how do you intend to make use of the LCD display? I'm having trouble with the .PDF, is it fairly easy to interface with?

07-22-2004 21:29:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Some thoughts...

DVD's have a different security model from this camera. With DVDs, the customer must be able to view the decrypted data, so ya' gotta give them the key. If you do that, it's security-by-obscurity, so it's only a matter of time. With this camera, the customer doesn't need access to their data, so you don't need to give a key. The exception is the preview of the last picture; you can save that at low-resolution and save only the last one, making it pretty much useless.

old blue camera to read flash = good idea! BTW, I got a cheap PNY 128MB USB key, and it uses a 16-bit wide flash. The controller chip is the latest one (T4) and probably capable of reading it, but I couldn't find any documentation on it.

Hopefully I'll get access to some good soldering equipment in the next week. I got my TSOP-to-DIP adapter, so it should go easy. The blue-camera-flash-read might have been easier; I might still try that.

PoS - right on. It's a hobby, not a financial deal. So far, I've spent $125 in materials on the PV2. I've tried to explain it to future employers as something like a crossword puzzle... I can got back an plod through the firmware and annotate a little more and eventually start putting pieces together.

Lanchon - an alternative to big internal memory for a copy of the executable code is just a cache. As this is cost-sensitive, I'd bet SMaL has a small TLB to allow easy execution from a flash memory with bad blocks. A logic analyzer at bootup should answer some questions...

07-23-2004 11:50:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
microftxxx - the lcd is fairly easy to interface to: CLK, VSYNC, HSYNC, and 6 parallel data bits. As for controlling with a microcontroller, the hardest part I'd think would be finding one with enough memory to form a picture -- the display is 280x220 (each dot is one of 3 primary colors, unlike how most computers define their screens), so it's about 60kB of information displayed.
07-24-2004 08:59:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
@Lanchon: A great freeware serial-port-to-disk utility: Hercules Setup - http://www.hwgroup.cz/products/hercules/index_en.html . Used this extensively while debugging some micro-to-CompactFlash stuff at work.

The Flash memories used in the old vs. new Dakotas look identical, as far as I can tell ("only" difference is one letter in the partnumber, K9F2808U0B-YCBO vs. K9F2808U0C-YCBO for the Old Blue). Only trouble here is that the classic Dakota expects to find blocks of configuration data at certain places in the memory; transplanting a new one could prevent the camera from coming up, or worse, it could try to overwrite data and corrupt whatever's on the chip before it can be read. (Someone experimenting with Rodrigo's firmware-writing utils [http://www.balerdi.com.ar/dakota/ ] tried flashing his Dakota with a newer revision, but when it got to the point of reading the (incompatible) config block formatted for the old version, it would do nothing but beep repeatedly. Wasn't completely hung--they could still reflash the old firmware.)

It sounds like piles_of_spam is already close to being able to read out the PV2 Flash. My super-duper-PIC-board (microcontroller, RS232 level converter and interface plug, and rows of .100" headers for all the I/O ports, on a 2" by 2" PCB) is still vaporware at the moment, it'll be some weeks yet before the boards get made (depending when the next 'official' project has boards made, and how much space is left on their layout). If the chip is still unread by that time, I'll try to rip the one off my PV2 and read it (all original data, no pictures taken yet).

On a totally unrelated note - anyone know what CMOS sensor is in the PV2, or at least how to identify it? Is it the same (Micron MI-1300?) as in the old camera?

07-24-2004 21:51:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
no idea on the sensor. I tried to photograph it, but I'd need a real microscope -- my bellows aren't enough. Chips are naturally hard to photograph to get good contrast, and the color filter in front of it doesn't help at all. I'd be stoked to find the resolution (*REAL RESOLUTION* not what puredigital will up-scale it to) or see a sample image.
07-25-2004 00:31:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
Drmn4ea, regarding the two problems with reading the flash in the old blue...

as i said in my first post, i know the 2 or 3 places in the firmware where the flash gets written, so it'd be easy for me to patch the firmware to do nothing and return OK. an even safer trick would be to write-protect the flash using the WP pin. not absolutely guaranteed to work, but at least it wont corrupt the flash.

and it's true, maybe the dakota hangs if it doesn't find the configuration areas in the flash. patching the firmware to avoid this can be harder. but precisely because of the story told by the guy who used my tools to flash an improper version of the firmware and got the "Er" message, i think the dakota enters a mode in which it continues to respond to usb commands and that i guess would include the basic "read/write to external mem" commands needed to read the flash, otherwise he couldn't have reflash the cam back to its proper version. to test the "read/write to external mem" commands, one would start with an old version firmware, flash the new and get the "Er" message, now test the commands (get a firmware dump, for instance), and flash back to the old firmware. again, the camera may hang with the flash replaced, but i would'nt corrupt the flash.

morcheeba, there are a lot of reasons why a cache would be a poor design choice. it'd be expensive, complex and slow. the page size (0x200) is way too large, and there should be full suport for all flash operations in hardware (otherwise, what if during a flash access op there's a cache miss?). and most of all, not all cams have flash, and most of those that do can't have the firmware in the flash. it would be hardware with no use most of the time. and besides, dram is better suited and must always be there and you don't need to cope with defects and contents need not conform to a particular standard. there's probably no such cache. if code is in the flash in this cam, it sure is copied/decrypted to somewhere else.

people, i thought of a way to hack this damn thing. it's easy, low tech, and could really work. but for reasons that'll become obvious i don't wanna post it here. those interested post your mangled emails here. or if you are concerned about doing that mail me at lanchon at hotmail (but how will i know it's really you?)

07-25-2004 13:26:24

New Messagepull-up resistors for data-outs could be configuration inputs for SMaL chip. (modified 0 times) newbee
Profile
It is a standard practice in industry to use those pull-up resistors for data-outs as configuration inputs. Not sure if that is somebody's patent or not but I have seen a lot.
07-25-2004 14:11:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) anikin_sniper
Profile | Email
anyone ever thought about just switching the two chips....we know the old blue was designed to be more than what it was...perhaps it could be easy patched to handle the lcd...if you cant figure one chip out but have one very similar perhaps the switch and mod the old firmware? Just throwing ideas out there...my soiderwork is too inconsistant for work like this
07-28-2004 02:19:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Gonna take longer than I thought- the asic seems to be back-powering from the data lines and it tries to take over. I'll need to lift the data lines and re-attach wires as well, if I haven't killed the chip- I think first I'll solder it back down and take another snapshot.

I'm having trouble reading the pdf for the lcd- morcheeba, where did you find a readable spec? Looks easy enough. In addition to the lines you have listed, I think there is also an analog brightness and contrast.

This is just a shot in the dark, but has anyone taken all 25 pictures and tried to talk to it?

07-28-2004 11:43:23

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Hi again guys.

I've been very busy at work lately so I haven't had time for the PV2 hacking. I did find some time today to do some probing. Using a very fine tipped probe and a tektronics scope i was able to look at the flash activity one pin at a time.

When starting up there's about 5 seconds worth of activity on the flash data pins and control pins. Most of the activity seemed to be read operations. The WE pin on the flash went active occasionally but not very often and for very short periods of time. I would guess this minimal activity was due to commands being latced into the flash and no actual writing of the flash took place.
There was quite a bit of activity on the R/B pin as well as the CE pin.

When turning the camera off there was a lot more activity on the WE pin indication that some data was being written back to the chip. Probably number of pics taken or something. This activity lasted for less than a second.
There was no activity while the camera was idle, There was some activity everytime a button was pressed. The status screens are probably stored in the flash.
Taking a picture resulted in 5-10 seconds worth of activity as expected.

The datapins operate at roughly 1.25 MHz. There is a very sharp spike of 25ns preceding each bit, possibly caused by bad logic design. This might be important if you intend to hook it up to a logic analyzer.

Trace showing activity on IO pin 0
http://pulsedpower.usc.edu/newpage/bit0.bmp

07-28-2004 14:24:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
regarding reading the flash in the old blue, some have concerns about the cam not starting cause it cant find config data, and also about the cam corrupting the flash. both are legitimate, but this takes care of them:

first, test that the cam will start up to a point of permitting flash dumps without the proper flash. add a switch to override flash CS to disable. or just constantly disable CS. plug the cam with CS disable. even if the cam shows "Er" or whatever, if you can dump the firmware in this condition then you could dump the flash.

then proceed to read the PV2 flash. now we need the switch, a full CS disable won't do. transplant the chip. and watch it: before turning the cam on or off BE SURE TO DISABLE CS!!! it may write to the flash during startup and shutdown (but not while idle), and would corrupt the PV2 flash (also be shure to disable CS before shutting down even before transplanting, for the same reason).

now plug the cam with CS disabled (it must start now because you tested it would). after startup, flip the switch to CS enabled. now dump the firmware. and before turning off switch back to CS disabled. (to be totally sure, you could configure your bios so that the PC stays off after a power interruption. otherwise, it would powerup the cam with the switch set to CS enabled and could screw the flash.)


hoppsan, the initial activity you saw probably was the firmware reading the flash out-of-band (spare) data in order to build the relocation table of the FTL.


earlier i said i thought of a way to hack the cam. i'm reluctant to post it here cause ritz or smal or whoever could be monitoring this thread (conspiracy theory; if i die my lawyer has an envelope). noone posted their mails, but some have mailed me. i don't know if they are who they say they are. they probably are. i could just trust, but instead i'm gonna ask some of you to post silly things so i can check. for the rest that haven't participated in the discussions, i'm sorry, i'll guess you'll have to wait till this attempt fails or succeeds. but think of it this way, do you want the camera hacked?

07-28-2004 17:17:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Lanchon

Lightbulb! ;)

Yeah, the initial activity could very well be just FTL data. There is no way to know without a decent logic analyzer. Come to think of it, the 25ns spikes I see on the datapins could be the effect of the flash dataport switching from read to write mode, again we need a decent logic analyzer to really know what's going on.
Perhaps it's finally time for me to build one.

07-28-2004 18:38:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
K9F2808U0B-YCBO vs. K9F2808U0C-YCBO

the difference apears to be a generation change:

B : 3rd Generation
C : 4th Generation

Part Org Voltage Temp Speed(ns) Package Simulation Production Comments
K9F2808U0C 16Mx8 2.7~3.6 C,I 50 48TSOP1,48WSOP1 VHDL,Soma Mass Production 0.12um
K9F2808U0B 16Mx8 2.7~3.6 C,I 50 48TSOP1,48WSOP1,63TBGA VHDL,Verilog,Soma EOL(Feb,'04) 0.15um

i guess they should be totally compatible

07-29-2004 00:32:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
piles_of_spam:

>the asic seems to be back-powering from the data lines and it tries to take over. I'll need to lift the data lines and re-attach wires as well, if I haven't killed the chip- I think first I'll solder it back down and take another snapshot.

i hope you haven't done that yet! there's one thing you could try first. instead of letting the asic backpower through its I/O protection you could fully power it but killing the oscilators. these chips tend to be highly configurable hardware-wise and there is quite a chance that the I/O pins are sort of dual/general purpose, and so they could wake up in high-z.... if the asic still lives. hope i'm still in time...

07-29-2004 00:46:39

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) chiusano
Profile
Has anyone had luck with transferring the chip to the old Dakota and reading it?

Rodrigo - rifle
chiusano@yahoo.com

07-29-2004 05:47:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lunaraspirations
Profile
Lanchon:

burritos..... :?)

07-29-2004 06:53:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) drider
Profile
Lanchon,
I really hope you can help because I need another cheapo camera for my other vehicle. I keep them in my "ashtray" for just-in-case. Thanks.

D.

07-29-2004 09:37:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Locosmotion
Profile
Lanchon...."Thermos"

Has anyone tried what Piles_of_span said yet, filling the camera with pictures then talking to it?

07-29-2004 11:43:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) wakebrdpunk
Profile | Email
Hey Lanchon, Ive been in and out of the house lately so ive been playing catchup with the forums. I am totally willing to try anything out with my pv2... I only got one problem, I am not very good at soldiering. So if you got anything that isint too hard with soldiering im willing to try it out!

wakebrdpunk@hotmail.com

07-29-2004 12:28:11

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Hey Lanchon- "bananas"

Clever!

Soldered the flash back down and it still works. I had a decent amount of resistance between the pic and the flash, so I didn't expect to have killed it, but now I'm back at square 1. I'll try disconnecting the oscillator- good idea.

07-29-2004 12:44:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
piles 'o spam - are you using this lcd pdf? Works fine for me -- what viewer are you using? If you send me an email, I can send you some screenshots from it, or re-print it with the Apple pdf generator.
07-29-2004 12:49:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Appl4U
Profile
Perhaps the Serial Number reset is some sort of self-disabling mechanism. Has anyone who had the serial number reset taken it into Ritz to see if they can still download the pictures?
07-29-2004 22:47:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) vthornheart
Profile
Hmm... okay, so I'm not the best solderer ever. =) Red went fine into pin 6, green into pin 8, black into pin 2... but when I went to put white into pin 9, my hand shook at just the wrong time and though pin 9 is in the right position, the solder that is holding it in has spread over to pin 10. I plugged it in, and I'm getting the two beeps that turn it on, and the USB icon pops up in the taskbar, but it doesn't try to find it. I went through the manual USB installation process (both methods that are explained in the readme file) and it still couldn't detect it. Suckfest! I've got to find a desoldering tube or something... ugh. Or since pin 10 isn't really used for anything, should it matter that the white cable connects to it and to pin 9 via the solder?
-Vendal Thornheart
07-29-2004 23:40:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) toddtmw
Profile
I just picked one of these up. Doesn anyone know if there is a way to delete more than the last picture (Or all the pictures...)?

This would be a great toy for my six-year-old if she could use it to take pictures and see them on the screen and then delete them and take more. I didn't realize you could only delete the last picture...that seems kind of uncool...

-Todd

07-30-2004 11:56:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) macisaint
Profile
Anyone wanna try opening a PV2, putting a USB bridge inside, going to ritz, getting your camera developed with your laptop, linked to a fresh PV2 connected via USB and forward the data back and forth?
07-30-2004 15:13:36

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 1 times) Kudzu
Profile

Anyone wanna try opening a PV2, putting a USB bridge inside, going to ritz, getting your camera developed with your laptop, linked to a fresh PV2 connected via USB and forward the data back and forth?

Nice try, but ..

They keep the camera, and they won't allow you to hook anything up to the camera while they process it.

08-01-2004 02:14:03

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) klothga
Profile

Nice try, but ..

They keep the camera, and they won't allow you to hook anything up to the camera while they process it.


Yeah.. there's plenty of room for a USB capable micro and a small flash in the case, but the chances of getting the camera back after developing are between slim and none...

08-01-2004 13:30:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) jorwex
Profile
so...is this basically a lost cause? i read about these dakota's once and was near a ritz yesterday so i grabbed one, not knowing that the PV2 had yet to be hacked. should i just return it? i havent opened it. thanks!
08-02-2004 13:22:46

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
Nope- not a lost cause- I've not been able to spend much time on it due to an exploding toilet (got a mess of water damage to fix).

HOWEVER- looks like the best chance of hack right now is to put a USB sniffer between the camera and the downloader. So how do we do that? Well, if anyone knows a Ritz, wolf, or willing CVS pharmacy employee that would help. Also, maybe anybody with a good usb sniffer could take up a collection here and slip the clerk $20 to give it a shot.

Morcheeba- thanks- turns out I was having problems because I was still using vers. 5 of acrobat. Looks like an easy interface- Hsync, Vsync, then data in RGBRGBRGB. I'll probably end up using it in a remote-control project.

08-03-2004 08:14:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
@Piles_of_spam

You really need to cut down on the chili dude ;)

Has anyone heard from Lanchon, I'm still waiting for news on his devious scheeme?

Also, about USB snooper. The best option would perhaps be to use a usb sniffer with a wireless transmitter. Does anyone know if they develop the camera while you wait?

08-03-2004 10:25:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) klothga
Profile
@hoppsan

There's room in the case, but not enough for a 802.11 card and antenna :) Maybe a mini-pci? Still going to be a _lot_ of work interfacing it with the micro doing the USB sniffing. And not too many other wireless devices that can handle USB bitrates.

If you're going to try to bribe a clerk (not something I recommend) you'd be better off putting initials and drawings on it and saying your daughter wants it back.. can you buy another one and put that in for recycling or something.. 'Course it would presuppose the afore mentioned internal sniffer. (Not that that is something easy to whip up, either..)

08-04-2004 11:04:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
There are wireless com chips significantly smaller than 802.11, granted not fast enough to relay the info in realtime but that doesn't matter. The micro could buffer the first couple of kB and retransmitt it at a slower speed. Hell, even just the first 36 bytes could be very helpful.

Ofcourse the "my kid wants the camera back" solution is a lot better ;)

08-04-2004 18:34:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) oldman
Profile | Email
Hoppsan, etc;

How about assembling a data recorder that saves to compact flash.
Put it in a PV2 case.
Take it to Ritz to get your pictures .
When their machine cannot communicate with the camera, ask for the camera back back since you got no pictures.
Take out the compact flash and read what commands their machine sent to the camera.
Write code to do the same commands.
Presto!

Have fun,


oldman
08-04-2004 20:05:39

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
serial transmitter:

6 pin SIP, 1.5 x 2 cm
100 meter range
3.3 V
10 Kbps (darn thing needs buffering)

U$S 15

http://www.usbdeveloper.com/RFKit/USBDeveloper.RFKit.html#RF%20Communications%20Modules

(too nice to give it away to pure digital :) )

08-05-2004 03:08:21

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
oldman,

that could work to get just the first private command. but it's not that easy, you'd have to play as another peripheral in usb. this could be done using an old blue hardware (and case), but someone would have to write the firmware. (i can't... perhaps morcheeba??? :) )

a snooper-on-a-chip using a usb-enabled controller and storing a limited snoop in internal ram (kept on by batteries) seems like a much simplier approach.

however a snoop is probably worthless. i guess these guys went from sunplus to smal for security reasons. do you think they did it wrong again? nahhh....

08-05-2004 03:24:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) 02U2
Profile
Lanchon,
Thanks for the link on the serial transmitter. Off topic and not camera related, but I got a bunch of small battery powered pir sensors that I'm planning in using for wireless perimeter intrusion detection.
08-05-2004 10:27:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) piles_of_spam
Profile
OK- toilet's fixed, dishwasher's installed, and my fingers are more or less healed. Back to hacking- wife's outta town this weekend so I might have a flash dump soon.

Also- I think you guys may have misunderstood me. I don't care if I get the camera back, because the idea of slipping the clerk a $20 is to LET me listen to what's going on in between. Basically, I'll have a shoebox with custom made cables in between the camera and the reader.

Something like this:

http://www.saelig.com/tracker.htm

So- here's a plan. We get a flash dump of a camera with a full set of 25 pictures (I'm on my way). At CVS Pharmacy, (CVS in particular since these cameras aren't anywhere near their primary business, and the kids that work there would most likely be thrilled to stave off the boredom on a slow night) somebody (or me if somebody wants to loan me the USB tracker) gets a full sniff of the full download. THEN we've got something to work with.

Anybody know anybody with a usb tracker/sniffer?

08-06-2004 11:35:56

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) jorwex
Profile
this probably won't do any good cuz its not a Ritz, but my friend works at Motophoto. Is there ANYTHING i could ask em to do that'd be worthwhile to this? THanks
08-06-2004 22:27:58

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) amall
Profile
Hey guys
Im new here and i dont no much about hacking this, so my help will be minor. Anyway, I found this forum of ritz employees and i figured you could ask them there. I didn't post anything there yet because i wanted to leave it to you experts. Here it is

http://www.retailworker.com/index.php?name=PNphpBB2&file=viewforum&f=24

08-09-2004 11:49:30

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) amall
Profile
Oh yea, I made u guys a username 2:
Username: atokadder
Password: reddakota

If u dont want it u can make ur own but im trying to help as much as i can :)

08-09-2004 11:54:35

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
I think it'll be best to keep it "clean-room" (i.e. not swiping/sniffing a downloader from Ritz), at least until all other options have been exhausted. Right now I'd like to find out

1) what's on the FLASH chip, and if it gives any insights into picture extraction methods;
2) more about the 'Bootloader' drivers of similar SMaL cams.

Slipping $20 to a Ritz employee to look the other way while a USB-sniffer runs, or snagging a copy of the download software, etc. may end up being the only options, but could also open legal worm-cans of various sizes.

08-15-2004 20:50:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Drmn4ea- agreed; I'd prefer the cleanroom. There are sympathetic Ritz workers who'll let you do anything with the equipment, but that's no fun.

I've got the parts & software to do the download, I just have to built the cable and move the chip onto my adapter (soldered in). The rom dump will happen; too bad my new company doesn't have the correct reader.

08-17-2004 19:22:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I got the imager under a microscope and the part number looks like "SCT-M033F". No luck googling, though. I could barely make out the color lenses that cover each pixel, but I didn't have a size reference to determine the resolution. We've got a much, much, MUCH better microscope, but I'll have to learn how to use it without breaking it
08-18-2004 21:55:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Agent5
Profile | Email
hey d00ds,
Just bought myself the PV2 and me and my Dad were playing around with it. I popped it open at the resturaunt we were at and I told him what i knew so far and asked for his opinion on the board and such. He used to do R&D for Texas Instruments back in the day and he knows his way around a board pretty well. When i told him that you only needed to solder four pins to USB connection. He seemed to think that was kinda funky because every engineer he knew and every board he made himself they only made pins that were necessary for the board to work correctly in connection with something or for it to work when they add or remove chips from the board in later models. Now back when I hacking i didn't have a computer so I settled for playing around with everything else. Mostly motorolla fones. Now before they got all freaky with their encryption and stupid default passwords, if you wanted to do stuff with the fone you just had to SHORT one pin to another pin and it woke up the programing that was TESTMODE.
Maybe we gotta short somethin to make this puppy work.
08-19-2004 08:48:40

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Maladroit
Profile
Agent5: supposedly the only modification to the Pure Digital reader was a software upgrade. Maybe the reader already jumpered some pins and the old cameras didn't use it, but the new ones require it? I suppose that's possible, but not so likely.

I think that a highly effective security system for this camera would be very easy to implement, and is probably the most logical answer. Look at the fact that the camera could possibly require a *36-byte* security code on startup, maybe within a few seconds of being powered. Even if thousands of geeks hooked up their cameras and computers to an Internet-based distributed brute-force key attack, and even if they were on the right path, it would take forever to find the key since it takes so long to restart the camera and try another key. Years, with a lot of luck and widespread participation. If someone successfully got the key, odds would be very high that the reader itself was compromised, and then they have legal recourse. Even if it took a month to find a key, Pure Digital could *easily* start flashing refurbished cameras with new security keys, and upgrade the software at the remote locations.

And then who's to say there isn't some sort of challenge-response verification? I think a simple long key would already be enough security, but Pure Digital has reason to be paranoid. Now that they have moved away from "security by obscurity," and are now trying "security by security" I think that hacking this device will be next to impossible, short of developing your own firmware assuming that firmware on the camera can be replaced. At the very least, this problem cannot be solved by pumping bytes into a black box and hoping something recognizable comes out.

08-19-2004 13:18:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billwiley
Profile
We won't be able to say with any certainty exactly how "impossible" hacking this camera will be until someone dumps the firmware. (probably by desoldering, hooking up to a reader, etc)

If the camera is waiting for a 32-bit integer, a firmware dump would reveal that fact and what the integer is, and we'd be in business without ever having to bother with the Pure Digital reader.

A near-impossible system would take advantage of a public key encryption scheme... the camera would first be sent a public encryption key, with which it would encrypt all pictures it stored in it's flash filesystem. Then, the Pure Digital reader would dump the pictures and decrypt them using their matching private key.

Another scenario, which I outlined in a previous post, is that they don't even have code on the camera that allows dumping - they might update the firmware with "dump code" to read the pictures, and then update the firmware a second time to remove the "dump code".

In either case, there's little point to assume the worst - even if either of the above cases are true, we will likely still be able to either patch the existing firmware or start an "open firmware" project.

08-19-2004 14:04:31

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) GWIZAH
Profile | Email
Wow, it's been awhile since I was here last. Im going to stop by a local wolf/ritz camera and see if I can "socially engineer" some more info on these while picking one up.
08-19-2004 15:05:29

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
right on bill.

Maladroit - there are side-channel attacks (i.e. reading the firmware) that don't require walking in the front door. The last camera was a simple challenge-response & I figured it out the algorithm disassembling the firmware. Good thinking, though.

08-19-2004 16:56:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Agent5
Profile | Email
It's too bad that we don't know if those developing computers have a network connection out. If it did we could just slap a trojan or a key logger on there and have it tell us everything we need to know. Hmmm...I just thought of something... What if we wiped these PV2's and put a totally new firmware on there. I think i remember reading something that someone said they were real similar to another camera. Maybe a different firmware would support that camera. Even if it didn't we could just get something close and mod it to work to our needs. If someone ever get s a dump of the memory on that thing we can then write a new software that doesn't require security and put that on there instead.
eh....just a thought.....
08-20-2004 12:06:33

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rgarito
Profile
Just a though--I've been contemplating getting one of these cameras to play with....

Is it possible that the 36 bytes the camera is looking for is actually 8032 code? (assuming it's an 8032 CPU core--I thought I read somewhere that it was). Some CPUs such as the 68HC11 will download a small bootloader program when started up in bootstrap mode. This program is loaded into internal RAM and then executed. In the case of the HC11 series, this code is usually a loader that in turn, downloads the actual operating code from the serial port. (in most cases, the loader program is used to re-flash the cpu).

That being the case, I wonder if the register mapping on the PV2 unit is similar to the original--anyone think they can write a small bootloader program into 36 bytes of code?

08-21-2004 14:17:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I've got an analysis of the flash memory. Seems to be that the bootloader in the ASIC reads a file called FIRMWARE.BIN from the flash, and presumably executes it. The pictures don't have JPEG/JFIF headers and are ~550KB each. Enjoy.
08-21-2004 21:34:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rangita
Profile
A dump! Fantastic! Could you zip/rar/targz up the files within and make them available? Also, the dump image itself would also be useful. Progress at last!
08-22-2004 08:09:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) codervinny
Profile
>microftxxx - the lcd is fairly easy to interface to: CLK, VSYNC, HSYNC, and 6 parallel >data bits. As for controlling with a microcontroller, the hardest part I'd think would be >finding one with enough memory to form a picture -- the display is 280x220 (each dot is >one of 3 primary colors, unlike how most computers define their screens), so it's about >60kB of information displayed.

-Quoted from Morcheeba

Regarding the LCD (Which I'm way more interested in; been going crazy trying to find a source for cheap displays for a project)

Has anyone successfully been able to connect an LCD to a computer and make it display stuff? And as morcheeba noted in his post, has anyone seen a usable microcontroller for the screen?

Also, I was thinking, according to the flash dump at http://www.maushammer.com/systems/dakotadigital/lcd-flash.html, the camera stores several help screens (look at PD-07.TFT) as TFT files. Would it be possible to use the camera's builtin LCD controller, e.g. have a computer create TFT formatted images, send them to the camera, and let the camera's controller display the image?

Any insights into using the LCD would be greatly appreciated. Thanks.

08-22-2004 08:49:23

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
rangita- I would love to post the firmware for people to analyze and learn from, but, sorry, i can't do that. It's copyrighted, so it's not mine to redistribute. Hopefully I can come up with a program so that people can read their own roms.

The reader is pretty easy to build - it cost me $50 for the SOIC adapter, plus $70 for the USB I/O board, pluse some time soldering. It was much easier to solder the chip than I thought it would be. I reused a lot of the old FLASH reader code from the old project - that's available for anyone who wants (for the mac, but it's posix)

codervinny- I'd love to do this-- should be possible.

Has anyone started probing the extra test points? R1, R2, R3 look promising.

08-22-2004 10:26:40

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
morcheeba, kickass! I'm assuming nothing glaringly obvious showed up in the firmware dump yet, otherwise we'd have heard about it by now But it's amazing you've got as much info as you do already.

You're right about the images - they're not JPEGs, even headerless ones, at least going by "ought-to-be-JPEG-markers" in the file ( http://www.funducode.com/freec/Fileformats/format3/format3b.htm ). If compressed, encrypted (or both) this makes sense.

But back on that firmware - you mentioned it isn't yet known what processor it's for. How would one find out? Is it mostly a matter of "disassemble it against every CPU and see which gives the least illegal opcodes" (ok, with at least some other sanity checks)? Or is there a more elegant (or insidious) method? Surely some previous firmware hacker in a similar predicament has written software to automate this, but casual Googling doesn't turn any up.

08-22-2004 15:19:35

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
When I wrote a disassembler for the sega vmu, I assumed an 8 bit-processor and tried about 10 different instruction sets... none of them worked, but a Sega USA employee said publically that it was a particular obscure Sanyo processor I'd never heard of.

I've tried googling for any press releases where, for example, ARM claims SMaL as a client, but no such luck.

There are other clues... I found some text, and then searched the file for the address I found the text at. It turns out I found a table of 16-bit addresses that points to the start of each message... they were stored in big endian format, so that's a clue. Being 16-bits may be helpful, but I'm not so sure... the firmware is 128KB (17 bits).

Thanks for the JPEG file format link -- I hadn't seen it put together so nicely!

08-22-2004 17:34:55

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) GWIZAH
Profile | Email
A dump! Yes!!! Can't wait to see what they did to hide the pictures this time.
08-23-2004 09:54:06

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billw
Profile
Just some observations to chew on...

-The RAW image from the dump isn't compressable in the least, so it's either highly compressed, encrypted, or both. I compressed some random jpegs of similar size, and they compressed a noticable amount more than IMG_0001.RAW.

-The gnu "file" command doesn't come up with any good identification on what the RAW image is, so you can pretty well rule out any common (unencrypted/unobfuscated) image/encapsulation format.

-The two hex dumps of images indicate a lot of common bytes. There's either a proprietary/unknown image header there, or they're using a saltless encryption (obfuscation?) on a known format. (ie.jpeg, png, etc.) I'm betting on the latter case.

Morcheeba, it's totally understandable that you keep the firmware to yourself, as nobody here wants to get you in trouble for illegally distributing stuff that isn't your copyright. Good luck on the analysis!

08-23-2004 13:26:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dis101
Profile
morcheeba - I bought one of these camera's ( for my 3 year old so she can play like daddy taking pictures ) the problem is at the
very end you cannot delete any more pictures. Hopefully you will be successfull (find out where the entry point to the program is) and
either change the program (put in a mod chip) to be able to go back to original or figure out how to do it on the USB. I was wondering if you could
do a memory dump from picture to picture and see what memory changes (is there a simple counter for the current picture?). Also in the firmware you
might look for references to the standard screen picture memory address?? I saw on your website you were looking for a recycled camera. I have one with all the picts taken I could donate or I could just give $20 bucks to the cause. I have a similiar background as you an ex rocket scientist from boeing I am now working on radar systems.
08-24-2004 09:46:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
great work morcheeba!!

by what you tell it apears the firmware code is not encrypted. maybe the cam is not that well designed after all. you can test whether it is encrypted or compressed by taking a bank of code, strip it generously of header and trailer, and compress it. encrypted code should be zero compressible (unless it is bitstuffed somehow to add redundancy, and i see no reason to do this).

the chipset is probably designed to run with a nonvolatile firmware not residing in the picture flash. this means that the setup of the PV2 missing this flash may be ackward to program and inefficient, all to avoid the cost of this flash. maybe it's like this, there is the custom onchip nonvolatile loader that knows how to access the picture flash and understands FAT (both read only). then an internal 16KB of ram is dedicated to hold code. of these 16Kb, 4 are constant and initialized to firmware file data at address 0. the other 12KB are bank switched to one of the bank areas in the file. the whole file is probably copied into DRAM at startup so that bank switching doesn't involve flash access or FAT indirection (avoids need for non-banked FAT and flash access code). every bank switch involves copying 12kb from dram to internal ram. this is incredibly inefficient, but remember the chipset was designed to run with a dedicated flash for code and this is just a hack to do without. code partitioning would be hand-done into functional units to avoid excesive performance hit from bank switching. on top of this, some of this 16KB memory could be used as data memory. ugly...

this accounts for all but the last 0x200 bytes, what the hell are they?? lets hope it's not a signature of some kind...

08-24-2004 18:32:34

New MessageDisassembly: CPU may be an ARC turbo-x86 (modified 0 times) bartoni
Profile
Just a possibility: A friend of mine worked w/ a MA based company on a credit card cam. That company may be SMAL. If I recall, the CPU used was ARC's turbo-x86. This would fit as it seems that the firmware indicates that the PV2 CPU is a 16-bit big-endian machine. If so disassembly should be straightforward.
08-24-2004 19:12:29

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) pyro
Profile
could i just go into wolf camera and like take the cd from them and get the driver. would it be a cd laying around posibly or maby slip the guy some money to put it on a disk for me
08-25-2004 22:14:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) GWIZAH
Profile | Email
I'd probably advise against that, unless you are very good friends with someone. By illegally obtaining those materials (which are basically property of wolf/and or PureDigital) you are putting yourself at risk of getting slapped with a lawsuit. Plus I doubt that anyone outside of warez groups would be willing to host any files you got from wolf/ritz/etc.
08-26-2004 08:10:19

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billw
Profile
There seems to be 2 camps of people here. Those that want to get the camera working by any means necessary,
and those that want the camera clean-room reverse engineered. I'm part of the second camp, and I'm going to
rant a bit to hopefully recruit some more people to this side - it may be a bit off topic. If you don't
want to hear it, or if I'm preaching to the choir, skip ahead to the next post.

It's ultimately preferable for us to do this "in the light" - even if it means that we have to wait months
more to do so. An illegally obtained reverse engineering (or outright theft of the capture software) taints
whatever is produced from it with the possibility of legal action. Yeah, we'd probably be able to download
the dump software from p2p for a while, but that would be the end of it.

I for one would love to see this thing grow beyond cheap camera drivers. If morcheeba figures out what CPU
is being used and how to dump flash over usb cable, I'll right in line trying to do the higher level analysis
of the existing firmware, and I imagine others here will as well. (I don't have the soldering skills to
duplicate morcheeba's work to get the firmware for myself)

Once that's done and documented, it's basically an open platform. We could create things like codevinny's
neato camera display idea, lift the picture limit, webcam mode, video camera mode, variable pic compression,
motion-detector mode, kid-friendly firmware (inspired by dis101), menu skins, etc. On top of the geek
factor, we'll have a $20 camera that outshines a lot of the other cameras featurewise!

Anyway, if you disagree with me still, that's cool. But one request - if anyone obtains illegal software,
for the sake of us that want this clean-room, please don't taint this forum with illegally obtained
information. Any of the clean-room folk disagree?

</rant>

08-26-2004 09:30:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Bhima
Profile | Email
Hi, I was just wondering if anyone had seen a Euro version of this version or the previous camera. I'd prefer a German market version so the shopkeepers stop looking at me funny when I ask for it. It doesn't really help when I tell then I don't care if they will print the images or not :) Also Bill's spot on with his request for legitimacy, the key thing is public comments (like this board for example).
08-26-2004 10:08:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
hoppsan - Just FYI: I didn't build a 3.3 interface -- I just used 50kohm resistors in series with all the data signals. Worked like a charm, at least for the 30 minutes it took to download. My I/O card was capable of using TTL levels, so all levels were compatible except the 5v>3.3v. I did have to provide 3.3 volts for the power supply, of course.

billw - well put, thanks. I write software for a living, so I've got to respect people's copyrights. As much as I'd like to put on my night vision goggles and go commando into Pure Digital's offices ... oh, wait, that doesn't sound quite right... scratch that thought.

bartoni - seems like the right start -- it's looking like an Arc core processor (either arclite or one of their bigger ones; not sure yet). That info thanks to a nice guy who emailed me with a ton of research.

dis101 - Thanks for the offer, but I'm looking for an old camera that has been resold -- it's got to go through PureDigital's "renewal" process because I'm interested in how well they do it. I looked at the bottoms of a lot of cameras in the store (too see if they were worn down or scratched) but didn't find any yet. Hopefully these cheaper cameras will actually get recycled -- for the environment, PureDigital's bottom line, and my curiosity.

08-26-2004 18:10:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lilbowser
Profile
I DID IT I DID IT I CRACK IT
08-27-2004 06:22:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lilbowser
Profile
i just kept throing it at the ground and it finaly cracked hehehhehehehe sorry just had to liven stuff up
08-27-2004 06:24:30

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) zippyut
Profile
Hi, good work to everyone with the progress you've made so far. I was wondering if anyone has tried dissecting the drivers from other cameras with the same SMaL chipset? I know some have been looking at Foxz1 without much luck, but a look at SMaL's web page shows the Radio Shack flatfoto, Logitech pocket digital, Oregon Scientific DS6618, Creative Labs CardCam, and FujiFilm eyeplate uses the SMaL products. http://www.smalcamera.com/download.html At least the ones from Logitech, Oregon Scientific, and Creative Labs are downloadable on their web page. It might prove useful in finding common commands. Of course, if each vendor uses a different key to enable communication with the device, we may be stuck (unless someone figures out how to reprogram it - or brute force finds the key).

In addition, the Oregon Scientific's is only $40 (no LCD, but you get a free lithium-ion battery). If we swap the flash memory, we might be able to figure out where the OS code is located.

08-28-2004 11:40:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 1 times) madhatter
Profile
maybe the proc core is a ARCtangent. According to:

original: http://moneyextra.uk-wire.com/cgi-bin/articles/20030730070354B2115.html
google cache: http://216.239.39.104/search?q=cache:xKyBqZgwCXQJ:moneyextra.uk-wire.com/cgi-bin/articles/20030730070354B2115.html+arc+core+%22smal+camera%22&hl=en

smal has obtained ARC technology.


"Consumer Electronics

A growing number of companies are evaluating ARC's technology for
consumer electronics. Recently announced companies, which are now
using ARC's products include:

Altek Labs, Inc., a Taiwanese-based company, manufactures digital
cameras for Konica, HP and Kodak. It licensed the ARCtangent processor
and ARC's MetaWare software development tool suite to aid the
development of next generation products.

Pictos/ESS Technology used ARCtangent technology and elements of the
MetaWare software development tool suite in both the Raptor 2 and 3
processors for digital cameras. Raptor 3, their latest product, was
just qualified by TSMC fabrication facility and is expected to go into
production soon.

SMal Camera Technologies selected both the processor and USB IP for
use in the world's thinnest digital camera.

Fujitsu Microelectronics introduced its new highly integrated IP-phone
VoIP chip for internet telephony applications in April. This product
is based on a user-customized ARCtangent processor."

08-28-2004 16:59:03

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Ooh, the irony. Linked from the ARC homepage: http://www.eetimes.com/in_focus/embedded_systems/showArticle.jhtml?articleID=22102797&_requestid=220694

"In response, suppliers are using processors to help improve the function and reduce the cost of their systems by shifting from proprietary communication protocols and complex wiring methods to open-standards protocols that use networking technology borrowed from other industries."

08-28-2004 17:46:09

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
chipwrights?
08-29-2004 14:00:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
I double checked with my friend about the ARC CPU. The company was indeed SMAL and the core used was what is now called the ARClite. They were working on the original credit card camera. I don't know if they continued to use that core in their later chipsets. I could get an assembler and maybe a disassembler for the core if you don't have one. Of course with only 30 defined instructions a Perl script could do the job. The problem would be if they defined any custom opcodes.

Also a Ritz camera sales dude said that they are locked out of the camera after they download the pitcures. He didn't seem too knowledable. If that is true, then getting a used camera may not help your effort.

08-31-2004 16:56:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) strae
Profile | Email
Hi all, long time!

Just a quick comment:

People are sort of treating the Ritz and CVS cameras the same - based upon what we saw with the wallgreens and original blue ritz cameras I would guess that there is some type of unlock code and that the algorythym is different in each brand. I am sure that CVS required assurance that the cameras could not be processed at Ritz and vice-versa.

That bootloader message is interesting - can a better programmer than me extract the communication routines from the original dakota and perhaps we can dump THOSE into the USB cable upon connection? It would be interesting (and incredibly lucky for us) if there is a key section of the code that is 64 bytes long, wouldn't it?

I picked up 1 of each (blue and red) from CVS and am dying to put them to use - I am glad to see that they are using REAL batteries in these, but it looks like the earlier focus mods are going to be much harder if not impossible in the pv2 models - probably a cheaper lens all-around.

It would be nice if we could get the LCD to do a live preview too - there are plenty of snap-over lens kits for cameras like the hp photosmart that would probably work well if we could see WHAT we were shooting.

Anyway - I will be dropping in a bit more again, meanwhile - I am going to pick up some more original blues while they are around!

09-01-2004 01:27:03

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) milpool
Profile
FYI, there is a $2 discount coupon for the PV2 in the Wolf's flyer in the Labor Day weekend papers.

I'm eager to hear of any progress!

09-05-2004 11:40:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Still churning through the code - added a paragraph of analysis and did a neat visualization of FIRMWARE.BIN.
09-06-2004 11:26:15

New MessageReverse engineering the PV2: educated guesses, possible approaches (modified 0 times) cambuilder
Profile
I haven't taken the LCD off my PV2, but I gather from reading this thread that there is only NAND Flash and SDRAM for off-ASIC storage. To me it is obvious that there is a programmable microprocessor in the SMaL controller chip. Someone guessed it is an ARCtangent. I would second that guess because ARC also sells USB IP for ASICs, and they also sell complete USB driver software for this home-brew microprocessor of theirs. Now the question becomes: is the entire camera application contained in ROM/Flash program memory inside the ASIC? My guess is no, because the USB driver plus file system code would be way too big to affordably fit in an on-chip ROM. This leads me to guess that (a) there is only a boot-loader on-chip, and that (b) the rest of the application code is contained in the NAND Flash chip. This would imply that the device is eminently hackable by reverse-engineering the NAND Flash contents, and either modifying it to give us what we want "in the clear", or studying the encryption system. Good luck, and keep us all posted.
09-07-2004 07:30:44

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Sully
Profile | Email
That ARC microprocessor seems very powerful. Is anyone interested in an ultrasound imaging project using that (or similar) processor? I have a nice application / market in mind & will give whoever helps me 50% interest in the intellectual property / company. I've been developing medical devices for 8 years but need help on the EE side to get this thing to market.
09-07-2004 17:18:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) strae
Profile | Email
there's an interesting concept - anyone have a parts list and price breakdown for red PV2?

It looks as if the processor and LCD alone are worth about $30 (except I cant really find this exact processor).
Imagine disassembling and reselling them as parts, hell, the batteries are worth another $1.50 too :)

09-09-2004 12:21:41

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) aaaa
Profile
On the page http://www.maushammer.com/systems/dakotadigital/lcd-flash.html , it is reported that the camera uses a "subset of the standard Smart Media format".

Since this format is so standard, is it possible that USB isn't the most trivial means for getting pictures?

It wasn't so hard to file a standard connector to fit the blue one (as luck would have it, it fits the new one too), so might it be easier to add a standard flash media interface to the camera.

Then, you:
1. take a dump of the existing flash.
2. copy that dump to a new flash card.
3. put the new flash card into the flash interface you put into the camera in step 0.
4. profit.

Noticable problems with this approach:
- Dumping the existing flash is nontrivial, and it is probably illegal to publish your dump for others.
- The hardware costs might be prohibitive.
- Last I read, the image format hadn't been figured out.
- Probably not for the clumsy (that's me!) or those who cannot be trusted with anything hot enough to cause burns (also me).

Just some thoughts.

My thanks go out to all of those who have so patiently and intelligently gathered the information we have to this point.

09-11-2004 01:13:16

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Hey everyone- a bunch of updates... I'm headed on a long business trip tomorrow morning, so I'll be out of touch. I'm going to a quiet, peaceful little town, at the base of a mountain. That had a volcanic erruption on wednesday. And I've got a good-sized toothache despite the denist saying everything's ok. And it appears that one of this countries enemies just detonated its first nuclear bomb. So, if I survive, I'll be back saturday. The best part of the trip will be the flying, of course... I'll be in the air for a total of 24 hours, so that means 24 hours of hacking!

Bartoni - Thanks for the info. It appears it is an ARClite 8-bit processor. It was a bugger to find info on! I found the instruction set, plus an assembler and a broken simulator. I'll publish this info soon. A good disassembler is much more than just some simple perl substitutions; it's more of a simulation. Here's a sample from the one I'm writing for this project:


0090: e4 f1 L0090: LDI R4,#$f1
0092: e5 0d LDI R5,#$0d
0094: e2 37 LDI R2,#$37
0096: e3 00 LDI R3,#$00
0098: 28 CLR R0
0099: 42 L0099: DEC R2
009a: 99 03 BR1 PSR_C,L009F
009c: 43 DEC R3
009d: 91 05 BR0 PSR_C,L00A4
009f: d4 L009F: STX R4 ;($0df1) = R0
00a0: c4 UPP R4
00a1: bc 9900 JMP L0099

There's a lot more work to go, but this program keeps track of registers -- their value and if they are known. The above loop example initialized R4 and R5 to the start address to write zero's to --- the program remembers this, and when the values are used at L009F, it comments the code. This makes it a lot easier to find all instances of the code that writes to $0df1. Soon it will say ;($0df1) = $00 because it'll remember R0, too. And if R0=(($1234)>>1)+$03, it should print that, too (that's a bit more complicated to do without consuming all memory in my machine!). The idea is that it does as much low-level processing as possible so it'll be quicker for me to figure out the high-level stuff.

Now the above example is a bit flawed because the code is in a loop - the address $0df1 is valid the first go around, but not the second (UPP R4 is a 16-bit increment). I don't know what I'm going to do with the problem-- keep it flawed like above (which would mean sometimes it has the wrong value, other code fragments illustrate that better), recogonize that it could be different and don't print anything, print a warning, or print a much more detailed description.

Anyway, I'm working on the bank switching (64K address space, 128 KB of code, gotta do something!), and hopefully after that I'll start looking at the filesystem and maybe USB interface. (filesystem is easier because I can see file names; the USB is harder to go on because I don't know any valid commands)

aaaa - good thinking. While the data is compatible, I don't know if there is any memory card format that is closely related electrically to the FLASH used. Maybe compact flash or smart media? I don't know... it would have a lot of pins (at least 16), The trouble is that this camera uses just a plain old memory chip, while many flash cards have a small controller in them too (to provide error checking/correction, drive multiple flash chips for bigger capacity, and to interface to a low-cost low-pin count connector). There's that image format thing, too, which is pretty major. But maybe a "firmware update" for another non-protected camera would solve that problem and the copyrighted-code-distribution problem.

09-11-2004 23:16:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
Pure Digital is hiring engineers to design the UI for the ritz camera software...

Drive the evolution of the Pure Digital software platform's front-end...

http://www.craigslist.org/sfc/sof/40343403.html

09-13-2004 06:33:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Krampack
Profile
Hello all.
First let me admit that 98% of what is in this thread
makes ZERO sense to me. Ok. Now, from reading...
and reading and reading... I noticed something.
I bought an LCD version of the camera at CVS.
Someone mentioned that it might be different from
other vendors. I think it is. 2 things that I can
note.
1) The "ghost" buttons. This model does NOT have
one to the right of the display button. Only four
in total. And a tiny VR2 ghost (No Idea.)

2) The boot test thingy gives several more lines of info
in my camera. Here it goes...
* Note the Different Firmware version!

Firmware 6520
Hardware 06
Type ID 30
CMP Type ID 30
ID DD4043405129
Realm ID 20

I hope that all means something to someone.

I bought this camera in a NYC CVS Store.
If you want me to look for something specific
please let me know.

Thank you.

09-14-2004 02:05:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
morcheeba - In the early days of VAutomation the V8, now the ARClite, was used to implement the USB protocol stack instead of doing it with a H/W state machine, so there might be some unusual code in the firmware. It is unlikely, as their USB has been H/W only for some time, but it is possible.

Also, I understand that one of the VAutomation founders and lead ARClite designer now works for SMAL.

09-14-2004 07:56:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
A few items of note from on the ARCLite product page (http://www.arc.com/products/soc/microprocessors/class_proc/arclite/):

-HI-TECH also offer the Salvo RTOS for ARClite, this is a cooperative real-time operating sytem (RTOS) that is designed for single-chip microcontrollers. http://www.pumpkininc.com/salvo/lite/8051/3.2/ = link for Demo...

could be the OS this SOC is running...

Also:
-Customizable assembler in ANSI C source code included
-An unusual feature of the ARClite is that it has two user-definable instructions. Replacing the most common, repetitive function in your application with a single instruction can yield a dramatic increase in performance without increasing the clock frequency.

09-14-2004 08:23:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j_tetazoo
Profile
I've been lurking here for a couple of weeks and thought it's high time I came out of the woodwork...

I bought a Flatfoto camera at Radio Shack last week (only $40). It, too, has the SMaL chipset. Anyone have any suggestions of some "non-invasive" reverse-engineering I might want to do on it that might help the Dakota PV2 effort? I say "non-invasive" because I don't want to doing anything that might break it, since I do plan to use it.

For instance, the Flatfoto has an SD card slot. I could pop a card in and take a bunch of photos and post whatever files I find have been written to it (presuming I can read them with my multi-format flash reader).

Also, is there such a thing as a USB sniffer? I wouldn't mind plugging the thing in and tranferring a couple of photos while sniffing the entire exchange.

09-14-2004 11:15:24

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
j-tetazoo,

Your camera could be most helpful. First we might be able to decode the image files by comparing them with yours.

Here are a few things to try:
If you read the SD card with a card reader are the image files .raw format? How big are they?
Could you put one .raw file on a website along with a copy of the image file produced when you download it from the camera using its host software.
Try downloading morcheeba's .raw image http://www.maushammer.com/systems/dakotadigital/IMG_0001.RAW, copying it to your SD card with a reader, and putting the card back in the camera. See if the camera can make sense of it or if downloading with the camera's software gives you a picture of morcheeba's cat.

09-14-2004 12:21:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mrgreen
Profile
I've been lurking this thread for a little while because I am interested in the LCD display of the camera. I can't calim to have any great knowledge of EE or hardware design, but I'd like to learn, and not spend to much money in the process. One thing I thought that might drive one of these screens fairly easily is the Intel PXA255 chip. It's the proc used in most (all?) Pocket PCs, and has an integrated LCD controller. You can see the developers manual with details on the LCD controller at ftp://download.intel.com/design/pca/applicationsprocessors/manuals/27869302.pdf.

You can get EXTREMELY small single board systems based on this chip, complete with ram, flash memory, usb, serial interface, and an MMC card reader from www.gumstix.com for starting at $110 (200mhz) up to $185 (400mhz w/ integrated bluetooth). They come with Linux preloaded as well.

I've got a project in mind that uses one of these and a small LCD (2" would be best, but a 1.5" would do at this price!) Any insight as to wether this LCD could be driven by this control would help me, and probably help the overall development of this camera as a parts resource.

09-14-2004 17:57:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) SteelBeak
Profile
I've been looking at morcheeba's .raw image and I've got to agree that it appears to be encrypted. What feels odd about that is the file seems to still contain a header of some kind. I'm seeing lots of null bytes that continue through 0x9d.

What do you guys make of this? If there's some encryption going on, these null bytes shouldn't be there, the file should be random all the way through. There's even more null bytes at the end of the file. It's all quite curious.

How far do you think the obfuscation/security goes on this thing? As I recall, the XBox had some false firmware to throw hackers off track. Any chance the same thing is going on here? I doubt it, but who knows, at $10/20 retail per-unit, they've got a big investment in getting those cameras back in for recycling if they want to turn a decent profit.

That header seems to hold a clue.

09-15-2004 13:20:41

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) strae
Profile | Email
Just did a real quick look, but maybe what we have here is a standard type of encoding like jpeg with an incomplete header?

Does anyone have a link to JPEG (and other format) header details? - it might be as simple as suppling the standard prefix for a JPG header (I will try this tonight)

09-15-2004 17:12:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
strae- we can check to see if the firmware is used by watching the FLASH interface during operation. Sure they could read the file and do nothing with it, but chances are they're not that tricky. Cost is sensitive here, too, and the flash is the cheapest place to put the image.

Someone on this thread tried compressing the RAW and a sample JPG image with gzip and found the JPG image was more compressible. That's good evidence of some sort of encryption, but I don't know if that means a shift-register-feedback type, XOR, or something more complicated.

Thanks Mr. Green for the gumstix board. At work, I just wrote software for a special $4000 driver board to generate custom video patterns to test our displays. I bet the gumstix board could do the same job for ~$200 and not require a dedicated PC. Might even make a nice giveaway for potential customers!

09-15-2004 18:37:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) scribble
Profile
The easiest way to discover if the images are encrypted is to make a test target of black and white stripes and take an image of justthe target. If the raw file come out quasi-random the images are encrypted. If raw file contains stretchs of nearly constant numbers with a sudden transitions to another stretch of different but nearly constant numbers the images aren't encrypted.

scribble

09-15-2004 19:42:58

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) strae
Profile | Email
Would that work if the camera has automatic image compression? the original dakota gives me wildly different file sizes.

morcheeba: When you say the raw and sample files didn't compress the same, are you saying they were the exact same photo? I can't locate any references to the 2 files other than the link to the raw file, what's the link for the sample jpg file? How did we manage to get the thing decoded? If it was processed by the retailer, it's possible that they change the resolution during processing so the file could become more compressable after processing (just my $9.75<adjusted for inflation>)

09-15-2004 21:44:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
wait a minute, the only evidence so far that this is not a recognizeable file format is:
-The gnu "file" command doesn't come up with any good identification on what the RAW image is, so you can pretty well rule out any common (unencrypted/unobfuscated) image/encapsulation format.

Not necessarily true, There is a ".RAW" file format specifically for digital cameras, and the format is used in other cameras made by SMAL.

Also, from http://wotsit.org:
-----------------------------------------
THE RAW (GRAPHICS) FORMAT

Basically, It's a raw format. There is no predefined format, not even for Image width and height, nor palettes, etc. The raw format is basically a type of import/export format rather than a storage format. For some systems and\or applications it’s a direct dump of the memory section containing the graphics information. Which means that encoding may depend on the graphics card memory arrangement itself. When opening a raw graphic format, the width and height must be specified usually, as well as when the picture data starts. There's other properties that needs to be specified sometimes. A raw file could be as simple as a stream of RGB values or as complex as random numbers as a header file with planar CMYK settings appended afterwards.

There's no standard between image viewers\painters. Some can write 16-bit and indexed colour graphics, but only read 16-bits or indexed colours. Some probably support RLE encoding. RGB is not always the colour information being recorded in the file, it can also be encoded as grayscale, monochrome bitmap, indexed colours, CMY, CMYK, HSV, HSB, or even L*a*b models.

Here's some ways a raw image could be encoded:
RGB [R Byte] [G Byte] [B Byte] [R Byte] [G Byte] [B Byte] ...
BGR [B Byte] [G Byte] [R Byte] [B Byte] [G Byte] [R Byte] ...
CMY [C Byte] [M Byte] [Y Byte] [C Byte] [M Byte] [Y Byte] ...
CMYK [C Byte] [M Byte] [Y Byte] [K Byte] [C Byte] [M Byte] ...
Planar RGB [R] [R] [R] [R] ... [G] [G] [G] [G] ... [B] [B] [B] [B]...
Image values could also start from the bottom and proceed to the top (like the Windows BMP)

I've tried the image in my versions of Photoshop to no avail, but there are always new filters
coming out. The image does open, however it looks like Television snow. I also tried reversing
the file and opening it. The image size is not known, and the type of colormapping is unknown.
What we need is a .raw file generated by a different camera using the sMAL chipset.
Anyone?

09-16-2004 03:33:32

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) scribble
Profile
Would that work if the camera has automatic image compression? the original dakota gives me wildly different file sizes.

I think it will. I believe most if not all compression formats work on small blocks of pixels. So if you have three or four black and white strips in the target,you will still see repeated nearly identical numbers in the file weither the image is compressed or not. Could be wrong, I'm not an expert on compression formats, but I still think it's worth a try.

scribble

09-16-2004 08:15:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billw
Profile
Sorry for the monster post, but there were a number of messages that I wanted to reply to.

Lakota:
-------

> wait a minute, the only evidence so far that this is not a recognizeable file format is:
> > -The gnu "file" command doesn't come up with any good identification on what the RAW
> > image is, so you can pretty well rule out any common (unencrypted/unobfuscated)
> > image/encapsulation format.
>
> Not necessarily true, There is a ".RAW" file format specifically for digital cameras

I wouldn't really consider RAW a real format, so much as a non-standard. Normally RAW images are uncompressed and should compress well, but this one doesn't.

If this format is indeed RAW+RLE, then it's pretty much equivalent to a proprietary format. RLE is an algorithm, as opposed to a format, so it can be implemented in all kinds of ways - 8/16/24 bit, with different sequence sizes, position and type of sequence markers, etc. And, I have to agree with SteelBeak - it really looks like there's a header in those RAW files.

In any case, if we're going to figure out the format from the non-firmware angle, we're going to need more than one example pic. A bunch of photo's (like scribble's idea of black and white bars) would help, but morcheeba's already extracted his flash from the camera. Is anyone else trying to dump flash?

It sounds like morcheeba is narrowing in on the firmware analysis, so I'd say it's probably easier to see what comes of that, then to try to analyze a closed picture format with one example. Just my $.02

Strae:
------
I was the one that did the compression tests. I didn't have the same image - I took a sampling of 10 JPEGs of similar filesize - pics that I knew had come from different cameras (and I also I downloaded a few from the web). I could squeeze each JPEG some amount, at least 1-2%, which is quite a lot considering I was recompressing a lossy compression scheme.

The RAW image was the only file which grew in size (by 0.5%). I used both winzip and bzip2 for the compression tests and recieved similar results with both.

Admittedly, doing this with one .RAW image isn't exactly a scientific study, and the percentage deltas weren't huge, but I found the fact that the RAW image was the only one to grow in size to be significant.

To me, this means one of either 3 things is true:

1) They're compressing the images with an algorithm similar to winzip/bzip2, so that winzip/bzip2 isn't finding anything to chew on.
2) They're squeezing the hell out of their JPEGs. (if they're using JPEGs) The images would look terrible if this was the case, so I doubt this is true.
3) The data looks like random data to the compression routine, due to some kind of encryption.

Without further evidence, I'd objectively have to say either 1 or 3 could be equally likely from a technical point of view. But given SMaL's comments about the next camera not being hackable, I'm betting on 3.

09-16-2004 12:17:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
On the RAW image file format:
From page 32 of the RadioShack SMAL UP3 based camera user manual: "Note: Because the files stored in your camera are specially compressed to increase storage capacity, images must be downloaded using Photo Album before the images are converted into JPEG format images for use with other programs or computers."
The ARCLite is probably not doing this compression. The imager is, hence it is called a RAW file. If this is the case, firmware disassembly isn't going to help much in decoding the images. RLE compression is a good guess as I wouldn't expect anything too complex on an imager chip.

j_tetazoo, Any progress on my suggestions?

On the ARCLite:
I've located an old V8 Core Reference manual. The memory map can be defined by the designer but the default settings are:
Program execution starts at 0x0000 on startup. Thus BIST/BOOT code resides at 0x000 to 0x1FF.
System hardware registers are usually mapped to 0x200 to 0x2FF. Page register at 0x200, Control register at 0x202, bit #3 is interupt enable. Power save contoller at 0x230. Timer at 0x260-0x263. There are others in there but I don't think they apply. Peripherals are usually mapped starting at 0x280.
The Stack Pointer is usually set to 0x3FF on startup and grows downward. This is consistent with morcheeba's analysis. The stack would go where the asterisks are and would not normally be paged out. This _may_ imply that the pattern ".2." in morcheeba's analysis is some sort of marker for the bottom of the call stack. Perhaps they are branches to a reset routine.
The NMI vector is usually at 0x400 (LSB) and 0x401 (MSB).
The other seven interrupt vectors follow.
General purpose RAM usually starts at 0x410.
The Processor Status Register is 8 bits, the four MSBs are set or cleared directly by user code. The LSBs (3..0) are Interupt Mask, Negative, Carry, and Zero.
The core is often configured with 2 register sets for fast interrupts, sort of like a Z-80.
Note in the ARCLite diagram that there is an 8-bit TEMP register in the address generation logic block.

09-16-2004 12:22:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j_tetazoo
Profile
> j_tetazoo, Any progress on my suggestions?

Not yet. I think I'll get to it in the next day or two. I'm constrained by the fact that I bought the camera as a present for my 5 yr old, and I haven't given it to her, yet, so I'm only able to mess with it after she's in bed. :)

I'm thinking of doing a number of things...

1) Taking pictures of: absolute black (basically cover the lens and snap a picture), a white wall, and a checkerboard.
2) Posting both the .raw and the .jpg files for other folks here to pour over.
3) Trying bartoni's suggestion of copying morcheeba's .raw file to an SD card and popping it into the camera and seeing if it knows what to do with it.

That brings me to a question. Any suggestions on where to go for free web or ftp space for the purpose of uploading my .raw and .jpg files?

09-16-2004 12:45:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) SteelBeak
Profile
The RAW images definately have an unecrypted header. Bytes 0x03 - 0x06 contain the filesize of the .RAW image. Byte 0x07 (and 0x08 maybe) is probably the header size. 0x00-0x02 would be the 'magic' or identifying marker for the filetype.

Also worth noting, bytes 0x43-0x45 seem to point to the start of the null bytes at the end of the file. Since I don't have the complete IMG_0004.RAW file I can't be certain. But if this is true, the field at the end of file for IMG_00001 is 16 bytes while the end of file field in IMG_0004.RAW would be 56 bytes. If this is true I wonder why IMG_0004 would have a significantly larger field at the end of the file from IMG_0001.RAW.

When comparing the headers for IMG_0001.RAW and IMG_0004.RAW (given here) you can see quite a lot of the headers are the same on both. With that much redundant information this is probably NOT a proprietary file format.

The data that begins at 0x9d is most likely encrypted. It's probably the entire JPEG file. If this is true, then the fact the the first 3 bytes beginning at 0x9d differ between the two files means we're not dealing with a simple XOR or substitution cipher. There's probably either a random salt value or initialization vector being applied here. If we're lucky, that info is stored in the header...

The interesting thing here is IMG_0004.RAW seems to contain more information in its header than IMG_0001.RAW. I'm curious as to why that is.

That's what I've got so far.

09-16-2004 13:11:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) SteelBeak
Profile
Scratch the encryption talk in my last post. After I posted I saw bartoni's post and I started checking out manuals for various SMaL-based cameras. bartoni seems to be right, SMaL, it appears, has their own RAW format. It's not encrypted, just compressed, thus the same amount of statistical randomness as you'd see in an encrypted file.
09-16-2004 14:11:06

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billw
Profile
j_tetazoo:
Check out http://www.cexx.org/files.htm for sites and guidance on online storage. This is a rather legitimate use of the online storage, so I don't think you'll need to use any of the obfuscation techniques discussed.

It would be most interesting to compare your RAWs with the one from the PV2.

SteelBeak:
Nice analysis! Though I wouldn't count out encryption just yet. It's possible that it's applied post-imager, even if Bartoni is correct about the imager being the source of the RAW format. I find it hard to believe they'd rely upon security through obscurity after being bitten before with the PV1. (But I'd be happy to be proven wrong!)

09-17-2004 09:20:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
@strae: I found some decent documentation on JPEG file format here: http://www.funducode.com/freec/Fileformats/format3/format3b.htm . Of interest, the files from Maushammer's cam don't appear to be valid JPEGs (even headerless ones) - a JPEG file is delimited into pieces (e.g. header, quantization tables, image data frames, etc.) by markers consisting of 0xFF followed by one additional byte from a limited set of possibilities. The .RAW files contain 0xFF bytes (presumably just by chance), but when I looked at the bytes following them, they didn't constitute valid JPEG delimiters. (In real JPEGs "by chance" 0xFFs must be followed by an 0x00 so the parser knows this one wasn't meant as a delimiter.)

@everyone: For anyone(s) able to read the FLASH memory off their cam, it may indedd be instructive to take a few test shots of e.g. "all black" and "all white" and stripes / checkerboard pattern (as suggested by scribble). Bear in mind that unless you physically pull some lines from the CMOS sensor, you'll never get a pure black/white image since there will always be (a sometimes significant amount of) random sensor noise in the image. These images should still be considerably smaller than "normal" though; and may thus prove easier to poke with via "file parsing by hand", statistical analyses, or etc. (and as a bonus, you'll still know approximately what a correct decoding should look like).

09-17-2004 17:48:14

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Just for fun, I created some images in PaintShop Pro to emulate what might be gotten from an "all black" (dark room with some opaque cold thing over CMOS image sensor) image - posted at http://www.cexx.org/dakota/pv2stuff/ . For three of the images, I created an all black image and added (2%, 4%, and 8%, respectively) RGB uniform noise (file names: #Unoise.jpg, where # is the noise percentage). For another three, I added random noise (1%, 2%, and 4%) (file names: #Rnoise.jpg). The "random" noise is random both in noise placement and intensity; the percentage affects the sparseness of the noise. The uniform noise samples are closer to what you might expect the camera to actually produce. All images are 1280x960 and saved at PSP's compression level "15%" (which officially corresponds to nothing in particular). Finally, I saved a *pure* all-black image with the same size and compression setting.

What's slightly interesting to notice: The all-black image is VERY sparse; in fact consists almost entirely zeros. The 2% uniform noise file is also very sparse, although it does contain some non-zero bytes in the image portion. The FFxx header format really stands out in these images, since there pretty much isn't anything else in them. But the sparsity drops off very sharply going from 2% to 4% uniform noise; this file looks almost "normal". The random noise files are similarly dense (even 1%) - JPEG is not really meant for this type of data to begin with (rapid light-dark changes; in this case, one bright pixel with pure black surrounding it), which is evident in the resulting image (furry halos around bright pixels).

I have access to MATLAB at the office; if I'm feeling sufficiently bored (or antisocial) over the weekend, I might try shoveling in data from these, the existing .RAW files and some 'real' JPEG images and see if any patterns emerge (e.g. histograms of 'character' count (0x00 ~ 0xFF), other statistical stuff like that). I don't expect to see anything at all by playing codebreaker-wannabe, but it might at least rule stuff out.

09-17-2004 18:34:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
RAW format - i think gphoto people have already done some research into this. Check out this page (although I haven't seen the exact details yet). He has a decoded image posted.

Back from my trip. Plane trip was not as productive as I thought it would be, but still made a bit of progress. Gotta get outside today; too much sitting over the last week.

bartoni - I'm coming up with a little memory map and that doesn't seem to fit what I found.
My guess:
0-90 boot code (doesn't make sense - too small. gotta figure out)
0090-0fff first memory page area (always points to same area)
1000-3fff second page (swaps between different sections of code)
f8xx, f9xx and other fxxx addresss are control registers. Lots more code to analyze, so I probably haven't seen FLASH or LCD interfacing yet.

Here's the info I've been using (all processor info, no memory map) -- thank you, wayback machine!

09-18-2004 02:03:54

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Pendragon445
Profile
The flatfoto camera software will not decode the image_0001.raw file by copying it onto the flash and trying to read it out. It recognizes that there is an image there but gives an error trying to decode it.

The RAW image is around 500k, but the JPG output is only around 30k. I'll have some all black and all white jpg/raw sets posted later in the weekend as I get the chance to upload them. This may help someone out there determine whats up with these formats.

09-19-2004 12:38:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I looked at the RAW format decoded by libgphoto2 and it looks like it expects something totally uncompressed. The cameras supported by that driver max out at something like 640x480, so that's not too unreasonable. The conversion is basically a de-bayer-pattern with a gamma correction -- the PV2 seems to also require decompression and/or deencryption. It'll probably be helpful down the road, but as is, doesn't do the job for us. I haven't tested it with libgphoto, but PenDragon's trial with the standard software pretty much confirms it. Thanks.
09-19-2004 14:57:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j_tetazoo
Profile
Well, I found some time to play with my Flatfoto over the weekend, but it looks like Pendragon445 beat me to the punch. I, too discovered that when I copied morcheeba's IMG_0001.RAW to an SD card and popped it into the camera, and then plugged the camera into the USB port, and then attempted to download it, the software barfed.

I also snapped a couple of photos and downloaded them to my computer, but when I popped out the SD card and looked at it with my reader, the RAW files had been removed and replaced with JPGs. So, the moral here is that you need to pop the card out and grab the RAW files BEFORE you download them using the Flatfoto software.

I didn't get around to re-doing it in that order (so that I could post corresponding RAW/JPG files). But, given that apparently the Dakota PV2's RAW file is not compatible with the Flatfoto's (my conclusion after the failed experiment with IMG_0001.RAW) I wonder whether there is still anything to be gained in doing so (wouldn't want to spend resource looking at the Flatfoto RAW files when they're not representaive of the Dakota's).

09-20-2004 08:32:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) SteelBeak
Profile
I'm guessing, to keep the hardware cheap, interpolation and related functions, including JPEG encoding, is all done by software. (Perhaps the Autobrite stuff that SMaL talks about is also software side?) So these .RAW files are probably compressed and contain the raw output from the Bayer filter.

The gphoto stuff that morcheeba linked is pretty interesting, but the header in the data pulled down by the slimshot driver doesn't match with the header format we're seeing in the .RAW files. So either some decoding is taking place during transfer from the camera, or the slimshot file format isn't the same as the PV2 stuff. It could be that we've got like a "version 2" of the header format and that looking at the slimshot driver and just reworking the header could yield some results.

What's interesting is that the driver's author talks about some extra info that gets pulled down with the image that the driver ignores. I recall an article linked to by one of the PV2 sites where a rep for Dakota or someone related says that even if a driver was hacked together to download the images, they wouldn't be as high quality as those obtained by having the cameras brought back for 'development'.

The extra info the driver ignores might be related to this. Could this be 'Autobrite' feature?

Lots of things to look into.

09-20-2004 11:01:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
morcheeba, - Wouldn't the stack and the hardware registers be in the first page where they wouldn't get paged?
I can only guess the stack pointer powers up, or is set by S/W to 0x00FFF, so that the stack grows down to 0x00D60 (approx.)
If they put the hardware register just below the stack, as they were in the default memory map, then they would be at 0x00D0 to 0x005F.

I'm betting SteelBeak has this right: "The extra info the driver ignores might be related to this. Could this be 'Autobrite' feature?".

The slimshot driver might still be useful. If I were at SMAL designing the next generation imager, after the one used in the SlimShot. I'd make incremental changes like: boost the resolution, add compression on the image pixel data, and leave the header information largely untouched. If something like this was done then the uncompressed pixel data format should be similar to that of the SlimShot but with more pixels per line.

09-20-2004 16:19:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Pendragon445
Profile
Here's the link to the sample flatfoto raw and jpg's for anyone interested.
http://loveshack2003.tripod.com/photo.htm
Don't worry about the title it's not an adult site...it's a reference to the B52's song.
09-20-2004 18:32:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
morcheeba,
Would it be possible/legal for you to tell us which code blocks read or write the various files?
Do they use the STA (store absolute) instruction to write the memory mapped system registers, especially the page register?
If so, can you tell us which code blocks call the others?
09-21-2004 13:33:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Bartoni - I forgot to say thanks for the good work -- please pardon my rudeness!

I think I used the wrong terms to describe my guess of a memory map. I'll refine it a bit...
0000-007f unknown
0080-008f looks like a vector list, but all execpt 82/83 point to same address. (82/83 isn't initialized by FIRMWARE.BIN; it must be done by bootloader) Haven't analyzed the code at that address yet. It's LSB/MSB. Maybe it matches the standard $400-$40F?
0090-0fff a fixed area of RAM that doesn't use pages. Probably contains the stack at or just below fff.
1000-3fff A window where multiple banks of memory get switched in. It seems to be switched in from the SDRAM and not the FLASH, but not sure.
fxxx Seems to be registers because locations are addressed very sparsely.

Questions:
Is the NMI for this processor the same as reset?
The NMI vector: does it point to the first byte of the code to go to, or does it point to the first byte - 1?
The 8-bit temp register in the address generation logic - that's the page register @ 0x200, right? Any clue if this is associated with any particular bits or a page size? It appears that the SMaL processor is pretty flexible, allowing specification of the start and size of the window (besides the page to see through that window)... not sure of this yet, though.

Don't know where the boot code is, but it seems elaborate -- it must configure the FLASH and SDRAM, follow the directory structure to find FIRMWARE.BIN, and then map this into memory somehow, and then start execution. I'd say that could fit in $200 bytes.

09-21-2004 13:56:24

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
forgot to mention.. found evidence that code starts at $400 in some other address space (I'm guessing start of SDRAM), but it appears that it actually executes at beginning at address $0090. Long explanation, I'll know more when I've got enough of the pieces put together.
09-22-2004 16:32:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
morcheeba, In reply:
The V8 manual says that NMI is not the same as reset. Reset sets PC=0x0000, PSR=0x08, and SP to default.
In contrast, interrupts including NMI load the PC with the vector address and don't increment PC prior to fetching ISR code.
INTs push the PSR then the PCH then the PCL. Then the DL register (seems to mean the temp register) is loaded with the next code byte, the ISR PCL. Last, the ISR PCH is loaded from code into the PC along with the DL contents. Totals: Six cycles. Two PC incrs. Three SP decrs.
Here's roughly what the manual says: PC is incremented (prior to being pushed) for a S/W INT. PC is not incremented for H/W INT. Ensures the correct opcode is executed upon return from ISR. A S/W NMI (i.e. INT,0) is usually reserved for debugging. This might be consistent with 0x0080-0x008f being the vector list. Meaning that they're only using INT,1 and all others including NMI are unsused.

The temp register is not the page register. The page register is in the memory map. As above, it seems that this temp register is called DL, perhaps for data load. I merely mentioned the temp register before since you said a good debugger has a simulator in it and you'd need to know that there's a temp in the address generator block.

The manual says that the V8 VHDL/Verilog shipped with sample BOOT and BIST code. The sample BOOT code was 384 bytes. It read data from serial I2C EEPROMs into RAM. If the checksum failed it would wait and download new code from the UART. The camera's BOOT code is clearly different as there aren't any serial ROMs. The sample BIST code was 128 bytes. It seems that this was executed prior to the BOOT code. So 512 bytes total for sample BIST & BOOT.

What is the address in 0x0082/3? _If_ the INT,1 ISR code _is_ initialized by FIRMWARE.BIN then this address may enable us to calculate where FIRMWARE.BIN gets loaded into the machine's overall memory map in the DRAM including paged addressing which might look something like:
(I'm not suggesting this is anywhere close to correct. I'm just spelling it out to get my idea across.)
0x00000 - 0x00cff BIST/BOOT (on-chip)
0x00d00 - 0x00fff H/W registers for mapped I/O subsytems (on-chip)
0x01000 - 0x01fff Stack (on-chip SRAM)
0x02000 - 0x1ffff FIRMWARE.BIN (fisrt segment now located from 0x02000- 0x03000 doesn't get paged)
Thus lowest 12KB doesn't get paged the next 12KB is paged.
What are the addresses attached to likely LDA instructions? Shouldn't these tell us where the hardware registers, including the page register, are in the machine's overall memory map? Once we discern which LDAs are to the page register, then we can better guess at the map from what it is being loaded with, (which should be various addresses differing by 0x03000), right?

09-22-2004 19:53:35

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
http://ludd.net/~fmason/ARCLite.CrossCompiler.Demo.7.85.zip

hope this helps...

09-23-2004 01:33:15

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
morcheeba,
I thought about the machine/SDRAM memory map a bit more. I think that the first part of all the firmware code blocks clears memory because the code blocks actually overwrite each other as needed in the same non-paged part of memory. So any code that wasn't overwritten must be cleared. Thus, the lowest 32KB, non-paged segment in the SDRAM map would contain: BIST/BOOT, H/W regs, Stack, INT vectors, character generator tables (1ea RGB), message tables, a buffer area used to move things from one high page to another or to/from files, and 16KB of code space. The higher 32KB pages would be for TFT frame buffer, raw image buffer, compressed image buffer, and maybe a copy of firmware.bin to speed copying.
09-23-2004 15:29:47

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
Interesting observations about the .RAW header block:

The total length of the header seems to be 0x9C, so the first 2 bytes
might be the length of the header.

Furthermore value 0x9C seems to be used as a record delimiter (?) <--- not sure of this.

0x0043: pointer to extra data at the end of the file (4 bytes).
0x0047: length of the extra data at the end of the file in 8 byte units.

The extra data at the end of the RAW image looks like a 4 byte/4 byte offset/length pair
signifying tables of some sorts.

Are there any more .RAW images available to analyse ?

09-24-2004 06:26:32

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
daBass - nice work! I posted IMG_0004.RAW a few days ago, but those are the only two that images that ended up on my camera (maybe 2 and 3 still exist but were deleted?) I limited the number of pictures I took so that there would be less information in the FLASH to plod through, but the file format was really easy, so I should have put more pictures in. I'll eventually get more pictures in there, but I really want to limit the number of times I put the flash chip into my reader because I might damage it ($50) every time I solder it in. Hopefully I'll have some code changes ready to try out before putting it back in to the camera.

all - Work on the disassembler is going well.. I'm pretty sure I found the routine that switches banks, but it's pretty complicated. It could be complicated enough that it's actually DMA'ing in data rather than bank switching. Yes, it is a loop of some sort! Also found the 32-bit add and 32-bit multiply functions. Disassembler is improving, too. It automatically identifies the start and stop of functions, and now I'm building in a function CRC-generator so that comments across different versions of the firmware can be attached to a function and not an address. As you can tell, identifying the bank swithing is taking a while and I'd like to add comments to the disassembly... but if I change the disassembler too much, patching old comments into a newer version output won't work too well. Hence, that's why I'm putting more effort now into getting the disassembler to better support comments as in input format. (sorry for the ramble; hope that made sense!)

09-24-2004 12:18:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
A guestimation about the filesizes and the CMOS size of the PVR2.

Guestimation: the CMOS size is close to a Megapixel (1280x1024 max).

The most inefficient uncompressed RAW file that can be produced would be a straight Bayer output RGBG, so 4 bytes per pixel.

The most efficient uncompressed RAW file that can be produced would be an I420 transformed picture (1 byte Y, 1 byte U every 2x2 pixel, 1 byte V every 2x2 pixel), so 1.5 bytes per pixel.

In the most inefficient case an uncompressed RAW file would be close to 4 Megabyte, in the most efficient case
an uncompressed file would be about 1.5 Megabyte.

Statistical compression (ZIP / BZIP) usually has an efficiency of 40 - 60 % on raw image data (depending on complexity of the scene), so seeing file sizes of 512 - 600 Kilbbyte would confirm an image at Megapixel size using 1.5 bytes per pixel compressed with a statistical compression algorithm.

Anyone have a better guestimation ?

09-24-2004 16:09:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) hoppsan
Profile
Hi

I wrote a small application that goes through the image files and prints out all instances of 4 consecutive bytes that could possible be a pointer (pointer<filesize), It produces a reasonably short list of pointers including the ones listed by dabass. A lot of the pointers can be immediatly discarded as they are just strings of 0x00 thereby further reducing the number of possible pointers. Also pointers containing the same bytes also needs to be culled.

List of pointers for img_0001.raw
http://peggus.freelinuxhost.com/pointer1.txt

List of pointers for img_0004.raw
http://peggus.freelinuxhost.com/pointer4.txt

command line program (win32) for scanning a file for pointers, Usage: findpointer.exe inputfilename outputfilename
http://peggus.freelinuxhost.com/findpointer.exe

09-25-2004 12:15:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Lanchon
Profile
morcheeba:

"I'm pretty sure I found the routine that switches banks, but it's pretty complicated. It could be complicated enough that it's actually DMA'ing in data rather than bank switching. Yes, it is a loop of some sort!"

in my posting of 08-24-2004 18:32:34 before you started disassembly i conjectured this type of memory model and the rationale for it. (i don't have the firmware as you know, so i'm afraid i can't be more helpful.)

09-25-2004 19:21:11

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) axon1
Profile
has any body had any progress with this , any info on to how we might be able to develop a driver yet ?
09-26-2004 13:24:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
bartoni- I just read your post from 9/21, and even though I replied twice to other posts, I still managed to miss it!

Would it be possible/legal for you to tell us which code blocks read or write the various files?
I haven't gotten there yet... still concentrating on the bank switching.
Do they use the STA (store absolute) instruction to write the memory mapped system registers, especially the page register?
If so, can you tell us which code blocks call the others?

There are no stores to an address less than $0d00.
The first BSS area is $0df1, length $37, seems to be used exclusively by code in 0000-ffff. The second BSS area is $3ae8, size $0278, and it seems to be used by code in 1000-3fff. These match the $30's found in FLASH memory.
Of course, still working on the bank switch, so not a lot of new info - just wanted to follow up.

The disassembler is coming along well. Spent a lot of time this weekend fixing it up rather than analyzing FIRMWARE.BIN. It should pay off in the end by making the analysis easier. It has already found some repeated code. I'll update my firmware page with some features of the disassembler.

09-27-2004 01:07:33

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
FYI: I was allowed to look at two used PV2s at the local Ritz store this past weekend. After the pictures have been downloaded the cameras start with the splash screen then go to a black screen with the words "READY TO RECYCLE". They do not respond to the buttons after that. I did not try to get it to start with the configuration screen as the salesman was watching closely.

Morcheeba, Great dasm work! You may want to sell it to ARC. What is a "BSS" area? Also sometimes when you give addresses it isn't clear if you mean in the system memory map or the location in firmware.bin.

09-27-2004 18:02:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
The BSS area is basically where global variables that aren't initialized are stored. For reliability, they are still initialized to zero's, but these values aren't defined in the C code. (another definition).

"PD-04.TFT" is a graphic that says "Camera Full" in big purple letters, and "Please return for prints" in small yellow letters down below. But, then, I also so "READY" and "TO RECYCLE" in LANG.TXT, so I guess that's where it's getting that from.

Sorry about the addresses... I'll get them figured out.

09-27-2004 22:37:24

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) metalmike6
Profile | Email
Hey everybody i've been reading this post for a while now and kinda messing around with all the information i've seen... i thought i'd report what i found here... for the record, i don't know a damn thing about hardware programming but i just to sit my ass and watch you guys do all the work...Now then, i'm using windows 2000 and i was trying to see if i could get the camera to be recognized... after trying a buttload of drivers with a buttload of exclamation points in device manager, i finally installed one that worked... like when i say worked i mean the driver went in with no problems, and when it did the camera beeped twice. the device in device manager also shows up properly

here's the kicker

the driver i used is for a AIPTEK CHE-EZ sound familiar?... it uses the exact same chipset as the dakota camera... and moreover get this... the software for the aiptek version of the camera is the only way to get the pictures out(officially anyway), because they are compressed, now here's where my theory comes in.... is it possible that the software thats checking the camera for pictures is looking for a file on the flash card with a certain file extension and all you'd have to do is change the software to look for a different file extension and it would pick up the photos

now this is either the dumbest theory ever, or not... let me know at mdaddona@heinekenusa.com

09-28-2004 11:29:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Lanchon gets a gold star!

It looks like there is no page switching; access to all other code is done by DMA'ing it from SDRAM into on-chip SRAM. Because this DMA transfer will take time (and power), that means the firmware has to be carefully written.

So, I've worked out a memset routine for the SDRAM, and the lower-level DMA routine. Besides the actual bank-switching routine, I've got to work out a bunch of other routines that also use the DMA. Then, I've got to port this page-switching model back into the disassembler and disassemble the code in the other banks (4000-1ffff). Then, there's so much more to do!

09-29-2004 00:27:03

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) newbee
Profile
metalmike6, where did you get the driver ? I don't think it would be that simple but I might just have a look what that driver would look for. Thanks.
09-29-2004 01:30:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
Found out some more interesting information, I probably should setup a web page to describe everything in detail, but for now here it is.

SmaL is leveraging their platform really quite well (see http://www.smalcamera.com/products.html) Including a nice press release about the PVR2 (see http://www.smalcamera.com/pressreleases/puredigital.html) which I had not seen mentioned before.

Current and future camera's based on the design are:

Ultra-Pocket Digital VGA Proto, SMaL Camera Technologies, Inc.
Ultra-Pocket Digital VGA, SMaL Camera Technologies, Inc.
eyeplate/SLIM SHOT, FUJIFILM AXIA CO.,LTD
Pocket Digital (BTLDR), Logitech
Pocket Digital (TCF-3), Logitech
FLATFOTO, RadioShack Corporation
CardCam (BTLDR), Creative Labs
CardCam, Creative Labs
Pocket Digital (BTLDR), Logitech
Pocket Digital (TCF-5), Logitech
Reserved[0x0007], Unknown
DS6618 (TCF-5), Oregon Scientfic
Reserved[0x0009], Unknown
Reserved[0x000A], Unknown
Reserved[0x000B], Unknown
Reserved[0x000C], Unknown
Reserved[0x000D], Unknown
Reserved[0x000E], Unknown
Reserved[0x000F], Unknown
Ultra-Pocket Digital MP Proto, SMaL Camera Technologies, Inc.
Ultra-Pocket Digital MP, SMaL Camera Technologies, Inc.
eyeplate/SLIM SHOT mega Proto, FUJIFILM AXIA CO.,LTD
Oregon Scientific DS6628 (BTLDR), Oregon Scientific
Oregon Scientific DS6628, Oregon Scientific
eyeplate mega (BTDLR), FUJIFILM AXIA CO.,LTD
eyeplate mega, FUJIFILM AXIA CO.,LTD 1.3 MP Digital Camera
Reserved[0x0016], Unknown
Reserved[0x0017], Unknown
SLIM SHOT mega (BTLDR), FUJIFILM AXIA CO.,LTD
SLIM SHOT mega, FUJIFILM AXIA CO.,LTD
Reserved[0x0019], Unknown
Reserved[0x001A], Unknown
Reserved[0x001B], Unknown
Reserved[0x001C], Unknown
Reserved[0x001D], Unknown
Reserved[0x001E], Unknown
Reserved[0x001F], Unknown
Ultra-Pocket Digital 2MP Proto, SMaL Camera Technologies, Inc.
1.3 MP Digital Camera, SMaL Camera Technologies, Inc.
PocketCam (BTLDR), Philips
PocketCam, Philips
PocketCam, Philips
Foxz
Foxz2
2.0 MP Digital Camera, SMaL Camera Technologies, Inc.
Legend Digital Camera (SMaL), Pure Digital Technologies, Inc.
Legend Digital Camera, Pure Digital Technologies, Inc.

The interesting ones in this list are the BTLDR based camera's.

The BTLDR based camera's need a special application on the receiving side to get the pictures out of the camera.
In some cases it also does the conversion from RAW to JPEG (and a heap of postprocessing).

The drivers for these camera's come with a 32K bootloader that is downloaded to the camera before pictures can be loaded off the camera. (On win2000 these have the extension .pack on XP these have the extension .pck).

These .pack/.pck files have been confirmed by me to contain valid (unencrypted) V8 code. (I'm in the process of
writing a disassembler and simulator for the V8 to play around further with the code).

Anyone interested in the VHDL code and some more information about the V8 should have a look at: http://www.ece.neu.edu/info/vhdl/class/HomeworksExams/FullDocument.htm .

09-29-2004 02:40:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
DaBass ... sounds like it's time for me to release an early version of my disassembler, right? It's command line and should be easy to compile with gcc (it'll need linking, too). Would this help you?
09-29-2004 13:45:27

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) rc123
Profile
I am a thinker more than a hacker, but have an idea. Would it be possible to reprogram the firmware so that it writes the pictures without encrypting them, instead of trying to figure out how to decrypt the pictures?
10-01-2004 22:11:31

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
The .pack images seem very promising if they can be easily decompiled (morcheeba, we'd love to try an alpha of the decompiler). It appears the .pack files would give us direct access to the camera as it would conveniently load up any modified boot images we create. Creative's "Cardcam Photo Album" app appears to submit the .pack file to the camera, I will try to get a USB snoop of this. The creative cardcam (BTLDR) .pack file mentions FIRMWARE.BIN, DCIM, and 100VGA, so there are at least some similarities with the Dakota firmware...

The SMaL press release says clearly that the images are encrypted but not compressed.

10-02-2004 15:07:52

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
rc123 - Yep, that's a good possibility. There are so many ways to make useful things out of this camera; it would be impossible for PureDigital to prevent all uses. Besides bypassing the encryption (rather than breaking it), you could just use this as a little game platform. Or just enable viewfinder mode all the time and add some infrared LEDs, and ta-da, cheap nightvision.

L - A USB snoop would be terrific! It would also be interesting to see if you can use this to upload other code. I'll try to put up an alpha version. It's not all that pretty, but very functional. You'll have to modify main.c to add new enntry points. The code will change a lot to support bank switching (I've got some stubby cheats in there right now that always assume bank #1).

The SMaL press release says clearly that the images are encrypted but not compressed.
My guess is that this is technically a lie, but there's a good reason for it. I suspect it's losslessly-compressed and then probably encrypted. Otherwise, the size of the RAW files wouldn't vary. I suspect that they don't want it confused with a lossy jpg compression.

10-02-2004 22:41:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
Finally had some time to setup an information page. See http://www.digitalfluff.net/pv2/ . It contains some more information about the .RAW image format, about the .pack / .pck files and some V8-uRISC tools (disassembler, simulator).

morcheeba, I would like to have a look at your implementation for the simulator/disassembler.

About the encryption/compression of .RAW files. My best guess at the moment: simple inflate/deflate compression combined with possibly a XOR.

10-03-2004 04:45:34

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
The creative software didn't yield any info during the USB sniff. The hacked .inf file was not enough to get the software interacting with the dakota at all. I may try editing the binary looking for the VID but that is pretty desperate.

I know nothing about USB programming, but these 2 tools look pretty promising for prodding the camera from Windows via the USB interface. With USB monitor I get the addresses for the endpoints, which I plug in to USB TrafficLab and send to the device, and then I see the response from the camera. If anyone has any of the other BTLDR cameras with software could you please run USB monitor on the startup and/or a file transfer for us? USB trafficlab has "playback" capability so this could be promising...

USB Monitor: http://www.tucows.com/preview/332433.html
USB TrafficLab: http://www.download.com/USB-TrafficLab/3000-2383-10259285.html

(eval versions, appear to function more or less, USB TrafficLab setup is a little dumb, you have to install their driver in the place of windows' USB Root Hub driver to do anything)

10-03-2004 06:35:02

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) kbd_dilligaf
Profile
After purchasing a Blue Dakota Camera and then finding out, after taking it apart, that it was the PV2 model, I started watching this thread on a regular basis. All the documentation I had read at the time indicated that all new model Dakota cameras would be marked either on the packaging or camera with “PV2” but that’s now water under the bridge as they say.

I noticed a post from Metalmike6 who had indicated that he had successfully loaded a driver onto the PV2 camera. Shortly after that post, Newbee posted and asked Metalmike6 where that driver could be located and has yet. I got curious and did a little searching and found a webpage of someone who had also successfully loaded a driver onto a PV2 camera so I gave it a try (www.bluedonkey.org). Because I had the blue vs. the red camera, I had to change the device ID in the .inf file from 27 to 28 and was able to load the drivers that were posted on bluedonkey.org. A link to the page is listed below:

http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Linux/DakotaPv2Camera

I knoticed later that this link was posted earlier in this thread but I don't know if j94501 had links to the drivers at that point. I hope this little bit of information helps.

kbd_dilligaf

10-03-2004 09:12:36

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I've got an alpha version of my disassembler posted here. It's pretty rought and will change. It's also got a sample of my comments file - it's not as complete as my other notes, but I'm slowly adding to it. I've also started a hardware analysis page, which is currently a memory map, but will include registers.
10-03-2004 14:02:56

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) codeknowbi
Profile
Long time lurker, first time poster.

I think 0x19-0x1A = 220, 0x1B-0x1C = 280 which may be the Thumbnail size.

It may mean that the first (or last) part of the data stream may be a thumbnail.

10-10-2004 13:08:48

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
codeknowbi- welcome! Sounds good. I just ran a quick check of the first and last 61600 bytes of both image files and ran my tft2tga program on all 4 images. Well, any preview image at either end isn't in their TFT format. It may be in some other raw-like format and/or compressed. My guess is that it's there (why else have the size), but that it's encrypted with the rest of the picture data.
10-10-2004 21:26:25

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I've updated the disassembler to handle bank-switching gracefully. Now all the code is visible, and the next stop is to manually start identifying larger sections of code.

There's a main switch routine in the $0000-$0fff address range that will jump to code in one of the banks (mapped to $1000-$3fff). It's structured really weirdly, though. There's two ways I'd write it:
1. Pass an address and a bank to jump to. Very simple.
2. Pass an index of a function to jump to. This function's bank and address is looked up from a table and jumped to.
But, actually, it uses a weird hybrid:
3. Pass an index of a function, plus the bank number. Only the function's address is looked up from the table.

As a result, I've got a list of addresses (see FIRMWARE.COMMENTS), but I've got to find where the bank-switching function gets called to associate the list of function addresses with bank addresses. Or, I could just look at the code in each bank and see what's reasonable.

Of course, there is no PureDigital nor SMaL code in the release; you've got to suck the software out of a memory yourself to use it. But, even without the code, you may find my comments in build/FIRMWARE.COMMENTS interesting.

I've also removed the hard-coded entry points and moved this to the FIRMWARE.COMMENTS file. This should make it easy for anyone to disassemble one of the .pak files found in various BTLDR drivers available for download from camera manufacturers. I've got to update my known register list to help others out.

10-16-2004 00:28:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) lakota
Profile
Whoa morcheeba that was a lot of work. I still haven't decompiled the other sMAl driver code. I'll try the more recent version of the decompiler. No luck with USB trafficlab either. It's a pretty beta tool, plus USB is complicated.
10-18-2004 03:57:27

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) toml
Profile
Did someone need a processed camera that's "Ready to Recycle"? I have one and the CD of pictures that comes from the processing machine that I could donate "for the cause." Post here and whoever you all think would do the most good with it can have it.
10-18-2004 07:37:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Some nice work tonight! I found the associated banks for lots of the functions that get called, so the disassembly of the rest of the code is falling in to place. So far it's 32k lines (& 1.4MB) disassembled, and I don't see any "wild code" (where non-code information, such as text, is mistakenly interpreted as code). My FIRMWARE.COMMENTS file is now 584 lines & 25KB. Probably a little more work getting the rest of the code to disassemble, and then I start trying to figure out what the next level of things do...
10-18-2004 23:31:36

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 1 times) boodle
Profile
I saw mention of usb sniffing, thought I may be able to help out - check out http://www.lvr.com/usb.htm especially the section named "Protocol Analyzers"
10-19-2004 00:30:44

New MessageAutobrite RAW file implications (modified 0 times) bartoni
Profile
Just in case this hasn't been noted elswhere.

Regarding the RAW format:

The PV2 sensor implements "Autobrite". What this means is that each pixel is encoded in two fields. It is a sort of mini floating-point with a positive exponent and positive mantissa. To decode a pixel you have to left shift its mantissa by its exponent amount.

Note that the exponent does not encode powers of two but of four, eight, sixteen etc. So an exponent of 0x01 does not mean multiply by two (left shift one bit). Instead, if they are using base four, an exponent of 0x01 means multiply by four (left shift by two bits). A 0x02 exponent in this case would mean multiply by sixteen (left shift four bits).

I don't know the sizes of these fields on this camera. In fact, the sizes may change from picture to picture depending on its dynamic range (but I doubt this). Neither do I know what base the exponent encodes. So the rest of this is educated speculation.

The exponents and mantissas aren't likely any bigger than four bits each. My guess is that the exponents are two bits and the mantissas are four bits. This would mean, assuming base four, four bit mantissas shifted by up to four bits yielding eight bits/pixel. (What about the exponent 0x03? It may not be used, or their driver decodes each pixel into ten bits and then resamples the whole image back to eight bits.) They say their sensors have the equivalent of a twelve bit dynamic range so this might mean a two bit, base sixteen exponent. 0x01 means left shift four bits. 0x02 means left shift eight bits. 0x03 is probably unused.

Without RLE this encoding gives six bits per pixel and image file size of about 6/8(1300x900pixels)+header. Since the files are smaller than this I'd also guess that the exponents are RLE and the mantissas are either raw or RLE separately. If the encoding is compact then one byte of the exponent record is two bits of exponent and six bits of run length or two, two-bit exponent and two-bit run length pairs. If the mantissas are RLE I'd expect four bits of data and four bits of run length per byte.

So after the RAW file header I'd expect either two records, one of RLE exponents and another of mantissas w/ or w/o RLE, or one record (perhaps divided into RGB planes) of bytes containing the exponent, mantissa, and a shared two-bit run length.

Lastly, morcheeba, u d'bomb! Please keep posting updates of your firmware comments file.

10-22-2004 12:36:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Ok, some more progress - to the disassembler and to my analysis. Hopefully someone gets interested enough to build another FLASH reader!

The disassembler automatically comments constant initializations (32-bit memory, 16 & 32-bit registers) -- pretty helpful. It now lets me name variables and it incorporates this into the output. I've also put together the correct bank numbers for all the code entry points found in the table. There's a lot more undisassembled code & I've found a couple of computed-gotos, so there's still hope. Also, I've identified some more math functions. No more info on the hardware registers or sdram usage, though. Here are the stats so far...

last version: disassembly = 32k lines, 1.4MB, FIRMWARE.COMMENTS = 584 lines, 25KB
this version: disassembly = 48k lines, 2.1MB, FIRMWARE.COMMENTS = 1059 lines, 42KB

There are a *lot* of repeats. Each bank has its own copy of all the essential library functions -- memcpy, memset, multiply, 32/16 bit add/subtract, etc. The multiple banks don't use the copies of these routines located in the unbanked area. They differ a little bit because of which temporary variables they use.

Fun, fun. Thanks bartoni! Are you sure the autobrite is like this? I guessed it was just extreme gamma because the sample gphoto image I saw didn't seem to have bands (which is what I'd expect to see with a mini-floating-point). I'd link to that picture, but I posted it before & it's really late here. Time to sleep. (and compressing these as two different sections is a great idea - it would really do wonders for the compression!)

10-24-2004 02:07:19

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
> Hopefully someone gets interested enough to build another FLASH reader!
I'm interested enough to build a Flash reader, but the biggest obstacle to overcome is getting a PV2 in Europe .

I'm concentrating my efforts on analysing the V8 code inside the pack files distributed with SMaL based camera's.
I'm mainly focusing on the file t14-a04-f02.pack, because it should be pretty close to what is inside the PV2.

The angle I'm currently trying to figure out is the following:

Inside the file are two interesting string tables. The string table used for USB communication, and the string table
used for accessing the filesystem.

By analysing the code to see where the 2 different string tables are accessed, and also checking the code to see which hardware registers are accessed close to an access to the string tables, I should be able to figure out which hardware registers are used for USB communication, and which hardware registers are used for accessing the Flash.

This information can than be used to see if the code from the PV2 accesses certain registers in the same way (same read write pattern).

I thought the Autobrite TM looked like applying different types of gamma correction to different parts of the picture.

10-24-2004 07:33:06

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) toml
Profile
>> Hopefully someone gets interested enough to build another FLASH reader!
>I'm interested enough to build a Flash reader, but the biggest obstacle to overcome is getting a PV2 in Europe .

I could send you the "ready to recycle" camera if you sent me a prepaid shipping label from ups... ;)

10-24-2004 20:55:44

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Ok, more progress. Some software infrastructure documented, and I started in on the filenames that I found. I found two sister-functions that probably read and write from the file NVRAM.DAT. And I found a lot of references to "FIRMWARE.BIN" - not quite sure why that's so popular. Once it's loaded into SDRAM, it shouldn't be needed again.

And, most interesting, I found a section of code that handled all the pre-set TFT images (PD02-09). This lets me identify major sections of code, and I've got some plans for this info.

I've got a ton of good leads to follow still ! Too much fun this weekend; I may have to take a break.

last version: disassembly = 48k lines, 2.1MB, FIRMWARE.COMMENTS = 1059 lines, 42KB
this version: disassembly = 48k lines, 2.1MB, FIRMWARE.COMMENTS = 1670 lines, 66KB
(note: disassembly size didn't go up too much because the auto-generated function headers were replaced with much-more-informative customized comments of about the same number of lines.)

10-24-2004 22:50:37

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) GWIZAH
Profile | Email
Morcheeba you is da man! At the rate this is going, I hope to give some of these away as "stocking stuffers"!LOL :)
10-26-2004 14:41:21

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) toml
Profile
Anyone make any progress with using the LCD for anything other than the camera? I was thinking of some cool projects that I could use it for, if only I knew how to control it... :)
10-28-2004 08:49:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
just bought 1 red and 1 blue pv2 red firmware 6430 hardware 06 type id 27 ID DAA 042350344

have modified centronics cable head for usb ......

windows xp 2 gets unknown device .... sniffusb displays unknown device and shows present yes when connected
and show present no when disconnected.....

have tried libusb/sucr foxz2 drivers can get nothing to happen.....
have tried patching vid/pid etc but noda.......

any ideas

10-28-2004 09:23:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) eDice
Profile
ok here is the pic. well i keept playing with the wires trying to find hidden buttons. and i think it worked. the camera kept telling me that there are no more pics to delete i had 20 in left so i used a wire from + to all the transistore u can see in the pic after i bit the previos picture came up and i deletet. now i have 21. :) but i think i messed something up when i try to turn the camera on it beeps 3 times and thats is. so i dont know what to do. but u can try it. if u realy whant to play with it. good luck.

http://www.freewebs.com/idice/11.jpg

10-29-2004 14:41:26

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) scribble
Profile
If any one else want to play this "blast the transistor" game solder a 2 to 5k resistor in series with your probe wire. That way your camera 'might' survive.

scribble

10-29-2004 19:15:23

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
daBass has done some really cool work with analyzing another SMaL-based camera. He's found an interesting USB command (for that non-PV2 camera) & I think I've found the code (in the PV 2) that handles it. I don't see how the CPU reaches this code, and there is lots of code afterwards to analyze, so it'll still be a while, but I'm excited. Then we need to figure out the images are encoded!
11-02-2004 01:19:39

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
More disassembly progress... I found a USB function, but haven't traced all the parameters it accepts.

last version: disassembly = 48k lines, 2.1MB, FIRMWARE.COMMENTS = 1670 lines, 66KB
this version: disassembly = 48k lines, 2.2MB, FIRMWARE.COMMENTS = 2257 lines, 89KB

11-04-2004 01:44:32

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
I managed to get the PV2 to talk over USB. Only problem is, at the moment I don't understand what it is saying .

I'll make a more complete description available on my website as soon as I have time. (Most of the information below
can also be found in morcheeba's latest FIRMWARE.COMMENTS).

Talking to the PV2 can be done by using interrupt / bulk transfers. I've been using configuration 2 interface 0
with libusb.

Send out commands on endpoint 0x01 using interrupt transfers. Commands can be 31 bytes, and have the following format:
0 - 3 "LaMS"
4 - 7 <id>
8 - 11 nr of bytes to read (play with this, 0x00 0x00 0x01 0x00 is a good starting value).
12 unknown, 0x80 is a good value.
13 unknown, 0x00 , 0x01 , 0x04 are good values to try.
14 unknown, 0x00
15 command byte, try 0x52 to start, others apply as well
16 - 19 unknown integer.
20 - 31 unknown.

After succesfully having sent out a command, the answer can be read back with a bulk transfer from endpoint 0x81.

First coming back is the number of data bytes specified at position 8 - 11 followed by 13
bytes confirmation (of the form "LaMS"<id><no bytes>0x64).

Hopefully someone with a little more USB knowledge than I have can make more sense of this.

11-04-2004 16:46:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
Dbass;;;

is your firmware 6410.......
I have 2 cams red/blue both are 6430 .....
my laptop will detect the cams plugged in ,,, but will not enumerate [ie] will not respond to vid0-pid0
get unknown device

my 2 desktops will not even detect these being connected

laptop xp sp1 + hotfixes
both desktops have xp sp2
laptop is dell c10 usb 1,1
desktop1 clone usb 1,1 desktop2 clone usb 2,0

11-06-2004 08:54:18

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
mike,

> is your firmware 6410.......
> I have 2 cams red/blue both are 6430 .....
> my laptop will detect the cams plugged in ,,, but will not enumerate [ie] will not respond to vid0-pid0
> get unknown device
Yes, but I don't think that is the problem.

This is
> laptop xp sp1 + hotfixes
> both desktops have xp sp2

In order to use libusb with a USB device under Windows, a driver needs to be installed.
(the little icon thingy in the statusbar telling you it found a Digital Camera is not enough).

I misused the Foxz2 driver as driver for the PV2. Install this driver first (see somewhere on this
board where to get it). After install locate the file smalunhj.inf (It should be under "Program Files"
with 4 other files) open it and make the following changes:

Under [SMALUSB.models] add the line:
%USB\VID_0DCA&PID_0027.DeviceDesc%=SMALUSB.Dev, USB\VID_0DCA&PID_0027

Under [Strings] add the line:
USB\VID_0DCA&PID_0027.DeviceDesc="Pure Digital PV2"

Now plugin the PV2, the new hardware wizard should come up, make sure that you can select your own
driver and point it to the directory where the .inf file is located.

After doing this, the USB double beep should sound and the ready light will come on.
Now you can use libusb (the testapplication coming with libusb should be able to enumerate
the device).

An alternative is to use Linux an libusb for Linux (no driver needed).

If this does not work for you, try to contact me (or leave a message on this board).

11-06-2004 12:57:21

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I just got the cable soldered on my second camera about an hour ago... I'm getting prepared to start trying to communicate with it on my mac - it's just a simple user-land program. The camera enumerated fine without any setup. Luckily, my second camera is also version 6410 - same as the one I totally disassembled. We'll see...
11-06-2004 13:58:51

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) jonnie
Profile
Sorry for back tracking here, I just picked up a blue pv2 (I assume) from CVS (I assume it's a pv2 as it has model 400 pon the bottom). I just wanted to double check a couple of things. Is the usb cable setup the same as the old style dakota's (I have that setup now, but am having issues getting just a basic connection, so I wanted to make sure that wasn't the issue first). If it's the same, I'm not having any luck getting any of the drivers to "bite", I've followed the 2 specific explainations listed above - neither work. But I'm finding that if I run testlibusb - win I just get

DLL version: 0.1.8.0
Driver version: not running!

So I'm assuming I've done something wrong.

This is a facinating thread BTW.

11-07-2004 19:21:30

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) KiwiPat
Profile
I have been reading this site for a while, and have a few interesting ideas for these things once we get them working. Alas my tech skills are a bit lacking, and certainly not up to those of Morcheeba, though when you get through your disassembly I will be in the line to buy you a beer.

I have a couple of thoughts and observations though.

Currently it appears that the only way to get the .raw image files off is via a flash reader - not a trivial task. Is this correct?

On previous cameras (walgreens), it was possible to add a smart media card as the chip formats were compatible - does anyone know if this is possible for this one? Has anyone looked at it?

The last point is that there has been some discussion on whether the .raw files are encrypted. As I see it, the only way to determine this is to get some standard images - all white, all black, checkerboard (not an original thought I know). Has anyone done this? I also wonder if the images are encypted based on the serial number of the camera - I imagine easy to do. To check this would be easy if we could get the same image off different cameras (I am sure I am not the only one who has unintentionally taken black photos). If the images are significantly the same they are either not encrypted or encrypted on a standard method. This comes back to getting the images back off.

I know that I have not added anything to the body of knowledge we have, but just thought these questions might set something running.

Thanks

11-07-2004 23:37:56

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Yep, the only way to get the pictures so far is to use a flash reader. I'm getting data from the camera over USB (daBass beat me to it , but I'm not totally sure where it is coming from and, although it is repeatable, I can't control it too well.

The old walgreens camera was sortof like a prototype. It was a regular camera with a pcboard that replaced the smart media socket & provided the card-edge connection -- very expensive to make. The PV2 is the camera they should have done in the first place - very cheap, purpose-built, nothing extra. The chip that is used probably is capable of connecting to a media card, but it doesn't look like there are any wires for this. There may be some pads that you could connect to to do this, but it's not obvious.

Two ways to encrypt: one key for all cameras, or one key per camera. It depends on how they do the encryption - the software may be too slow. For individual keys, I doubt the key is custom-burned in to each ASIC, so if it is in the FLASH, you could change it to a weak key (or a public key you know the private key for). If the key is the same for all cameras, having it in the FLASH is still a liability - so it may be in the ASIC. A system-wide key in the ASIC is my bet.

.. but with the code in the FLASH memory, there are plenty of things to play with. And if you don't need to get pictures off the device, you can still have a lot of fun (think remote LCD display, or small homebrew game console)

11-08-2004 10:38:24

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
dbass

thx for driver info although was not the problem.....

all usb cables are not equal
mine... green to 10 red to 9 black to 8 white to 7
red & black are biggest wires... cable may have been made wrong???

any way pv2 blue is type 28 .... get bootloader
pv2 red is type 27 .... have not got boot loader msg

ready led's come on both....

the following was captured while loading drivers


PV2 RED-------------------------------------------------------------------
000000: PnP Event: Device Connected (UP), 08.11.2004 20:40:38.8477008
The USB device has just been connected to the system.
000001: PnP Event: Query ID (UP), 08.11.2004 20:40:38.9879024 +0.1402016
Device ID: USB\Vid_0dca&Pid_0027
000002: PnP Event: Query Device Text (UP), 08.11.2004 20:40:38.9979168 +0.0100144
Description: Digital Camera
000003: PnP Event: Query Device Text (UP), 08.11.2004 20:40:39.0079312 +0.0100144
Location: Digital Camera
000004: PnP Event: Query ID (UP), 08.11.2004 20:40:39.0079312 +0.0
Instance ID: 1
000005: PnP Event: Query ID (UP), 08.11.2004 20:40:39.0079312 +0.0
Hardware IDs: USB\Vid_0dca&Pid_0027&Rev_0001, USB\Vid_0dca&Pid_0027
000006: PnP Event: Query ID (UP), 08.11.2004 20:40:39.0079312 +0.0
Compatible IDs: USB\Class_ff&SubClass_00&Prot_00, USB\Class_ff&SubClass_00, USB\Class_ff
000007: PnP Event: Query ID (UP), 08.11.2004 20:40:39.9893424 +0.9814112
Device ID: USB\Vid_0dca&Pid_0027
000008: PnP Event: Query Device Text (UP), 08.11.2004 20:40:39.9993568 +0.0100144
Description: Digital Camera
000009: PnP Event: Query Device Text (UP), 08.11.2004 20:40:39.9993568 +0.0
Location: Digital Camera
000010: PnP Event: Query ID (UP), 08.11.2004 20:40:39.9993568 +0.0
Instance ID: 1
000011: PnP Event: Query ID (UP), 08.11.2004 20:40:39.9993568 +0.0
Hardware IDs: USB\Vid_0dca&Pid_0027&Rev_0001, USB\Vid_0dca&Pid_0027
000012: PnP Event: Query ID (UP), 08.11.2004 20:40:39.9993568 +0.0
Compatible IDs: USB\Class_ff&SubClass_00&Prot_00, USB\Class_ff&SubClass_00, USB\Class_ff
000013: PnP Event: Query ID (UP), 08.11.2004 20:41:51.1817120 +71.1823552
Device ID: USB\Vid_0dca&Pid_0027
000014: PnP Event: Query Device Text (UP), 08.11.2004 20:41:51.1917264 +0.0100144
Description: Digital Camera
000015: PnP Event: Query Device Text (UP), 08.11.2004 20:41:51.2017408 +0.0100144
Location: Digital Camera
000016: PnP Event: Query ID (UP), 08.11.2004 20:41:51.2017408 +0.0
Instance ID: 1
000017: PnP Event: Query ID (UP), 08.11.2004 20:41:51.2017408 +0.0
Hardware IDs: USB\Vid_0dca&Pid_0027&Rev_0001, USB\Vid_0dca&Pid_0027
000018: PnP Event: Query ID (UP), 08.11.2004 20:41:51.2017408 +0.0
Compatible IDs: USB\Class_ff&SubClass_00&Prot_00, USB\Class_ff&SubClass_00, USB\Class_ff
000019: PnP Event: Query ID (UP), 08.11.2004 20:41:52.1631232 +0.9613824
Device ID: USB\Vid_0dca&Pid_0027
000020: PnP Event: Query Device Text (UP), 08.11.2004 20:41:52.1731376 +0.0100144
Description: Digital Camera
000021: PnP Event: Query Device Text (UP), 08.11.2004 20:41:52.1831520 +0.0100144
Location: Digital Camera
000022: PnP Event: Query ID (UP), 08.11.2004 20:41:52.1831520 +0.0
Instance ID: 1
000023: PnP Event: Query ID (UP), 08.11.2004 20:41:52.1831520 +0.0
Hardware IDs: USB\Vid_0dca&Pid_0027&Rev_0001, USB\Vid_0dca&Pid_0027
000024: PnP Event: Query ID (UP), 08.11.2004 20:41:52.1831520 +0.0
Compatible IDs: USB\Class_ff&SubClass_00&Prot_00, USB\Class_ff&SubClass_00, USB\Class_ff
000025: Get Descriptor Request (DOWN), 08.11.2004 20:41:52.2031808 +0.0200288
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes
000026: Control Transfer (UP), 08.11.2004 20:41:52.2131952 +0.0100144
Pipe Handle: 0x829298a0

12 01 10 01 00 00 00 40 CA 0D 27 00 01 00 01 02 .......@Ê.'.....
00 02 ..
Setup Packet
000027: Get Descriptor Request (DOWN), 08.11.2004 20:41:52.2131952 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x9 bytes


000028: Control Transfer (UP), 08.11.2004 20:41:52.2131952 +0.0
Pipe Handle: 0x829298a0

09 02 20 00 01 01 03 80 64 .. ....€d
Setup Packet

000029: Get Descriptor Request (DOWN), 08.11.2004 20:41:52.2131952 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x20 bytes


000030: Control Transfer (UP), 08.11.2004 20:41:52.2232096 +0.0100144
Pipe Handle: 0x829298a0

09 02 20 00 01 01 03 80 64 09 04 00 00 02 FF 00 .. ....€d.....ÿ.
00 00 07 05 81 02 40 00 00 07 05 01 02 40 00 00 .....@......@..

Setup Packet
000031: Select Configuration (DOWN), 08.11.2004 20:41:52.2232096 +0.0
Configuration Index: 1

000032: Select Configuration (UP), 08.11.2004 20:41:52.2632672 +0.0400576
Configuration Index: 1
Configuration Handle: 0x828d9cf0
000033: Get Descriptor Request (DOWN), 08.11.2004 20:41:53.6552688 +1.3920016
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000034: Control Transfer (UP), 08.11.2004 20:41:53.6552688 +0.0
Pipe Handle: 0x829298a0

12 01 10 01 00 00 00 40 CA 0D 27 00 01 00 01 02 .......@Ê.'.....
00 02 ..
Setup Packet

000035: Get Descriptor Request (DOWN), 08.11.2004 20:41:53.6552688 +0.0
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000036: Control Transfer (UP), 08.11.2004 20:41:53.6652832 +0.0100144
Pipe Handle: 0x829298a0

12 01 10 01 00 00 00 40 CA 0D 27 00 01 00 01 02 .......@Ê.'.....
00 02 ..
Setup Packet

000037: Get Descriptor Request (DOWN), 08.11.2004 20:41:53.6652832 +0.0
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000038: Control Transfer (UP), 08.11.2004 20:41:53.6652832 +0.0
Pipe Handle: 0x829298a0

12 01 10 01 00 00 00 40 CA 0D 27 00 01 00 01 02 .......@Ê.'.....
00 02 ..
Setup Packet

000039: Get Descriptor Request (DOWN), 08.11.2004 20:41:53.7053408 +0.0400576
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000040: Control Transfer (UP), 08.11.2004 20:41:53.7053408 +0.0
Pipe Handle: 0x829298a0

12 01 10 01 00 00 00 40 CA 0D 27 00 01 00 01 02 .......@Ê.'.....
00 02 ..
Setup Packet

000041: Bulk or Interrupt Transfer (UP), 08.11.2004 20:41:53.7053408 +0.0
Pipe Handle: 0x82961734 (Endpoint Address: 0x1)
Send 0x1f bytes to the device

000042: Bulk or Interrupt Transfer (UP), 08.11.2004 20:41:53.7153552 +0.0100144
Pipe Handle: 0x82961714 (Endpoint Address: 0x81)
Get 0x4 bytes from the device

000043: Bulk or Interrupt Transfer (UP), 08.11.2004 20:41:53.7153552 +0.0
Pipe Handle: 0x82961714 (Endpoint Address: 0x81)
Get 0xd bytes from the device

PV2 BLUE-------------------------------------------------------
000000: PnP Event: Device Connected (UP), 08.11.2004 20:33:00.8291024
The USB device has just been connected to the system.
000001: PnP Event: Query ID (UP), 08.11.2004 20:33:00.8291024 +0.0
Device ID: USB\Vid_0dca&Pid_0028
000002: PnP Event: Query Device Text (UP), 08.11.2004 20:33:00.8291024 +0.0
Description: Digital Camera
000003: PnP Event: Query Device Text (UP), 08.11.2004 20:33:00.8391168 +0.0100144
Location: Digital Camera
000004: PnP Event: Query ID (UP), 08.11.2004 20:33:00.8391168 +0.0
Instance ID: 1
000005: PnP Event: Query ID (UP), 08.11.2004 20:33:00.8391168 +0.0
Hardware IDs: USB\Vid_0dca&Pid_0028&Rev_0001, USB\Vid_0dca&Pid_0028
000006: PnP Event: Query ID (UP), 08.11.2004 20:33:00.8391168 +0.0
Compatible IDs: USB\Class_ff&SubClass_00&Prot_00, USB\Class_ff&SubClass_00, USB\Class_ff
000007: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.8491312 +0.0100144
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes
000008: Control Transfer (UP), 08.11.2004 20:33:00.8491312 +0.0
Pipe Handle: 0x82cdd388

12 01 10 01 00 00 00 40 CA 0D 28 00 01 00 01 02 .......@Ê.(.....
00 02 ..
Setup Packet
000009: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.8491312 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x9 bytes


000010: Control Transfer (UP), 08.11.2004 20:33:00.8591456 +0.0100144
Pipe Handle: 0x82cdd388

09 02 20 00 01 01 03 80 64 .. ....€d
Setup Packet

000011: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.8591456 +0.0
Descriptor Type: Configuration
Descriptor Index: 0x0
Transfer Buffer Size: 0x20 bytes


000012: Control Transfer (UP), 08.11.2004 20:33:00.8591456 +0.0
Pipe Handle: 0x82cdd388

09 02 20 00 01 01 03 80 64 09 04 00 00 02 FF 00 .. ....€d.....ÿ.
00 00 07 05 81 02 40 00 00 07 05 01 02 40 00 00 .....@......@..

Setup Packet
000013: Select Configuration (DOWN), 08.11.2004 20:33:00.8591456 +0.0
Configuration Index: 1

000014: Select Configuration (UP), 08.11.2004 20:33:00.8992032 +0.0400576
Configuration Index: 1
Configuration Handle: 0x82c2be60
000015: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.9192320 +0.0200288
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000016: Control Transfer (UP), 08.11.2004 20:33:00.9292464 +0.0100144
Pipe Handle: 0x82cdd388

12 01 10 01 00 00 00 40 CA 0D 28 00 01 00 01 02 .......@Ê.(.....
00 02 ..
Setup Packet

000017: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.9292464 +0.0
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000018: Control Transfer (UP), 08.11.2004 20:33:00.9292464 +0.0
Pipe Handle: 0x82cdd388

12 01 10 01 00 00 00 40 CA 0D 28 00 01 00 01 02 .......@Ê.(.....
00 02 ..
Setup Packet

000019: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.9292464 +0.0
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000020: Control Transfer (UP), 08.11.2004 20:33:00.9392608 +0.0100144
Pipe Handle: 0x82cdd388

12 01 10 01 00 00 00 40 CA 0D 28 00 01 00 01 02 .......@Ê.(.....
00 02 ..
Setup Packet

000021: Get Descriptor Request (DOWN), 08.11.2004 20:33:00.9693040 +0.0300432
Descriptor Type: Device
Descriptor Index: 0x0
Transfer Buffer Size: 0x12 bytes


000022: Control Transfer (UP), 08.11.2004 20:33:00.9693040 +0.0
Pipe Handle: 0x82cdd388

12 01 10 01 00 00 00 40 CA 0D 28 00 01 00 01 02 .......@Ê.(.....
00 02 ..
Setup Packet

000023: Bulk or Interrupt Transfer (UP), 08.11.2004 20:33:01.0794624 +0.1101584
Pipe Handle: 0x8362bba4 (Endpoint Address: 0x1)
Send 0x1f bytes to the device

000024: Bulk or Interrupt Transfer (UP), 08.11.2004 20:33:01.0894768 +0.0100144
Pipe Handle: 0x8362bb84 (Endpoint Address: 0x81)
Get 0x4 bytes from the device

000025: Bulk or Interrupt Transfer (UP), 08.11.2004 20:33:01.0894768 +0.0
Pipe Handle: 0x8362bb84 (Endpoint Address: 0x81)
Get 0xd bytes from the device

11-08-2004 19:39:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dzoster
Profile
Hello,

i am very interested in this camera..

But i have one great concern that i think might be a red flag.

I got a pv2 red camera at my local CVS store and when i tried to get the serial boot information. I could not get to it!
I tried holding down all 3 buttons on boot ( at the same time.) i also tried pressing on then holding down the buttons still no screen!
This might mean another change in the pv2. Digital camera - Model 410 On battery case
Please tell me that i am doing something wrong! another update would suck! - Dzoster


THANK YOU FOR ALL YOUR WORK! You guys make a difference in the world!

11-08-2004 23:47:13

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
This looks like the wrapper that we're seeing for the bulk transfer (or maybe not!):
http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf

Unfortunately, that document doesn't get into the specific commands we'll need to read.

dzoster - my camera also says model 410. The sticker on the back says "V5-01.04". Are you doing it right? Battery removal isn't necessary - hold down the three buttons while pressing the on/off button.

11-09-2004 12:03:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dzoster
Profile
yes i held the three buttons down at the same time and no screen..

the sticker on the back says V6-3.04

:(

11-09-2004 14:04:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dzoster
Profile
OK!

after frowning i tried something different instead of just holding down on/off delete and display..
i added the 4th button the top shot button this brings up a black "screen " with white lettering

I belive that the delete key is not needed ity works if you just hold down the on/off display and top shot button
when camera is off

INFO

Firmware 6520
Hardware 06
Type ID 30
cmpTypeid 30
ID DD604341073
RealmID 20

hope this helps is this a new type of camera?
are you guys working on old technology?

11-09-2004 14:16:04

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
I've got some Juicy USB command analysis!
11-09-2004 21:43:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) strae
Profile | Email
Hi all,

I just had a fleeting idea that is probably not kosher.

What if we replaced the insides of a camera with a usb recorder - have it act like a camera ready for processing then just record what happens when it's inserted in the processing PC and say ERROR - RETURN TO CUSTOMER - CALL TECH SUPPORT.

We know what the camers says so we could probably trich the PC into uploading the "bootloader"

Just an idea that seems less invasive than trying to steal a pure digital PC image. Hey, it's not OUR fault if they GIVE us the bootloader, is it?

11-11-2004 14:08:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
I have been trying to get a virtual com port to usb drivers to be able to send/rcv to camera...with hyperterm or a script driven setup etc...
have tried FTDI .. shows promise.....

not having much luck... has anyone any ideas ... using Xp

11-11-2004 15:58:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Some more disassembly progress... I think I found the main USB I/O routine (SRAM and SDRAM, but not directly to FLASH, though), and why we're not getting any different data. (Still actually have to figure out how to get the different data, though!)

last version: disassembly = 48k lines, 2.2MB, FIRMWARE.COMMENTS = 2257 lines, 89KB
this version: disassembly = 52k lines, 2.3MB, FIRMWARE.COMMENTS = 2816 lines, 111KB (not up on the website yet)

Mike -- that might be possible; I don't know the FTDI drivers well enough (although that's what I used to download the firmware from the desoldered flash chip), but since the camera uses the bulk pipe for commands, it may work. I don't know if the 31-byte packet can be split into smaller packets that the FTDI driver might. I guess getting the right configuration and interface would be necessary, too (but haven't explored that too much yet)

11-12-2004 01:22:49

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
HMMMMMMMMMMMMMM......
found www.delcom-eng.com ....got lots of stuff.....
modified usbiods.inf added string2 vid/pid 0dca/0027
installed it ....it appeared to hang during install but disconnect camera
then install finished....driver says its ok....

cranked of usbrs232.exe ..... it complained that my chipset didn't support rs232
then a tx/rx window comes up.....I started usmonitor
then keyed HGFJKHGFH [ascii was selected] transmit....
usbmonitor goes crazy logging info.....havn't a clue what it is ...but
was able to dissconnect / reconnect restart usmon and rs232 and repeated same

......this could get interesting.....

11-12-2004 16:00:57

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
I managed to get a couple of images out of the PV2, which should help trying to decode the .RAW file format.

Several attempts to create an all black image failed miserably, however I have available two all white shots
(and some others).

Have a look at http://www.digitalfluff.net/pv2 . The white shots look really usable as it has a nice clean
repeating pattern and very high compression.

11-14-2004 15:35:10

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) razdrez
Profile
Hey all--

I don't have a camera, but I had an idea--has anyone tried using other button combinations on startup? Especially the unused buttons? Perhaps we'd get a new info screen?

11-15-2004 00:10:39

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
debass - Did you download those files over the PV2's USB? If so, AWESOME JOB! and What commands did you use? I'm working on decyphering them and I'm sure many others are too. Thanks.

morcheeba - If and when its possible, please post an updated FIRMWARE.COMMENTS file. Your progress on that is very impressive and the files are quite informative. TIA.

11-15-2004 16:16:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Nice, daBass! After analyzing your pictures for about 5 minutes, I've got really good news!!

First off, it's obvious that they are doing compression - the files are different sizes, and the white files are the smallest. I guessed this from my 2 pictures, but this solidifies it.
Second, running the white files through pkzip made them go from 64K to 5-8K. Looking at the data, both files are really repetitive. This means that no encryption is being used - otherwise, these files wouldn't be compressible!

From the copyright notes found in the drivers, does anyone want to try out zlib uncompression on these files? The headers are different, so just using gzip won't work.

11-16-2004 12:18:59

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j_tetazoo
Profile
FWIW...

I did a quick frequency analysis of 8-bit values in each of daBass's all-white image files. The most popular values are F7, FB, FD, FE, FF, and their mirrors, 7F, BF, DF, and EF.

Also, the sequence "FEFF7FBFD" (or some aritrary ROT there of) is repeated ALOT.

HEX img_0003 img_0014
00 114 261
01 9 50
02 13 48
03 11 34
04 21 64
05 9 27
06 8 41
07 5 21
08 11 81
09 21 42
0A 15 21
0B 6 9
0C 13 67
0D 5 26
0E 15 14
0F 7 13
10 12 75
11 17 33
12 8 28
13 23 28
14 10 32
15 14 24
16 12 10
17 27 19
18 11 81
19 37 68
1A 8 16
1B 9 18
1C 12 23
1D 7 9
1E 3 14
1F 12 25
20 10 41
21 13 47
22 11 39
23 8 32
24 10 39
25 10 15
26 22 26
27 29 22
28 7 32
29 12 21
2A 19 24
2B 14 16
2C 11 15
2D 11 5
2E 12 13
2F 49 42
30 12 54
31 33 57
32 28 34
33 20 32
34 9 20
35 7 29
36 8 18
37 12 19
38 8 30
39 21 22
3A 20 12
3B 12 5
3C 24 18
3D 3 26
3E 4 8
3F 39 56
40 5 48
41 12 39
42 19 49
43 11 31
44 6 26
45 38 42
46 12 38
47 10 17
48 29 37
49 11 30
4A 5 22
4B 14 17
4C 30 29
4D 7 18
4E 12 20
4F 24 13
50 12 19
51 16 37
52 17 38
53 8 21
54 16 19
55 12 17
56 9 10
57 14 12
58 15 14
59 20 22
5A 21 15
5B 12 4
5C 8 15
5D 13 7
5E 8 16
5F 86 43
60 12 49
61 7 33
62 33 27
63 19 28
64 13 21
65 50 18
66 20 28
67 19 25
68 4 32
69 9 22
6A 8 17
6B 18 23
6C 23 12
6D 9 6
6E 4 5
6F 13 15
70 2 19
71 11 29
72 7 18
73 16 17
74 7 17
75 13 13
76 21 15
77 20 5
78 3 19
79 66 22
7A 12 16
7B 8 8
7C 9 17
7D 4 7
7E 2 11
7F 6504 6525
80 5 60
81 14 32
82 3 29
83 18 20
84 17 41
85 16 21
86 8 51
87 20 20
88 17 50
89 18 23
8A 24 38
8B 28 29
8C 49 55
8D 12 20
8E 7 22
8F 14 17
90 24 42
91 10 28
92 12 35
93 13 23
94 9 7
95 11 8
96 16 13
97 51 33
98 47 37
99 18 31
9A 8 17
9B 17 13
9C 23 36
9D 12 20
9E 15 19
9F 38 46
A0 5 29
A1 11 30
A2 19 25
A3 12 30
A4 18 37
A5 12 21
A6 12 19
A7 9 18
A8 42 30
A9 12 26
AA 14 21
AB 11 15
AC 17 20
AD 21 13
AE 5 12
AF 38 21
B0 13 21
B1 15 14
B2 20 17
B3 29 21
B4 14 16
B5 20 13
B6 15 7
B7 5 11
B8 7 12
B9 9 10
BA 12 15
BB 15 17
BC 19 30
BD 17 13
BE 16 20
BF 6491 6459
C0 20 33
C1 3 27
C2 6 24
C3 14 32
C4 17 29
C5 10 18
C6 32 39
C7 8 14
C8 21 33
C9 9 20
CA 16 14
CB 78 37
CC 49 42
CD 15 19
CE 17 12
CF 26 39
D0 10 25
D1 15 26
D2 8 22
D3 11 17
D4 25 21
D5 12 18
D6 27 17
D7 22 19
D8 9 26
D9 16 18
DA 13 15
DB 12 23
DC 11 16
DD 11 15
DE 19 24
DF 6432 6428
E0 9 21
E1 1 22
E2 15 16
E3 10 26
E4 15 18
E5 24 13
E6 28 17
E7 16 41
E8 15 22
E9 18 26
EA 18 22
EB 42 23
EC 23 30
ED 20 20
EE 16 21
EF 6445 6424
F0 7 16
F1 16 20
F2 28 21
F3 54 30
F4 38 23
F5 30 30
F6 34 32
F7 6422 6428
F8 14 18
F9 43 23
FA 72 27
FB 6372 6456
FC 41 31
FD 6406 6475
FE 6450 6513
FF 6448 6503

11-16-2004 12:22:50

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) j_tetazoo
Profile
Another curiosity I noticed...

The sequences 0xFEFF7F and 0xBFD are binary "palindromes", meaning they read the same thing backward as they do forward:

0xFEFF7F = 1111 1110 1111 1111 0111 1111
0xBFD = 1011 1111 1101

11-16-2004 14:02:44

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bentfork
Profile
It looks like they have been making some code revisions:

my camera from CVS with 3 finger salute gives:

firmware 6510
hardware 06
typeid 27
cmptypeid 27
DA50443200707
realm id 20


P.S. Any hints on how you got the raw images out? I have been waiting for the USB gods to do their work, look like it is in my realm (software) now.

11-16-2004 21:57:43

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
j_tetazoo, ya beat me to it! I had a quick look at daBass' all-white images today at work while waiting on a MATLAB license to open up (so I could get some actual work done...), and noticed the strongly repeating 9-byte pattern in each. The hexeditor Tiny Hexer can generate some basic file statistics; I used this to create some pretty (ugly) histograms at http://cexx.org/dakota/pv2stuff/stats/ of the white images (the *allwhite.rtf files) and morcheeba's original two .RAW files (the img*-anal.rtf files...they don't show this clear pattern, but the 7F/FD/FE/FF/etc. bytes still reign supreme). (Beware, the generated files are well over a megabyte each; I didn't have time to try and massage them into a less evil format.)

Of particular interest, have a look at the graph for "allwhite_closeup.rtf"; this was just the first few hundred bytes of the actual image data (discarded the sparse header) from one of the all-white images, represented as signed 8-bit integers. Interesting little "exponential decay to 0" pattern they've got there, which I completely didn't notice staring at raw numbers in a hexeditor :)

Also, similarly to j_tetazoo's observation, the 9 bytes that appear a disproportionately large number of times (of the form 0xF# or 0x#F, see table below) each have a 'buddy' with the high and low nibble reversed (palindromes?) - that is, there's an FE and EF, F7 and 7F, BF and FB, and so on (with the exception of FF, which is its own nibble-swapped 'buddy').


Value Occurrence Percentage
0xFE (254) 46 10.624%
0xFF (255) 46 10.624%
0x7F (127) 45 10.393%
0xBF (191) 45 10.393%
0xFD (253) 45 10.393%
0xDF (223) 44 10.162%
0xEF (239) 44 10.162%
0xF7 (247) 44 10.162%
0xFB (251) 44 10.162%
0x12 (18) 1 0.231%
...

11-16-2004 22:27:29

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
daBass - I (and I'm sure many others) are dying to know - how did you get these images out of the cam? USB or flash-sucking?

And regardless, how did you generate the image previews at http://www.digitalfluff.net/pv2/ (I assume these aren't all photographs of the LCD screen?)

11-16-2004 22:37:00

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Godzilla
Profile
Hey,

I have been reading this for a while with a good deal of interest because I bought one of these digital cameras because I read about them on slashdot. I went in to the local Longs (where I got the camera from in the first place) and talked to the photo specialist, who told me some things and gave me a look at the machine (these may or may not be useful) that they use to get the data off of the camera. Basically, what it is, is a specialized computer (loaned out by Pure Digital???) that has a camera shaped slot on the front. The software that they use is pretty user-friendly, basically a big button that says go. I didn't get a chance to see it in action. The software appears to be all-in-one; it reads the camera and burns the images directly to a CD.

The specialist also told me that their system will not get images off of other types of disposable digital camera (for instance, Dakota). I am guessing this has something to do with the firmware version (mine is 6520, but still hardware type 06). Also, my camera has a Longs splash screen at the beginning when you turn it on.

I dont know if that helps, but if there is anything else I can do to help, please let me know.

11-16-2004 23:14:17

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
Ok, I finally put up my latest version of my firmware comments - I decided to make it beta instead of alpha.
last version: disassembly = 48k lines, 2.2MB, FIRMWARE.COMMENTS = 2257 lines, 89KB
this version: disassembly = 54k lines, 2.4MB, FIRMWARE.COMMENTS = 3102 lines, 122KB

I found some code that used $55 and $AA's - this is often used as a special code to program & erase Flash memory. Code like this was in the old dakota camera, but that used a totally different flash memory. Unfortunately, the flash memory used in the PV2 doesn't use this code for programming... so, it's a bit of a mystery. Is it used for some sort of memory check, or maybe for some sort of external memory that doesn't have a connector.

Anyway, I'm pretty excited about daBass's file dump. If someone can figure out the uncompression, I think we've got a good chance at making this a more useful camera.

Godzilla - I'm guessing that it is the "Realm" field that is shown when you press all three buttons on power up. PureDigital's real customers are the stores that they sell their systems too -- the restriction that limits cameras to specific store chains is there to please them. One of the things store owners would find attractive about this camera (as with other photofinishing services) is that it brings people back in to the store, where they'll often buy other things.

11-17-2004 01:00:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
How to get pictures out of the PV2 the 'weird way'.

What I did to make the shots available on my site is the following:

Turn on the camera.
Take a picture.
Wait until the camera is ready again.
Hot plug it into USB (without turning it off that is).

Send out USB command 4c 61 4d 53 1d ba ab 1d 00 00 10 00 80 00 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 on endpoint 0x01.

Read back response on endpoint 0x81 (see post above somewhere for the particulars, or morcheeba's site for the juicy USB description).

What you are doing here is sending out a wrong command that (because of a bug in the USB code (?) ) still gives back a Megabyte of data that comes from SDRAM (I suspect from address 0x140000).

The megabyte of data contains at 0x2000 the preview (280x192 bytes) and at 0x12000 the picture (length is in the header
at 0x12003).

That's all.

11-17-2004 03:29:36

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bartoni
Profile
Looking at the image part dBass's white files in binary, what seems to be palindromes in hex is really just 60 repetitions of the 9 bit pattern 011111111. These 540 bit groups are separated by a variable number of about 40 to 50 miscellaneous bytes. There are about 860 such groups in the file, so we may have raster data after all.

Three cheers for morcheeba and dBass!

11-17-2004 07:41:28

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
How about some separate shots of all red, all green and all blue. An easy method would be to create on pc monitor and snap a closeup. Also a red square inside a green background might be revealing.
11-18-2004 01:46:40

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) billw
Profile
Debass - kudos on extracting the pictures!

About generating an all-black image, did you try covering the lens with black cloth or something similar? Just a thought.

11-18-2004 13:34:08

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
If anyone has a pinout for the CMOS sensor, it might be possible to generate a true 'all black' image by physically forcing lines on the sensor high/low (otherwise just a bunch of sensor background noise gets read, which I would guess the camera scales up to some arbitrary minimum brightness). How about attempting to photograph an alternating pattern of white and (very complex pattern) lines? This might help to decipher which bytes in the image correspond to each line (or, block of lines, anyway) provided the source image can be taken very straight-on with respect to the imager.

Also- for the Windows folk, I'm throwing together a USB poking tool that can be used to send/receive arbitrary data from a bulk device (screenshot at http://cexx.org/dakota/usbpoker.gif ). For now, data (unless text) will be sent by specifying a file with the raw binary data, or dropping such a file on the main window. Data received (unless text) will be logged back to a binary file. Any recommendations / feature requests?

11-19-2004 07:41:20

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) morcheeba
Profile
dakotamod - that's a good idea, but I think it won't be too useful in practice. (of course, I could be wrong!) To get a pure r=1, g=0, b=0 signal, you'd have to perfectly match the color of the filter in the camera. Also, there is a contrast issue - you can't just put the camera in front of a 100W bulb like you could do for an all-white image; you've got to have enough red light, but not so bright that some bleeds through and lights up the green and blue sensors even just a bit. A red laser pointer would probably work best, but might still be too bright. I'm just trying to say it would be hard to get a pure r=1, g=0, b=0 signal... and that would be most helpful for decoding the compression scheme used.

Once we get the compression scheme figured out, I'm sure we'll just get a bayer pattern. There aren't too many possibilities for this (3 colors arranged in 4 squares - assuming two greens, there are 4 useful permutations). That can be guessed at by trial and error.

An all-black signal will probably have to be done digitally. or at -200 degrees C. (hey, we've got liquid nitrogen at our office) There aren't that many pins on the imager - identifying the clock with a scope should be easy, and then all the image data pins should be pretty easy. A little solder blob, and ta-da.

But, I think the white image is enough to get us most of the way there! I was the compression wizard in high school, but I'm rusty now. It looks like 9-bit huffman encoding (good job bartoni!) - I think that would be simpler to implement in hardware than arithmetic coding. I loaded it into zlib, but it's looking for some headers -- a header at the beginning of the file, and a 5-byte header at the beginning of each block. This may have neither. I suspect that the noise seen between the groups (40-50 bytes) are the unused pixels at the end of each line, or they could hold the gamma parameters for that particular line. (40-50 bytes seems like a lot! but, then again, random noise at the edges won't compress nearly as well as 11111's in the middle)

11-19-2004 11:49:53

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) mike
Profile | Email
drmn4ea

I sure could use a usb poke tool for win xp.....I've been trying to learn usb and
visual basic to do the same... but have a long way to go.....
how about supplying the source code also.........
using pipes looks interesting ....

msw101144@charter.net

11-19-2004 21:50:35

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
Ideally a red pixel filter on a camera would match the red phosphor on computer screens - so a laser may not be necesarry. If I had a windows usb poke, I would try it myself.
11-20-2004 10:48:52

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) daBass
Profile
Seeing as my camera is out of comission (I tried filling up the camera with pictures to see if it would react differently to
USB commands when the camera was ready to be processed, it doesn't BTW), I can make no further shots with the PV2.
So any shots of green/red/black need to be done by someone else.

Having said that, I do have a Philips camera to play around with. The images it makes have a sligthly different format from
the PV2 (different header, and a TFT/image preview is appended to the header), but as far as I can see it uses the same compression scheme as the PV2 (it is also easier to get raw files out of this camera).
I tried making shots of pure green / red with the Philips camera, but could not achieve it without other colors bleeding in.

I also had a closer look at the TFT/preview format, they have a distinct 'Bayer' feel to it, and there is 6 bits for RGB.
This may be a clue that can be used in decoding the RAW format, as the preview might be generated directly by decimating
the sensor image. (Also note the remarkable properties between possible sensor size and display size: 1288/280 = 4.6 and 864/192 = 4.5 ).

11-20-2004 14:51:11

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
From maushammer.com: "My microscope was strong enough to barely make out the bayer filters, but I didn't have a calibrated scale to determine the resolution." Was a bayer pattern clearly identified? Is barely 100% certain?
11-20-2004 21:28:45

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
Burning the midnight oil, inspired by daBass' comments, hope this is more helpful than misleading.

Algorithm for creating TFT image.

81 pixels grouped into 9x9 squares. Each 9x9 square is reduce to a 2x2 as follows:

Each Bayer column contains 2 colors (green&red or green&blue) so create a value for each color by averaging sometimes 4 pixels and other times 5 pixels. After doing all columns then perform same averaging operation on rows.

Example

R G R G R G R G R
G B G B G B G B G
R G R G R G R G R
G B G B G B G B G
R G R G R G R G R
G B G B G B G B G
R G R G R G R G R
G B G B G B G B G
R G R G R G R G R

first averaging by column pass becomes:
R G R G R G R G R
G B G B G B G B G

second averging pass by row becomes:
R G
G B

The 9 bit patterns may be related to 9x9 squares.

SMaL claims a 500 times extended dynamic range - which could translate into a 9bit exponent (9 bits = 512).

Perhaps dynamic range exponents are extracted just for the 9x9 squares.

A key question is do the 60 repeating 011111111 for each row (860 groups 860 rows) represent color or intensity. I suggest they represent intensity which is set exactly at mid point (255 - 9 bit value) for center of white exposures.

11-20-2004 23:50:48

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
An interesting test would be to take an all white shot with an extremely bright light circle in the center. I suspect a nine bit exponent would make it very difficult to obtain an all black shot - unless you encased the imager in a thick layer of lead.
11-21-2004 00:31:01

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
Sorry for propagating misleading information - according to page 21 of http://www.cexx.org/dakota/A015AN02V1.pdf LCD is not a Bayer Format. Thus my 9x9 square would not map as described to the LCD, but the ratio of 81/4 still fits imager to LCD reduction. I still think 9 bit repetitions are more likely exponents than color; however are they exponents of one colored pixel or a matrix of pixels. Note that the SMaL site points to a press release at http://www.letsgodigital.org/en/news/articles/story_1738.html "In addition, the digital images are stored in the camera before processing in an encrypted, uncompressed file format that can only be processed by the Pure Digital Server." I think they are wrong.

Can anyone positively identify the PV2 Bayer imager mask with a microscope?

11-21-2004 12:32:58

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) PidGin128
Profile
like others ive been reading this page with eager anticipation, but the loading is starting to get longer and longer , what with 300+ posts and all [ this being #304 ]. would it be possible [ read, would it really bother/inconvience anyone too much ] for somebody to created a 'Hacking the RED Dakota PV2 (with LCD) - continued' thread or similar to speed up page loads and probably reduce server load ?

also if somebody could automate even just the thumbnail extraction routine / program into a simple to use app / script, it would be much appreciated, because even that would allow simple use. if not the ability to use it again ... [ till we figure out more ]

well keep up with the good work all.

11-21-2004 18:52:05

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Drmn4ea
Profile
Very early, unfinished, untested USB poking tool for Windows up (source included): http://cexx.org/dakota/usbpoker.zip . Bugreports to dakota "at" cexx dot org.
11-21-2004 19:34:19

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) dakotamod
Profile
Please use the new thread "Hacking Pure Digital Continued (from one use to many)" for future posts. The length of this one may discourage new talent.
11-21-2004 21:16:29

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) Burzurk
Profile
The RED Dakota PV2 (w/LCD) can be purchased at Wolf Camera's web site www.wolfcamera.com for $18.99 + $6.95 for shipping.

It took about 6 six days to arrive.

I'm going through all the POSTS now.
If anyone knows of any sites with regards to the PV2 and Windows XP specifically, I could use it.

Othwise I'll keep my fingers quiet.

12-15-2004 02:20:50

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) antidartan
Profile | Email
Hey guys
I have enjoyed following this subject.
I just bought a cvs red camera with a LCD. when I push delete,display,shutter, and then on
I get

firmware: 6520
hardware: 06
typeid: 2b
comptypeid: 2b
ID: DB6044609676
Realm: 20

Is this the camera that has been hacked or is it the one that is being worked on, or none of the above?

Most of what you guys say goes way over my head. What should I study to learn the most basic stuff? (have to start somewere)

12-17-2004 11:52:12

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) brite_eye
Profile
antidartan, follow "Links - 1 2 many 4 all" and try to make a cable - if you get that far download other links and see how far you can go, otherwise just wait for "Dummies - 1 2 many 4 all" to explain an easy proces - it won't be long.
12-17-2004 12:21:38

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) agentc0re
Profile
I currently bought the pv2 (red one with LCD) and have been looking up how to beable to download all the pictures from the camera. now i found some utilities to download the whole flash but im not quite sure if im using them right. I was able to use some drivers and accually get it to be found on my computer. basicly what im asking is there anyways i can download the pictures to my computer yet, or are we still all trying to figure that out. if there are ways please let me know which windows programs i need to use and the info so i can get them please. thanks guys!
12-26-2004 20:22:42

New MessageRE:Hacking the RED Dakota PV2 (with LCD) (modified 0 times) bullring1
Profile
i was able to unlock the red dakota digital camera pv2 using the pv2mod file and the updated libusb-32 files but was unable to read the camera from windows-xp. so out of curiosity i sed the Picasa2 photo editor from Google and was able to download the pictures with no problem. i have a second camera so i will try and repeat the process and post guide. let me know if it works for you too...
07-08-2005 15:24:07

Reply to Thread | Printer |
All times are PSTPowered by UltraBoard v1.62



Copyright © 2000, Netmake Inc. All Rights Reserved.
See Terms and Conditions for more information.




i-opener opener laptop notebook computer help drivers dll free windows dos repair fix linux mac macintosh 2000 95 98 nt pc configure hardware software sound video netscape explorer network networking lan wan software cmos fat bios printer card mouse modem ide scsi cd rom controllers scanner tape hard drive cgi scripts source code mp3