I-Appliance BBS
The Official Source for Internet Appliance Upgrades and Mods
Amazon Honor System Click Here to Pay Learn More
BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.netReply to Thread | Printer |

Home / MISC Areas / Cameras
Hacking Pure Digital Continued (from one use to many)
Hacking Pure Digital Continued (from one use to many)

New MessageHacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
This is meant to be a continuation of "Hacking the RED Dakota PV2 (with LCD)"
The best summary is probably the above thread with many contributors (morcheeba, bartoni, daBass, Drmn4ea ... are my personal favorites).

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

Windows USB poking tool from Drmn4ea:
http://cexx.org/dakota/usbpoker.zip

Repost from DaBass:
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).

11-21-2004 21:13:06

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
New Timestamp to move above old thread.
11-21-2004 21:17:39

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Oops, missed a very important recent link from DaBass:

http://www.digitalfluff.net/pv2

11-21-2004 21:45:54

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
Following daBass' procedure, a dump from a 'pristine' PV2, firmware 6410. (No pictures taken on it, not hotplugged) - http://cexx.org/dakota/pv2stuff/sdram.zip . Very repetitive, but I haven't had time to look at it yet (past my bedtime!).
11-22-2004 01:37:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
dakotamod - you beat me to posting daBass's page! There's also Cexx.org, but, thanks to the slashdot article, that comes up as the #1 page for a google search for "PV2". Blue Donkey has a usb tool -- drmn4ea, that might be of interest - I haven't tried it. Anyone else, self-promote! (sorry if I missed you) Here's my main lcd page and a succulent usb command listing. The part that gets updated most often is my disassembly software & the FIRMWARE.COMMENTS file that I'm writing as I disassemble the code -- look for "DISV8 download" on this page.

When I said I could just barely make out the bayer pattern, that really just means no. I could see the pixels as a distinctive texture, but not clear enough to see the colors. Lighting a piece of silicon can be difficult. I'll try to get it under the super duper microscope & see what it looks like.

The circle pattern sounds like a good idea for decoding. I'm thinking about it... maybe I can produce the image. Also, if anyone wants, I can post my Mac OS X program for reading from the camera - it should be doing just want daBass has been doing, only under a different OS. I doubt it will port to linux easily (the mac makes user-mode USB programming pretty nice!).

I don't think the 9-bit pattern is directly related to a pixel -- It's got to be compression because the file sizes change so much. The 9 bit size is probably a maximum size from the decoder -- zlib allows something like 8 to 16 bits per symbol (variable). I tried just sticking the data into zlib, but no love. zlib is looking for some headers that I'd guess are set by the PureDigital driver software. Still looks doable, IMHO. A perfect job for anyone playing with compression.

I did some more disassembly this weekend. I found some FAT code (deleting a file, creating a directory, and maybe searching a directory)... hopefully I can see from this code how to access the flash -- and then, see how to call the flash-access routines from the USB port.

11-22-2004 01:59:18

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Finally found Autobrite Patent, brains behind it (Keith Fife) and his Thesis:

Patent
http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=6600471.WKU.&OS=PN/6600471&RS=PN/6600471

Thesis
http://theses.mit.edu/Dienst/UI/2.0/ShowPage/0018.mit.theses%2f1999-310?npages=143&format=inline&page=39

11-22-2004 16:35:25

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
I would like to post extracts from the thesis but that is illegal; however intermixing of nibbles from rows as depicted on page 41 would certainly if in use be very difficult to discover or even guess. I wonder if patents based on a thesis are valid. The patent as I currently understand it does not seem to cover this mixing algorithm and thus it can probably be used royalty free; if not there is no harm in posting a patent - only implementation and use are restricted. The patent mainly covers physical electronic implementation of an extended dynamic range.
11-22-2004 20:56:59

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) tapostrophemo
Profile
Two thoughts:

-----

Assuming 1) we're able to download the raw images, and 2) that downloading them wouldn't negatively affect the chances of getting the camera processed at the drugstore, couldn't someone:

1. take a camera full of photos
2. download the images
3. take the camera to the drugstore for processing, and BE SURE TO PAY FOR THE IMAGES ON CD (I don't recall if that came with the prints anyway or not)
4. compare the raw image to the processed ones to figure out the raw encoding/encryption?

(And wouldn't it really be funny if it turned out that the raw images were just *.jpg's run through a simple XOR or ROT13? )

-----

In his/her penultimate post in the previous thread, dakotamod wrote:

>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."

Does that mean that the drugstores machine makes a network connection to PD when the images are processed?

11-22-2004 23:14:46

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Vanilla_icer
Profile
I work for longs drugs and I can verify that the Pure Digital machine
does use a network connection.
11-23-2004 16:35:22

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
I put the sensor under the good microscope today & I've got some measurements!

With this machine, I could clearly see the Bayer pattern. It is (viewed from top):

R G R G R
G B G B G
R G R G R

The optics in the camera probably project the image upside down to this pattern. And I don't know where the pattern starts (there are probably some dummy rows on the ends), so the only information we can get from that is that it's one red (actually kindof yellowish-red), one blue (pretty dark) and two greens. That's in line with just about every other sensor (except the foveon and hex-shaped sensors)

Next was the measurement. The pixels looked square, so I only measured only one dimension (I should have measured both). The pitch appears to be 3.9 micrometers per pixel (and by pixel, I mean an individual sensor in the bayer matrix). I had far less precise equipment to measure the active area of the sensor (I basically used a calibrated SOIC and eyeballed it). The area was about 0.2" x 0.1583", so (drumroll please)

that would yield an imager size of 1302 x 1031 pixels. It looks like it's the Ultrapocket 3 chipset -- the dimensions are close: (1280x960, 4 micrometer square pixels, 0.202x 0.163")

----
dakotamod - nice work digging that up! It'll take a few days for me to read it, but that's what we've got thanksgiving for.
tapostrophemo - that's a good idea. I suspect that they do a lot of processing that will make the difference between the two images pretty large, so it might not be too helpful early on. If I remember correctly, they would resize the pictures of the old camera so you'd get more pixels -- they'll probably resize this to 2MP or more. Still worth a try, but it's probably much more useful once we get a rough output so that we can generate a calibrated output. The gphoto SMaL decoder didn't have this step done yet, so the pictures came out looking dark.

11-23-2004 20:58:36

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
tapostrophemo - (thinking out loud) we could capture the data coming from the imager chip & compare it to the data file.. there should be very little processing between these two (AFAIK).
dakotamod - holy bit manipulation in that thesis paper!
11-23-2004 21:36:35

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) bentfork
Profile
I have written a little program to play with the first 'all white' images supplied by daBass over at http://www.digitalfluff.net/pv2/. It currently loads a image_xxxx.raw file, populates a header and loads the raw image data into a buffer for further processing, and dumps it out into another file. If anyone is interested I will post the code somewhere. It compiles on windows now, but I can make it crossplatform if there is any interest.

I have been playing around with XORing the buffer using xorbuff[buffstart]={0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01, 0x00} starting a different buffstart offsets for each 'chunk' cleans up the image nicely and leaves lots of 0xFF bytes in groups of aprox 67, followed by a few bytes (4-6) of data.

Interestingly there are 864 groups of non 0xFF data left over when it is finished. I assume these are the vertical pixels from the imager.

here are the first few chunks from image_0003.raw:


00 55 21 followed by 95 0xFF
ED 7C 66 61 12 54 followed by 67 0xFF
FA 78 CB E4 59 B3 followed by 67 0xFF
9E 84 47 32 AE D7 followed by 67 0xFF
5D 86 45 49 3E 35 followed by 67 0xFF
D3 16 5F 22 CD 9F followed by 66 0xFF
FC 86 33 33 0F C6 followed by 67 0xFF
...

As this is just the all white file the size of each section is small, and seem to be fixed size. I am going to look at the other white image and see if I can find any similarities. I havent figured out what value 'seeds' buffstart yet for each section, so I am just bruteforcing it until I find a start value that yields 0xFF. I dont know if the data I am finding should also be XOR'd, and if so should I use the previous sections XOR buffstart, or the next sections XOR buffstart. Any ideas?

Has anyone had any luck generating a all Red, all Green, all Black, or maybe a test pattern (There are some advanced ones here http://www.bealecorner.com/trv900/respat/ and here http://brighamrad.harvard.edu/research/topics/vispercep/tutorial.html ). The trick will be getting a high contrast picture so the patterns jump out at us.

11-25-2004 12:13:01

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Drmn4ea,
Did you use your USBPoker to obtain a dump from a 'pristine' PV2. I have had no luck getting libusb to recognize my 6410 PV2, but the Foxz2 driver recommended by daBass does recognize the PV2 and turn the ready light on.

Running testlibusb-win does not enumerate as daBass suggested but just lists the following 2 lines:
Runing test DLL version: 0.1.8.1
Driver version: not running!

Any suggestions are welcome, I will shoot some red, green, white with a single black line ..., If I can get past the above windows problems (someday I need to install linux).

11-27-2004 01:29:17

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
OK, after rereading all the posts and links, I replaced all the Dakota lines in libusb.inf with just one line:

"Pure Digital PV2, Bulk Interface, Version 11/18/2004, 20041118"=LIBUSB_DEV, USB\VID_0DCA&PID_0027

and removed "Che-ez! Foxz2" driver. Testusb-win worked and Drmn4ea's poker picked up my pics while I should have been asleep dreaming. I have sent another "pristine" and a white split by black line and a white with a blue rectangle as can be seen indirectly on simple ms paint screens (all sent to dakota "at" cexx dot org for posting). The white split by black line was a screen shot that somehow (raster timing) ended up with 2 large horizontal gray strips. The blue rectangle on white paper is quite lousy due to flash and close proximity. Perhaps the most value will be comparing my "pristine" with the previous one. My PV2 is 6410, 06, 27, DAA042126767. If someone can offer another site for raw images other than cexx, please reply below.

11-27-2004 06:39:14

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Can anyone explain/guess as to why the TFT image of an all white computer screen with a line down the middle was divided into 4 equal horizontal sections of white, gray, white, gray? While at first I thought this might be an odd rasterization effect, my current guess is that it has something to do with autobrite sectioning combined with a raster effect. I plan to try one with my camera rotated 90%. Does anyone know if a single dump of multiple pictures is possible - unplugging, deleting, hotplugging, USB poking, unplugging, deleting is a bit unpleasant - also I would like to leave my basement and try for some higher quality outdoor images such as electrical lines against a blue sky (or gray here in Michigan) and some simple monotone structures. It would speed the process up if I could shoot 25 duplicates (1 on my old blue and 1 on the new red) and then select the best to post.
11-27-2004 10:57:26

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Just realized I can post to my yahoo briefcase for all to see!

http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then PV2 to download a zip file containing:

pristine.raw
white_blackline.raw and .GIF (simulated gray bands were added after picture was taken to reflect a surprising result on TFT)
white_bluesquare.raw and .GIF (simulated TFT, due to flash this does not look much like TFT only like actual paper with blue rectangle)

I am too burned out to investigate difference between my pristine and Drmn4ea's, but that may help determine if there is serial number based encryption.

11-27-2004 15:17:57

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) daBass
Profile
dakotamod,

Have a look at the pictures you made: http://www.digitalfluff.net/pv2/weird.html .

Do you wait a long time between taking the shot and getting the data out ? It looks like the data either gets overwritten with pseudo random
data, or you have a defective CMOS imager.

11-27-2004 18:44:46

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
nice work getting that data out, dakotamod! Question: is your computer screen a CRT monitor, or an LCD screen? If it's LCD, then the artifact may be because it's a dual-scan screen. Otherwise, I'd say it's an autobrite artifact. I'd have to study autobrite better. At least I gleaned that the exposure is a piecewise-linear approximation of an extreme gamma instead of a perfect extreme gamma.

I'm still taking apart the firmware... I think I found mkdir/chdir.

11-27-2004 19:45:42

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Those actually look worse than the LCD did; both triggered the flash in a poorly lit basement. There was only a short hotplug delay before downloading each. The white with black line was a CRT (Flat Envision from Costco), the white with blue rectangle was white paper with blue paper taped to my basement wall. daBass, Please provide the method you use to extract the TFT images and also the method for the all white shoot. I wonder what RITZ would say if I take it back after having been opened, with sticker removed and ask for another because it is defective? Perhaps a cable problem? Look at the quality of my Blue using the same cable: http://www.photo.net/photodb/folder?folder_id=443422. Once someone gets a CVS communicating I will try one of those. Each download using Drmn4ea's poker indicated 1048589 bytes after requesting 2,000,000 - same as both pristine images using windows USB poker. I used a trial version of winzip, but doubt it has anything to do with artifacts unless there is some incompatibilty during unzip process.
11-27-2004 20:16:59

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) daBass
Profile
Dakotamod,

In the data you get returned from the camera at offset 0x2000h is the start of a block of RGB data that is the TFT preview (280x193 lines). I cut
out 64K at 0x2000h which I feed to a modified version of morcheeba's tft2tga. The result I read in to Paint Shop Pro (which can read raw pixel files).

The all white shot was created by holding the camera about 2 inches above a white piece of paper, and letting the flash do it's work.

I suspect data corruption in some way is taking place as the white_bluesquare.raw has in the header @ 0x12000h a length of 6c da 07 02 (34069100 bytes ?).

11-28-2004 06:19:50

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) zippyut
Profile
Anyone consider using a laser pointer to excite the CCD? Lasers (even just plain old LEDs) are great at producing a very distinct wavelength. Depending on how good the filters are, you could get your pure RGBs.
11-28-2004 15:16:12

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
TFT under a microscope:
G B R G B R
_B R G B R G
G B R G B R
_B R G B R G

daBass, did you fix the MSB/LSB issue with tft2tga (tga expects bytes ordered as B,G,R), and note also that the starting byte should be G (upper left corner). I think this explains purple vs blue on morceeba's images. The artifacts do not appear to be totally random, but would probably be greatly reduced by averaging pixels (which may not have been done when extracting the TFT from a bayer image. There are various averaging methods but usually they include surrounding pixels, above, below, to the right and to the left. I may have screwed up images by repoking with different sizes specified on Drmn4ea's poker. I think artifacts could be removed by discarding the high order 6th bit from pixels in my images. As to using a laser, it would probably be difficult to obtain a good full imager exposure along with an appropriate electronic rolling shutter speed without specialized diffusion techniques. I am waiting for Blue Sky - hope to post an outdoor shot soon.

11-28-2004 16:04:31

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Two new raw files and 1 extracted lcd at
http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then checkers to download a zip file containing:
checkers.jpg - My basement floor, bayer like with blue replaced by white and green by black.
checkers.raw
sky.raw - this looks corrupted, but I have no idea why or how - blue sky, clouds split by electrical wires - if the lcd is at 2000 it exceeds the 6 bit pixel limit on previous previews.
11-29-2004 04:14:25

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) daBass
Profile
dakotamod:

The tiles dump is OK, the sky dump is not. Please note that the trick to get data out only works if the camera has not shut it self off between
taking the shot and hot plugging it into USB.

You read data out of SDRAM, if the camera shuts it self off, you lost the preview and the raw file because SDRAM gets inited with random data.

BTW: which timezone are you in ?

11-29-2004 04:32:45

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
> Did you use your USBPoker to obtain a dump from a 'pristine' PV2
Yep, it's completely virgin as far as I can tell (at least, no pictures have ever been taken since I bought it), and sucked in via the USB poker. The brief-detailed procedure was: [Camera off, no batteries -> plugged into USB -> "turned on" by claiming bulk interface -> RAM contents sucked out]. But as daBass mentions, this may consist of mostly random garbage data.

dakotamod - Regarding the strange banding you saw - I noticed a pretty much identical effect while playing with the old Blue cam with removed lens - placing the imager right up against my CRT, or within a couple inches, and taking a picture produced fat, horizontal bands (I don't remember exactly the colors, but I remember seeing one or both of (dark gray and white) or (light blue and white)). I thought at first I was seeing something related to the monitor refresh, until I realized the bands were completely horizontal, regardless of the angle the camera was actually held at! So, I'm sort of at a loss. Maybe the levels of EMI put out by a CRT scramble the imager's brains in a specific way when held too close?

11-30-2004 00:54:50

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
More Raw Pictures:

http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then BLACK to download a zip file containing:
black - a slightly smaller black (black tape over flash and lens, timer set, inside shielded lead film bag).
blackdot - my pinhole lens (black plastic circle with shiny brass shim in center on white paper).
reddoor - a red door with bright white flash circle on top.
11-30-2004 03:02:29

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Sorry for may haste (I did not take time to extact raw data from USB dump - as daBass did). Perhaps Drmn4ea can add such a feature to his poker. When holding the camera just 2 inches from a piece of white paper I could also produce the small SMaL files. Thinking in my sleep over a short night about how little luck I have had proding a smaller file using any other method, I am speculating that it may be related to exponents on each color and a dynamic range (500 times a normal camera) with bright light saturating every pixel presenting no need no for any exponent (or just an occaisional few bits). For any automated processing of my images be sure to start at 12000 and only process the length in header. For manual processing, I have been opening in binary mode using Textpad. Can anyone find the bright flash circle on red door or black circle on white paper simply by visually scanning the rasterized raw image? Good luck to all, I seem to be driven by a thought of cameras flying off drug store shelves into Santa bags - the count down has started and pressure is on. I am in GMT-5 (Michigan US). I need to go see Polar Express - new animation techniques have gotten good reviews.
11-30-2004 07:52:03

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
For windoz users... found TheSycon....USBIO driver wizard etc with sample apps
I installed USBIO_DEMO.exe created a driver...then installed VB5 on WXP2.....then tried the sample apps
..The visualbasicdemo seems to be well written [i'm just learning VB] ... I did have a prob with vb5 and had to
get patch vb5cli.exe then app appears to work very well......it will require some changes .. like add another pipe and I'm not sure of how to get bulkin/out to work...trying to learn usb also[not a lot of luck].....
For those who can ..take a look at the visualbasicdemo
on my sys Its at C:\Thesycon\USBIO_DEMO\V2.20\COMobj\samples\visualbasicdemo\USBIO.vbp
the driver generated by the demo stops working after 4 hours ,,, but just reboot and you are back in business....
11-30-2004 12:41:03

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
ALSO...... you must regsrv32 usbiocom.dll as well as set vb5 preferance usbiocom2.0
11-30-2004 12:44:36

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
I was hoping it would be a trivial task to break red door raw file into ~ 860 lines using several pixel wide solid white door jam on left as guide for where each raster line starts. Simple pattern matching may be all that is needed to identify the flash circle in top of photo. I am reposting a direct link in hopes that everyone at least looks at high contrast preview for my red door.

Preview
http://us.f2.yahoofs.com/bc/41a8ec19_4b60/bc/Pure+Digital/REDDOOR.jpg?BC_.NrBBz45XL_RK

raw
http://f2.pg.briefcase.yahoo.com/bc/zqcpwr/lst?.dir=/Pure+Digital&.view=l

11-30-2004 14:46:49

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Ignore links in previous post, sorry they do not work. For quick preview try:

http://us.f2.yahoofs.com/bc/41a8ec19_4b60/bc/Pure+Digital/REDDOOR.jpg?BCRMQrBBSazmL_RK

If that does not work then:
http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then REDDOOR.jpg to view the preview.

11-30-2004 17:04:51

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Please somebody help transfer files and create links that work better than yahoo briefcase (not everyone can get to ones I posted). If anyone thinks they have located a specific piece of image, please post the location. The most important one is red door jpg and raw.
11-30-2004 17:18:58

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
USBpoker 101 how is it suspose to work??????
I can open dev send 31 bytes to ep1 but the max I get from ep81 is 525 of inconsistant
data.....
..what is the proper proceedure to use.....
11-30-2004 18:28:58

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mako
Profile
briefcase works fine for me, but otherwise:

preview: http://img86.exs.cx/img86/8066/REDDOOR.jpg

raw: http://img54.exs.cx/img54/2096/reddoorrawzip.jpg

^^ is not a jpeg, it is a renamed zip archive. save it and change the extension to .zip, whereupon you can extract the .raw file.

11-30-2004 20:01:59

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
mako, thanks a million (I would like to think that many are watching - how many will pass through when the door is finally cracked open?), good to see an oldtime contributor still watching (your last post was 7/16). Please also post my most recent black taken inside a leaded bag (are these still allowed in airports?). While it is blacker than daBass's it is not much smaller. Viewing it's preview with a photo editor shows tightly grouped rgb values with little variation. Again thanks for reposting red door with white jam on left - after looking directly at the white jam it isn't really solid white since paint is peeling but it certainly it is free from high intensity red. I am not really big on Christmas but can't get the chorus of Here comes Santa Claus! Here comes Santa Claus! out of my head. Perhaps in years past I did or did not (which I am not sure) always remember what Carroll's doormouse said (Lewis Carroll is the pseudonym of the English writer, Mathematician and Photographer - Charles Lutwidge Dodgson). Does that explain intensity of light shining on my basement door - do not answer here but feel free to respond to my email available if you follow my previous links to photo.net .
11-30-2004 21:51:45

New Messageif the stream is compressed and then XOR masked, our test images wouldn't give us any clue. (gloomy) (modified 0 times) newbee
Profile
The raw image size varies. It doesn't compress more. So it is compressed and most likely encrypted. The easiest way of doing it is, having a fixed LFSR pseudo random number generator, initialize it with a seed (possibly based on the file size) and XOR the original compressed stream with it.

In that way, the resultant stream would not have any obvious characteristics of anything but a pseudo-white noise of varying size. If that is the case, if we can get identical two all-white images, the files should be identical. However, even if we get two identical files, it wouldn't help us in decoding. Morcheeba's approach seems to be the only way to get closer to the solution.

Eventually, we might need to write a new program that does not do any encryption. (This could turn out to be rather easier if there are not many XOR instructions used in the software)

11-30-2004 22:23:06

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) pseudonym
Profile
Some interesting hardware hacks on the camera itself :

Shorting Q15 - Close shutter
Shorting Q13 - Open shutter

R27 - resistor controls LED brightness
VR2 - variable potentiometer controls LCD brightness

Shorting C1 - Voltage drop across camera, causes camera to enter indeterminate state. Intermittent contact during startup causes camera to run code incorrectly.
Removing power for 15 seconds then re-applying causes camera to reset (turn on/turn off)

11-30-2004 22:46:18

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
Drat, lost my post! (Browser crash) Here is the abridged (read: too-lazy-to-retype) version.

newbee - good news, looking at the image files harvested so far, particularly daBass' all-white ones, it looks like there is definitely compression going on, but not encryption (see the histograms at http://cexx.org/dakota/pv2stuff/stats/ , esp. hist_0003.png and hist_0014.png - a well-encrypted file should appear as random data, without such clear patterns as mentioned earlier in the thread).

mike - are you using USBPoker.exe or the Thesycon driver? (Guessing Thesycon, if I'm hearing talk about endpoints ) As for usbpoker.exe, I'll try to clean it up a bit and have some proper documentation soon.

Everyone - I'd like to suck out a 'guaranteed' black image by some careful trace-cutting.
1) Anyone identified an obvious clock / enable line to the imager?
2) It sounds like maybe the flash memory can be made "read-only" by tying the WP line high. This would save a lot of needless picture deleting or corruption during indiscriminate hacking around, but at the same time, I wonder how the camera firmware will react to its writes being ignored. (Likely reaction: craaassh!) Anyone tried it already?

Answers to 1 or 2 could both save me a lot of work

12-01-2004 00:36:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Whoa, relax the reins - let's backup.

From an early post by morcheeba:
"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!"
newbee's "It doesn't compress more." just aint so when it comes to white paper shots taken 2 inches away. Why does moving the camera to 4 inches away produce much larger raw files?

Another post by morcheeba:
"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." Was he referring to off camera USB drivers or on camera firmware? Note if zlib is used it does not appear to be using rfc1951 and thus probably is not used.
http://www.faqs.org/rfcs/rfc1951.html


As to pattern matching with lcd image - if there is no encryption and compression is applied sequentially then one might still determine start for some rows and even recognize some distinct differences in the first rows of red door image where the high intensity flash circle appears. The previous posts seem have found 860 rows for all white images.

12-01-2004 01:56:24

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Sorry, for jumping to conclusions again, but I was not reading data from right to left as specified in rfc1951 - so I can't rule out zlib (this will take considerable brain twisting). Oddly of all the raw files the red door is the only one which starts (or is that ends) after the header with the same sequence as in both white files! I doubt it is because of white door jam, but can't rule that out.
12-01-2004 07:14:04

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
drmn4ea
I have used usbpoker and Thesycon [ready made app .. not the visual basic sample source] and the
most bytes I have received has been 525
loc 0000-007f all 0's
0080-01ff ???? maybe v8 pgm code ????
0200 - L a M S 00 00 00 64 02 ...... I've seen this somewhere......

The THESYCON USBIO_DEMO visual basic sample looks like it could be a usb hacker's dream if you have visual basic on you
system.....and you know more than I do about usb and visual basic.......

12-01-2004 09:52:34

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mako
Profile
@dakotamod: Yeah, I've been lurking. The recent developments have been quite exciting. I think it may be time to get one of these things, and maybe read up on compression =).

I've been using http://www.imageshack.us/ to host the images. The file size limit is 1MB, which is why the compression and renaming is required.

black preview: http://img61.exs.cx/img61/7325/BLACK.jpg

black raw: http://img40.exs.cx/img40/6871/blackrawzip.jpg
^^ again, this is a renamed zip archive.

12-01-2004 14:55:42

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
Is any body using usbpoker with win xp2 ---- I think xp2 is contributing to my prob
...my win 98 machine will xfer 1meg + ... of course I have no idea what's being xfered.....
and both usbpoker and Thesycon[usbioapp] both transfer 1meg+

I will have to try my laptop next.....it has xp1 + some xp2

12-01-2004 18:11:53

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
Is any body using usbpoker with win xp2 ---- I think xp2 is contributing to my prob
...my win 98 machine will xfer 1meg + ... of course I have no idea what's being xfered.....
and both usbpoker and Thesycon[usbioapp] both transfer 1meg+

I will have to try my laptop next.....it has xp1 + some xp2

12-01-2004 18:26:40

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
dakotamod

You mentioned taking picture 2 inches ?????? I would think the the focus would be so bad
that the data would be screwed up.......?????

12-01-2004 18:29:50

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
Dakotamod - The zlib was seen in the PC drivers for other products. I think I found mine in the mac version of a che-ez driver; I thinki daBass or someone else also saw this in some windows drivers. It's not in the firmware (at least the text message). The zlib could be used for outputting png files, but I haven't seen any drivers that would actually do that.

Q: Why does moving the camera to 4 inches away produce much larger raw files? A: I suspect what you're seeing is the difference between a pure-white image that compresses extremely well versus a mostly white image with a little bit of noise that compress so-so well. I suspect that if you had more light on the 4-inch-away picture, you'd get a pure-white image and it would compress again.

Glad to see activity on this board!

12-01-2004 22:29:57

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
@mike

Strange you're only getting 525 bytes out. This happens only on the WinXP box, with the exact same bulk input? Same versions of libusb/thesycon? PS. I don't know any VB, mostly just enough c/c++ to shoot my toes off (and enough PIC assembly to be downright dangerous)

@fellow solder jockeys

Yaya, I meant WP\ held LOW on the flash mem to inhibit writes... well, they just HAD to run the entire trace completely under the chip, directly to a power plane INSIDE the board, didn't they... ah well, will share some results when/if I have them.

For those who don't like getting zapped: I have found the PV2 will refuse to come up if the photoflash capacitor is removed (safety, bah), but can be fooled by a small-value high-voltage cap with a bleeder resistor in parallel, so the cam can be safely handled shortly after power is removed. (I'm using 4.7 uF and 200 KOhms)

12-01-2004 23:24:14

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) tapostrophemo
Profile
I'm done with step #1 (from my post on 11-22-2004 23:14:46). I've filled up the camera with pictures (with kids as cute as mine you just can't help it), and here's some interesting behavioral tidbits:

1) After you take the last picture, it displays the "Camera Full" message. However, as long as you keep the power on, you can keep deleting that last picture and taking another one.

2) *But* as soon as you turn the power off and have taken the last picture, the camera operates differently. The next time you turn it on, it immediately displays the "Camera Full" and "Please return for prints" message. The shutter never opens. You cannot display nor can you delete the last image. Then if you let it sit a few seconds (about 30 by my count) it turns itself off automatically.

Point 1 might be interesting because it could be pulling up a different *.tft file than it normally does (as mentioned in a post from the previous thread by morcheeba, dated 09-27-2004 22:37:24).

I should also point out that my camera has the "6520" firmware and is from CVS.

So, now I just have to be patient and hope that a way to download all the images is discovered...before I take it back to the store for processing.

12-01-2004 23:32:18

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
@mike:
"525 bytes" solved, maybe. Morcheeba got a similar result, with the command packet shown there (it's slightly different than the one at the start of this thread).

@dakotamod:
I can't explain the other artifacts, but am able to reproduce the banding you got taking a picture of the computer screen. Here is my CRT, taken with an old Blue at about 45 degree angle (note the bands are still perfectly horizontal!) and about 0.75" from the imager (limitation of having the camera and lens assembly still fully assembled).

12-01-2004 23:58:59

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
The difference in those 2 commands is simply a length code of 512 and 1048576 based on hex 00 00 20 00 and 00 10 00 00.
I have tried 00 20 00 00 after taking 2 pictures and received 2M back but looks like just one picture then non random data. At 1E7A70 26 39 27 39 28 37 25 37 26 3A - looks like RGB data too me. Just think maybe the 1M compressed picture is followed by an uncompressed version! Here those sleigh bells ringing! I should wait till I have verified this (as I have several posts where I jumped the gun) but had to post this for all right away. The pattern really appears to match my shot of an eye chart on a old white basement wall. Check out my "Can your camera see better than you" thread at http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=00A4R4 . Scroll to last post on that thread!

I am just to sleepy to change to 2.6Meg (1 + 1.6), take another shot, pull down full RGB, ...
Too much time playing with gzip headers and reading rfc1950,1,2. What a relief if the above proves true. Hope to awake to some great shots from someone else who is hearing those bells ding aling dinging. Who is making thousands of cables to sell on ebay? I am not - had several problems making the first(there was a wire touching 2 pins at serial end of palm cable which really created a nightmare for the special 2 piece cable I made).

Mike, the 2 inch out of focus is necessary to achieve enough diffusion for a highly compressed white picture.

Thanks so much Drmn4ea, I'll be dreaming 4 yee all tonight! Who is MOD erating this dakota thread?

12-02-2004 01:55:55

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) scribble
Profile
morcheeba-- In one of your earlier posts you said you saw a color filter array pattern showing one each blue red and green spots. Is this correct? The two common color filter array patterns are the classic bayer with one each red and blue spots and two green spots and the complimenty version with cyan, magenta, yellow and green spots.

dakotamod-- If the 26 39 27 39 28 37 25 37 26 3A data is from the black letter part of your eye chart and the color filter array is a classic bayer as I suspect, you are seeing unproccessed raw data. The two 39's are from pixels with green filters and the 26 and 27 are from pixels with either red of blue filters. It would not be uncompressed rgb data since for a 1280 by 864 sensor that would require over 3.3 megs of memory. The 3A would be from a much brighter pixel and if the data you quoted is from a black letter it could be part of an intermediate calculation in the compression scheme.

This is what I think is going on. The camera stores compressed raw data just like the extension says. Why raw data? That would make it marginally harder for folks like us to hack the camera. And far more important--nobody has to write the firmware needed to comvert the raw data into a true picture. So I'm almost certain that the demosaicing, gamma conversion and everything else needed to convert the raw data into the rgb data for the fugi frontier is done in the Pure Digtal computer.

Any why compress the raw data down to .6 megs. That's so you can store 25 images if the 16 meg flash memory on the camera.

Once we have a cleaned up raw image what do we do? There is a dos program called raw2nefw that turns unprocessed raw data into NEF images. It supports a number of cameras-Nikon, Olympus, and Minoltas--where the control chip can output raw data but for one reason or another the camera manufacture didn't impliment the feature in their firmware. The program and source code is at http://e2500.narod.ru/raw2nef_e.htm. Once the program is modified to handle pure digital we could then use one of the freeware raw converters like draw or irfran to produce the pictures.

One more thought. For photographic reasons I doubt pure digital is using smal's high dynamic range scheme. High dynamic range make for fine survailance pictures but for ordinary photography the images look unnaturally flat. Moreover if you don't use all 8 bit in a pixel for tonal information the colors after demosaicing are blotchy.

scribble

12-02-2004 05:20:46

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Not scribble to me - I think you are right on scribble, but you must of missed morcheeba's recent post a few back:

I put the sensor under the good microscope today & I've got some measurements!
With this machine, I could clearly see the Bayer pattern. It is (viewed from top):

R G R G R
G B G B G
R G R G R

I just awoke and had to check, but still to tired to go further - hope others can carry on. I had already made plans to go see Polar Express tonight with my wife and another couple.

12-02-2004 05:47:51

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) scribble
Profile
Enjoy the Polar Express. My wife dragged me off to see it last week and I walked into the theater muttering, "Big thrill!! Two hours wasted watching some stupid Xmas movie!!" Much to my surprise I walked out of the theater thinking, "What a great movie."

scribble

12-02-2004 06:14:03

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Analize This! Eyechart.jpg for preview and eyechart.zip containing raw with uncompressed bayer?
http://f2.pg.briefcase.yahoo.com/bc/zqcpwr/lst?.dir=/Pure+Digital&.view=l

If that does not work then:
http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and eyechart.zip to download raw.

I recommend xvi32 for viewing raw (it has a nice address goto):
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

Sorry the preview of low light shots looks rather ugly, but perhaps the full photo will look much better. Tried to sleep - could not - like a kid waiting for Santa, going to try again.

12-02-2004 08:59:46

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Red stop sign and yellow fire hydrant:

http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and stop.zip to download raw and jpg preview.

12-02-2004 14:53:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) j_tetazoo
Profile
I just realized that when it comes to looking at raw graphics files, xv is my friend. If you're not familiar with it, xv is a graphical file viewer (for X-Windows) that can read just about any graphics file format known to man.

A very primative file format it PPM (Portable PixMap). I found a nice treatment on the format here -> http://astronomy.swin.edu.au/~pbourke/dataformats/ppm/

For kicks, I downloaded dakotamod's eyechart.raw file and did the following (from the *ix command line) to turn it into a binary PPM file:

echo "P6" > eyechart.ppm
echo "1000 933" >> eyechart.ppm
echo "244" >> eyechart.ppm
cat eyechart.raw >> eyechart.ppm

I then opened the resulting file in xv and saved it out as a GIF and posted it here (for those of you who can't read PPMs) :

http://jtetazoo.tripod.com/eyechart.html

Starting about halfway down, I can just make out a distorted-looking eye chart!

12-02-2004 15:07:28

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) j_tetazoo
Profile
Oh, and here's the stop sign & fire hydrant pic...

http://jtetazoo.tripod.com/stop.html

12-02-2004 15:14:45

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) paganpat999
Profile
You guys are geniuses! You're all so smart! I'll never beat up another nerd! morcheeba/Drmn4ea/daBass/dakotamod and all you others working on this, I want to let you know that there's hundreds of us eagerly awaiting your hack are whatever you call it:0) for the camera, I barely know how to turn a computer on. And I wanted to let you guys know that due to the efforts like morcheeba/Drmn4ea/daBass/dakotamod and the other nerd's my kids have had countless hours of enjoyment with the old dakota blues and I'm looking forward to using my pv2 if it wasn't for people like you we probably wouldn't have electricity! Keep up the good work you guys :)
12-02-2004 15:53:00

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) j_tetazoo
Profile
Oops. Typo in my post above.

echo "244" >> eyechart.ppm

should have read

echo "255" >> eyechart.ppm

12-02-2004 18:15:03

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
@thx guys the length was the problem......now I can get back to learning vb and usb......
I have a lot to learn....
USBpoker and the usbioapp [thysycon] both appear to extract ok....
havn't done much with the visual basic demo sample yet....
12-02-2004 18:18:02

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
schweet, j_tetazoo! I think you've found an uncompressed version of the picture!

I had assumed that the compression was done in hardware, and thus never seen in memory -- but now that we see it, the compression may be done in software. I'll keep my eye out for such a thing as I look through the firmware, but a compression routine isn't going to stand out too much. That data should also give us a good idea of the exact number of pixels, too.

12-02-2004 18:33:10

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
Hmm... j_tetazoo's stop sign RAW... I figured I wouldn't have anything to contribute here but,

Is this any closer?

http://www.mindspring.com/~insomniaskunk/decode1.jpg

12-02-2004 23:35:02

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
I'm sure you guys already have this stuff. but... Closer still. Let me know if I'm already covering old ground...

http://www.mindspring.com/~insomniaskunk/decode2.jpg

12-02-2004 23:56:21

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
schweet schweet schweet! Halve the width, and I think we're a getting there. That's enough to figure out the bayer pattern & autobrite gamma. Then, we need to figure out the compression (helpful that we've got the uncompressed versions) and how to get pictures over USB. I'm still concentrating my efforts on that last part.
12-03-2004 00:22:25

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
I'm working on Bayer as we speak.
12-03-2004 00:26:38

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 1 times) icedragon
Profile
bada boom, bada bing.

http://www.mindspring.com/~insomniaskunk/decode3.jpg


how about them apples.


RGRG
GBGB.

12-03-2004 01:47:17

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
eyechart, too.

http://www.mindspring.com/~insomniaskunk/eyechart.jpg

Image size is 1288x864, including black current reference on the right side.
Bayer is as suspected, RGRG / GBGB.

Image seems to include: first, a bunch of non-Bayer data (almost twice the image), always 1179648 bytes long. (perhaps the autobrite.), next, the image, 1288x864x8, and then some other stuff to EOF.

If you start at byte 1179649, decode 8 bits, go for 1288x864, debayer with that pattern, apply a standard brightness curve, whammo. picture.

It'd probably look better if it wasn't bilinear demosaic. but hey.

12-03-2004 02:14:02

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
Here's what I can find for the graphical structure of the files. These offsets may not be the same all the time, because the file size changes; however as found before, the image does seem to begin at the same point every time. Except where noted 'varies', it seems to be the same for every raw image.

Bytes:

[0-272: Header]
[273-1600: Graphical text of some sort, 16 px high]
[1601-8191: Unknown pattern 1]
[8192-66232: Preview/Thumbnail image in 280x193 TFT]
[62233-73885: Unknown pattern 2]
[73886-VARIES: 'Noise'. (in stop.raw it ends at 667740]
[VARIES-1179648: 'checkerboard pattern', (in stop.raw, it starts at 667741]
[1179649-2292480: image in 1288x864 Bayer RGRG/GBGB]
[2292841-3555917: 'checkerboard pattern' continued]
[2555918-EOF: black]

Here is the 'checkerboard pattern'
http://www.mindspring.com/~insomniaskunk/pattern.jpg

here is what appears to be some sort of text, all squashed up
http://www.mindspring.com/~insomniaskunk/text.jpg

12-03-2004 03:41:25

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Well Done All!
Time for some publicity. Sorry, for the pressure morcheeba, but please post details describing how others may help. Now is a good time to maximize numbers of off self cameras. I suggest that any posts concerning specifics of non PV2 cameras go to a separate thread (there is already one for CVS). Too all visitors, please sign up at photo.net (it is free until you want to post more than 5 pictures), and give the stop sign photo in events a 7/7 rating. If it makes photo of the week there should be a large quantity coming off drug store shelves.

http://www.photo.net/photodb/photo?topic_id=1481&msg_id=00AJMe&photo_id=2929362&photo_sel_index=0

12-03-2004 05:05:51

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) icedragon
Profile
Heh, I hope my site holds out then, if anyone wants to host those extracted pics anywhere else, that might take a bit of the pressure off.

I'm gonna try and write a quick raw->bmp converter in the next day or so; hopefully with Morcheeba's efforts the whole thing could come together into a consolidated app -- but this isn't over yet... I've been lurking here, watching everything go on, it seems like there's still a bit to get USB to respond logically.

Almost there...

12-03-2004 06:28:53

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) j_tetazoo
Profile
I don't know if I'd go out and buy one of these just yet...

Seems to me there is still quite a bit of work left to do. IIRC, the raw data we've been working with the last couple of days is the result of a memory dump. This means you only have access to the last picture taken, and that you have to snap your picture, then run to your computer and download it before the camera turns itself off.

I'd say this is more a step along the path to figuring out the compression scheme. Now that the compressed and raw version are available at the same time, work can proceed on reverse-engineering the compression scheme.

Once that gets worked out, and morcheeba and company work out how to offload the data stored in flash, then we'll really have something.

12-03-2004 08:27:49

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
There is no harm in using them as stocking stuffers - in worst case they can still be returned for processing if efforts on this thread fail; but I am betting morcheeba will succeed (others are helping). I doubt the industry can react before holidays are over and so this is conveniently a very good time. Again I would request more publicity by obtaining a photo.net guest membership and giving the stop sign photo a 7/7. After all this effort, why wait till the cameras are recalled (as many feel happened with the original blues). I have given credit to the team on this forum in the comments attached to stop sign photo.

http://www.photo.net/photodb/photo?topic_id=1481&msg_id=00AJMe&photo_id=2929362&photo_sel_index=0

12-03-2004 08:55:17

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) j_tetazoo
Profile
icedragon... In your memory map, the data from 73886-1179648 is where the compressed image data lives (look back to dakotamod's "root" post to this forum). I suspect the "checkerboard pattern" you're seeing is just un-initialized memory, the result of allocating a fixed-sized chunk of memory to store a compressed image of a variable size. The data from 73278 to 73885 is a header to the compressed file, which has also been documented (look back in this thread for links to daBass's web site). Help in reverse-engineering the compression technique would be greatly appreciated (I've tinkered with it to no avail so far).

Now that we have a way of getting ahold of both the raw image AND the compressed version, perhaps it's time for a systematic "attack", in which the raw data is compressed using a variety of known compression methods and compared against the compressed image data to see if we can get a match.

12-03-2004 08:57:34

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
I agree with j_tetazoo, and would recommend that someone follow above processes and post an all white image (taken 2 inches from paper) and poked with a high address. As daBass discovered, and I confirmed this produces a much higher rate of compression than any other photos. I used drmn4ea's poker with hex 27 instead of 10 in command length code (it failed with 30 for some odd reason).
12-03-2004 09:11:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) halincandenza
Profile
Does the processing machine at the photo store talk to HQ via Internet when the camera is hooked up for image extraction? If so, I wonder if the camera has a unique identifier that identifies the type of compression/encryption scheme to be used, with several to choose from, or maybe even a unique encryption key ("OK, camera #42840214, here's the key- now give the nice machine your data."). If so, there might be some real challenges emulating such an interchange.

I'm no expert in these things, so please ignore this post if it's irrelevant.

12-03-2004 11:16:48

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
Hi everyone! Despite my "schweets", I don't think it's quite time for publicity yet. Yep, it's provably hacked (we can always substitute the firmware to save the raw image we see in SDRAM), but it's not too practical yet. I'd like to wait for the practical part first; otherwise we'll disappoint people. Worst case is that people need to desolder their flash memory and reprogram it outside the camera -- I doubt this, but we still need the FLASH I/O. The old blue camera could download pictures before we went public; it just wasn't too practical (a couple of hours downloading the FLASH memory byte-by-byte). I'm open to suggestions, though, as to how we should proceed.

I found a bunch of commands that take filenames. Last night I tried to download "FIRMWARE.BIN" and "IMG_0001.RAW", but both got error $64. I only tried one of the commands -- there are a couple others and I suspect one is chdir and another is a "filesystem reset". Hopefully I can get people downloading their FIRMWARE.BIN's.

I think the next thing people need to look at is the compression -- we've got the compressed and uncompressed versions of pictures, so that should be a good start. I was guessing arithmetic coding because that's supposedly simple to do in hardware. I'll have to post my experiments with this & see if it's helpful.

I'm at the office right now, so I'll post later tonight. Wow, I'm amazed by how quickly this has picked up in the last few weeks -- good work everyone!!

12-03-2004 11:24:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 1 times) icedragon
Profile
Actually I was figuring that this morning - that the alternating black/white probably is just unused memory, now that I realized how the .raw file was taken.

Well, I'm on board for this now... hopefully I can help with some of this compression voodoo, it's the kind of thing I've done in the past... Now that I've got even those few files to play with (I do have a PV2, but no cable to tinker with..) - we'll see what we can get going.

This was definitely a milestone, but it isn't done yet, I agree. But it's great to see things actually taking shape now.

I've already got some code that takes the raw file to .jpg, but that's not too useful; If the encoding is lossy at all, it has to be 'de-bayerized' before the compression occurs, anyways. Next I'm going to take out the compressed data alone, and start monkeying with that. If it's some kind of DCT-based algorithm that doesn't follow any existing spec, and at the same time, encrypted, we could be in for a ride. If it's just simple arithmetic, maybe not.

12-03-2004 12:22:21

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
Five $ discount on pv2 red ... just got one total 13.99
hurry fella's christmas is almost here......

http://www.cvs.com/CVSApp/cvs/gateway/promotion?pid=5735

12-03-2004 19:22:19

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) nambabwe
Profile
morcheeba: if you can point me in some direction on how to read the data from a removed chip, i'll desolder my flashchip this weekend. my camera is still empty. my first try would be to hook it up to a PIC chip and read the data out through a rs232 connection, unless you have a better solution?
12-03-2004 23:39:01

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
I have tried to use usbpoker with no success. I have installed the usblib driver, Windows XP recognizes the camera fine. I opened USBPoker, it had
USB id 0DCA/0027, configuration 00, interface 00, alternate setting 00
in the first dropdown. There is also configuration 01. I tried that, and it was the same result. I chose Bulk Out (was that my mistake?) and sent a binary file that contained 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 (but not in ascii). I clicked Send it, and USBPoker printed "Wrote 31 bytes to bulk endpoint." After that, nothing happened. Am I doing something wrong? I have tried the same process on two Windows XP computers with libusb installed and everything. Any help would be great, thanks.
12-04-2004 01:42:14

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
nambabwe-

I've posted the program here & I've got some links to the hardware I used posted on my main lcd page (see "Flash memory analysis section"). The microchip PIC serial port sounds like a great idea. I used a pre-made microcontroller & USB interface, but the USB interface was supported with a serial driver, so it was basically the same. The chip I used supported lots of commands; you can hard-code in things like port directions, so your PIC code can be simpler. My USB FIFO chip was slow to read things back (because USB is polled, you have to wait for the next polling cycle), so I have a speed optimization you won't need. I take advantage of the FIFO and request many reads before actually looking for the data. You can disable this by setting BYTES_PER_BULK_READ to 1 in the .h file. Good luck!

12-04-2004 01:53:06

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) mike
Profile | Email
boodle

Heres what I do...1] open device 2] select bulk out 3] select filename if 31 char bin/cmd file
4] sendit (wait for 31 xfer) 5] select bulkin 6] set desired length 1000000
7] set a receive filename 8] sendit wait for xfer to finish
if I get a -1 error I close and replug device

12-04-2004 05:17:58

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
boodle, mike and others,
I use mike's process but with hex length code "00 00 27 00" instead of "00 00 10 00" in binary file and then 2600000 in the decimal bulkin length (zeros start somewhere after 2.5 million). This will pull down uncompressed raw file that is after the initial 1M compressed version. Please post a few more uncompressed successes for those working on compression algorithm. An all black and all white might help; and we should confirm process works on more than just my camera. I have been unable to communicate with a blue CVS - If anyone is successful please post a note on the separate CVS thread. Thanks for the CVS add mike - I had just bought a blue and red for 8.99 and 17.99 with an additional $3 off exracare coupon (common if you buy $20 or more on a CVS card) for a total of $24. After that I now have $4 off $20 - so How many more do I buy when I go back for $5 discount? Personally I do not feel I can check anything but framing on the Reds which isn't needed except for closeups which are blurred (until someone succeeds in lens modification - I had great fun posting high quality macros on photo.net with original blue:
http://www.photo.net/photodb/folder?folder_id=443422 ).

morcheeba, Drmn4ea, deBass and others
It appears that changing usb direction bit is working - changing bit, bulkout, bulkout with angerRcvd.txt gives a write message. I cannot seem to get more than one combined operation (bulkout bulkin or bulkout bulkout) without replugging usb connection. If morcheeba can produce a short stub to just call compression on raw image, I could change single bits and recompress an image to aid in identifying compression algorithm. However I do think if morcheeba gets to a point where we can upload code over usb connection and know where compression routine is - the compression issue may have already been solved. I did notice if rfc1951 deflate is being used some images start with a final block and others require multiple blocks. Oddly both of daBass's whites do not have this high order bit set (perhaps indictating multiple blocks) and only one other raw had it set. Where is daBass - we need another booster.

12-04-2004 09:34:40

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 2 times) boodle
Profile
Awesome, thanks dakotamod-I didn't realize we had to ask for data back. That makes sense though. Anyway, I made an almost black picture-it's pretty close to being all black I think, but it's not. http://www.boodle.info/dakotablack.zip Somehow I disabled my flash. I accidentally shorted some of the wires on my cable to each other. I can't get it to do it again, but while it was like that I couldn't get any communication (obviously). I don't know which pins were shorted, I think it was one of them shorted with the ground. I'll work on figuring that out, because then I could probably get closer to all black without a flash.
12-04-2004 12:35:28

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
Oh, and I forgot-somehow I deleted one picture past what I should have been able to delete. I'm not sure how it happened, I think it was when I was messing around with shorting the wires. Before I had 18 pictures left after taking a picture, now I have 19 pictures left after taking one. I think most likely it was a mistake and I may have some corrupt data on the flash now. I'm not really sure.
12-04-2004 12:40:46

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
How about some help for morcheeba?
I think he may be able to legally post his disassembled results, not just his disassembler. Normal software license agreements have specific non-use and non-disclosure clauses. We have not signed any software license agreements. Portions of the software are probably already protected by SmaL’s patent but that would only stop use (we own legal cameras). Who owns the software – Pure Digital, SmaL, ARClite? Is there a copyright notice in your dump morcheeba? If not they goofed and we have a loophole. Are they using any open source code? It sure would be nice to find the original programmer. How about just posting portions for educational purposes – in most cases this is allowed. Does anyone have contacts with any of the linux or open source geniuses who could recommend an attorney for free advice. I would certainly be willing to donate twice the cost of all my cameras to morcheeba if they take him to court.
12-04-2004 13:02:09

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Great job boodle, we have now have another uncompressed poker! I can pursue other things.
What camera do you have - please provide results from a 3 finger salute. Oddly your compressed image at $12000 as a header with C8 instead of the usual 9C (I use XVI32 it is fast, easy and has a nice goto feature). The image did not compress as much as mine posted earlier taken inside a leaded film bag but your's has the uncompressed version also. If your flash is still working please post an all white taken 2 inches from a piece of paper (these compress much better - 60k instead of 600k). Your dump is not corrupted, I can see black.
12-04-2004 13:23:25

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) daBass
Profile
dakotamod:

I'm still around, just a little busy with other stuff at the moment.

I have a theory about the pattern data as shown at http://www.mindspring.com/~insomniaskunk/pattern.jpg .
What I understand of the Autobrite / compression patent is that databits get reshuffled to create longer strings of 1's and 0's.

Are these bands maybe the reshuffled bits ? I see 4 bands (RGGB) of about 6 - 8 blocks (How many bits is the individual Bayer color ?).

So Bayer image -> reshuffled bits -> RAW file. The inverse then would be RAW file -> reshuffled bits -> Bayer image.

It would be really easy to test this on an all white image, but I never saved more than 1 Megabyte per read and my camera is
out of comission. Anyone up for a challenge ? I'll have a look at the almost black one that got posted right away.

12-04-2004 13:34:13

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
http://www.boodle.info/dakotawhite.zip wow, that does compress a lot more. I bought my pv2 from www.wolfcamera.com a while back. 3 finger solute:

FIRMWARE: 6430
HARDWARE: 06
TYPEID: 27
ID: DA304240xxxx

12-04-2004 14:03:35

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 1 times) boodle
Profile
Could the reason my compressed image was at a different point in memory be because I had done some other things before I took the picture? I most likely deleted the last picture that was taken, took a picture, then plugged it in. Are you just turning it on, taking the picture, then plugging it in?

edit: The reason my black picture doesn't compress very well is probably that I just covered the lens with something black.

12-04-2004 14:05:37

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
I'd love some help with the disassembly, but I still can't break the copyright. Sure, we haven't signed any license agreements, but the code is still copyrighted (it doesn't have a message, but it is still implicitly protected). I can't tell if there is any open source code in the firmware, so no leads there. As for portions for educational purposes, that's fine except the big problem is figuring out what is what. You need access to the whole body of code because it's hard to tell what's important. Hopefully I'll get some help from nambabwe (no pressure!), but I think I'm getting close to reading some data. I've mapped enough of the code that I should be somewhere already!

Patents are a whole 'nother thing -- I'm wondering if it will be legal to make a smal-decoder without violating patents. Unlike copyrights, AFAIK, there is no provision to be flexible when it comes to interoperability purposes. Remember the Unisys GIF patent? People who wrote viewers had to pay. The same thing could happen here, except SMaL may not license individuals. I've got some very-legal ideas on how to get around this...

12-04-2004 14:37:00

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
daBass,
You now have 3 full white dumps - 2 more white1.raw and white2.raw from my 6410 Ritz:
http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then white.zip.
I hope icedragon (thanks so much for making my stop sign real) can answer your other questions. I am not sure if icedragon processed autobrite info to create final picture - it may look better after such processing but it was a gloomy Michigan day and I doubt if extended dynamic range was needed. If others want to help here are the patent and thesis links again:
Patent
http://patft.uspto.gov/netacgi/nph-Parser?u=/netahtml/srchnum.htm&Sect1=PTO1&Sect2=HITOFF&p=1&r=1&l=50&f=G&d=PALL&s1=6600471.WKU.&OS=PN/6600471&RS=PN/6600471
Thesis
http://theses.mit.edu/Dienst/UI/2.0/ShowPage/0018.mit.theses%2f1999-310?npages=143&format=inline&page=39

boodle,
The header of your compressed image started at the usual location, but it has a larger length C8 instead of 9C. daBass may be able to update his layout - hopefully each version of these cameras is not significantly different. Your camera is fine and so is your process. How about a nice sunny outdoor shot - have fun running and trying to keep camera live with usb cord hanging (luckily my neighbors were at work - I took the day off for community service helping provide stocking stuffers and catching up lost sleep).

morcheeba, even if you were to send dump to me I would be afraid to post it. Are any lawyers watching this thread?

12-04-2004 14:58:28

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
Just making sure I'm thinking right: the images pulled off this camera will be about 642x432, right? These raw images are 1288x864, each horizontal row ends with 4 bytes which represent something, the pattern is RGRG GBGB, so every four pixel square in this raw dump represents one pixel with RGB. Or is that not how you demosaic from bayer? I was going by a couple sites I found with google. I'll try to post an outside shot, there's a lot of concrete around here though...not too exciting.
12-04-2004 15:51:53

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Almost all cameras average bayer into the same size array. Here is a nicely colored display of one method:
http://64.233.167.104/search?q=cache:5vETgwtcUvMJ:www.siliconimaging.com/RGB%2520Bayer.htm+bayer+to+rgb&hl=en
12-04-2004 16:19:34

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) Drmn4ea
Profile
All BLACK (or should be) dump, by cutting what appears to be a clock line to the CMOS. http://cexx.org/dakota/allblack_no_cmos_clock.zip

Enjoy

12-04-2004 16:52:38

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Drmn4ea, That's really black, but why did you stop at 2,000,000? The white ones have an uncompressed area that continues well beyond the FFs and I would assume there would be something following the black 00s. Unless you verified all zeros following could you please repost using $27 for bulkout command and 2,600,000 on return bulkin. Thanks so much, this should result in a quick algorithm identification from our compression experts.
12-04-2004 17:41:15

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) daBass
Profile
The compressed .RAW files for an all black and an all white look almost identical.

All black file size: 58876
All white file size (dakotawhite.raw): 63708

They both have the exact same repeating pattern, the black one is not interrupted by other values. (Huffman dictionary used ?).

The difference in size is probably due to fluctuating values for the white shot (not pure white due to sensor damage, errors),
the black values should be guaranteed black.

The pattern pointed out by icedragon is slightly different in every file I looked at. But I don't think it's related to the
shot itself, need to look into it further.

12-04-2004 18:01:27

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
Thanks dakotamod for explaining, that makes sense. I made a quick program that doesn't do the interpolation. It just takes every block of four pixels and makes one pixel out of it, then puts it into a 24 bit bitmap (the two greens are just divided in 2). I've found something weird though, on the raw files posted here as well as my own, it seems like there are pixels that aren't correct. It looks like it's in pixels that would be gray. I don't think it's my program, although it could be. http://www.boodle.info/stop.zip The picture is upside down because that's the way the data is stored. The data is backwards horizontal and vertically. Since bitmaps are read right to left, the horizontal is automatically corrected when doing it the way I did it, but the vertical is still inverted.
12-04-2004 18:03:15

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Looking at the 2 whites I posted, I thought I had bad sensors seemingly occuring in groups of 4 with the first at $120504 (white1 44 0F 08 0A , white2 47 10 08 0B) but boodles has one too 19 02 00 00! Drmn4ea's so so dark he must be dreaming all 0s even at $120504. I'm hoping some of those z's in my sleep tonight. But with only certain offsets being different and the black containing zeros - what else is needed for a wond waving wizard of compression?
12-04-2004 18:15:55

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Nice work boodle, it looks like icedragon did use utrabrite gamma. icedragon please post a link to a detailed description of how you did you magic. This is starting to move awfully fast - is there anyone who can gather all the important links and place on a single page (do not copy info - just paste links with brief descriptions).
12-04-2004 18:22:29

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
utrabrite - it's time I get some z's. That should have been autobrite tm. Are we required to put the tm on every time?
12-04-2004 18:30:44

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Clarification of single page - not on this forum - your own web page. And then one link from here to there.
12-04-2004 18:33:52

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
I had a mistake in my code for extracting the bmp, that's why there were visible errors in the stopsign bitmap before. I replaced that file with what the program outputs now. Right now it just takes the g value from the GBGB line and it's fine.
12-04-2004 19:01:36

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) boodle
Profile
And the reason mine is so much darker than the others is because I haven't been doing it right. Right now mine will have half the green compared to those that still have the bayer pattern. I'll just work on doing the interpolation instead of trying to work with half the resolution.
12-04-2004 19:12:36

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
Thanks for (among other things!) the summary of the downloaded file. These locations correspond well to numbers I've seen in the firmware, so I went ahead and [url= http://www.maushammer.com/systems/dakotadigital/lcd-hardware.html]updated the memory map. This helped identify lots of things in the code! I've always heard about buffer overflows, and we've got a prime example. Too bad the code is below the USB work space; otherwise we'd be able to download and/or modify it. It also looks like the TFT memory buffer is below the workspace, so we can't access the screen. Haven't tried it, though.

I found the routines that initialize the header, so we can see what's static and what's dynamic. I think daBass did a good job already, so I'm putting off exploring that. It looks like the header is $9c in length (like daBass said), and the compressed data starts right after that, so I think it actually starts with a $00.

Also added more detail to the USB commands -- I tried some of them, but got the same $64 error we've been seeing with the other commands. Looks like it's time to try to track that down again.

Dakotamod - You'd better believe that puredigital is watching this forum! I've got no evidence, but the URL for my zvue development page went around the offices of its manufacturer a couple of times. I got to talk with the guy who designed it, and he's really nice. Hope to see him in person someday.

12-04-2004 20:08:52

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) scribble
Profile
This may or may not be helpful.

I did a noise profile on what little of decode3 image--the white car--that was close to being nearly saturated white. It looks like we may be seeing about 8 bit of noise with the new camera. Unfortunately this is about twice the noise I was seeing with my original blue so the sensor may not be as good. In any case, this is roughly the variance you should see on a 'black' image.

boodle--I did a roughly 2.2 gamma correction on your bmp image in photoshop. That brightened the image up to something close to what it was in the stop.gif image.

scribble

12-04-2004 21:03:08

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) morcheeba
Profile
whoops - in my last post, that first thanks goes to icedragon
12-04-2004 21:17:55

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
This thread is growing fast and in an effort to better organize things I am creating 4 new ones:
Links - this should only be used by key contributors - I'll try to capture as much as I can on first posting.
Questions - Primarliy for new talent just getting started.
Discoveries - Significant advances and initial links to new downloads.
Suggestions - Any new ideas are welcome.

Ending with 1 2 many 4 all.

I'll hold off on the first one waiting for morcheeba to start it, or if he wants he can control a set of links from his site which he will can periodically update from the Discoveries thread.

12-04-2004 21:29:49

New Message# 0108 -- RE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) PidGin128
Profile
ok , i decided i wanted a raw file all my own.

ive had libusb 1.8.0 in and working, connected pv2 to pc , added

"Dakota PV2 Digital Camera, Bulk Interface, Version 02/15/2004, 0.1.8.0"=LIBUSB_COMP_IF, USB\VID_0dca&PID_0027

to libusb.inf and got windows to accept libusb as my driver.

removed camera from pc, snapped pic [ of my desk ], immediately connected camera back to pc

opened up the usb poker, camera config 00 was selected already.
set bulk out as endpoint
set binary data file to a file i had pasted " 4c 61 4d 53 1d ba ab 1d 00 00 10 00 80 00 00 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " into using xvi32.
sent it
changed endpoint setting to bulk in
set wlength to 5000000 , forgot exact value necessary
clicked sent it again

renamed angerRcvd.txt to raw001.raw
opened raw001.raw in xvi32 and trimmed off excess zeros, reducing it to 1,048,589 bytes

placed raw to http://pidgin128.web1000.com/raw001.raw

if somebody would [has? ] write a simple tool / script to play with the raw and get it the the stop signs level of quality i would welcome it because even this level of functionality is enough to kept me satisfied [ for the time being ]

12-05-2004 03:53:34

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Please do not use this thread anymore!

This thread is growing fast and in an effort to better organize things I am creating 4 new ones:
Links - this should only be used by key contributors - I'll try to capture as much as I can on first posting.
Questions - Primarliy for new talent just getting started.
Discoveries - Significant advances and initial links to new downloads.
Suggestions - Any new ideas are welcome.

Ending with 1 2 many 4 all.

12-05-2004 04:07:28

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) dakotamod
Profile
Growth again dictates a better organization. A small group of us have started a new forum at: http://camerahacks.10.forumer.com/index.php .
04-18-2005 20:02:17

New MessageRE:Hacking Pure Digital Continued (from one use to many) (modified 0 times) astalavista
Profile | Email
CVS RED - NEW FIRMWARE 6550 (pv2tools fail) (i need some help about this model), what i am gonna do

------------------------------------------
Firmware - 6550
Hardware - 06
Typeid -2B
Cmp Typeid - 2B
ID -DB2051301280
Ralm Id -20
-------------------------------------------

04-26-2005 13:38:51

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