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.net Reply to Thread | Printer |

Home / MISC Areas / Cameras Discoveries - 1 2 many 4 all Discoveries - 1 2 many 4 all

Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Use this to post any advances, links to new pictures, analysis of dumps, hardware modifications ... 12-04-2004 21:37:15

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile There are 3 areas to explore: 1. Test all combinations of usb commands and parameters looking for a way to access flash, or sdram code outside of image buffer. Be sure to keep track of sequence incase it permanently disables your camera - that would be an important discovery to report here. Those who have pulled flash and disassembled it have the best chance of figuring this out. 2. Compression algorithm - there are 3 all whites and 2 blacks with uncompressed images in the new link section (the cut line black is truncated but still very helpful). All 3 whites have an image of FFs up to $120504 where there appears to be four damaged pixels (would make sense if it were just one camera, but in same location in 2 cameras eliminates that unless there is a repetitive flaw in manufacturing). The cut line black is all zeros, boodle's black has 06 08 07 09 at $120504 with a rare 09 but does not stand out like the values in the white images. Tracing the above oddities perhaps trying various compression schemes to see what happens to these rare "damaged" areas might provide a discovery worth posting. Any further suggestions should go to Suggestions - 1 2 many 4 all thread. 3. Drug store cameras - CVS, Longs and others. These have added a realm id in response to 3 finger salute. They are also likely to sell in greatest quantities (There are 6 CVS stores less than 2 miles from that Red Stop sign and yellow fire hydrant which icedragon did such a great job on - http://www.mindspring.com/~insomniaskunk/decode3.jpg ). Please continue to use the separate CVS thread for activity on these cameras only posting a major discovery here. 12-05-2004 08:15:21

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Left one out. 4. Test extended dynamic range of SMaL sensor. Woke up to a rare sunny day in Michigan. Here are my 2 1985 Cadillacs, the first I bought at peak of my career while working for EDS and since it has treated me so well for 220K miles, I bought another well kept white one last year with 100K miles. Again I have some red and yellow - this time to test Autobrite tm. I noticed on my previous shot that red of rgb was higher on yellow fire hydrant than red stop sign. There are also lots of shadows from tree limbs with no leaves. I hope icedragon can work is magic or someone else to begin clarifying the capabilities of SMaL's patent. White Cadillacs http://briefcase.yahoo.com/zqcpwr Click on Pure Digital and then sunnycad.zip. 12-05-2004 09:39:42

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Is the new technology better? Here are the Cadillacs taken with an old Blue: http://www.photo.net/photodb/photo?photo_id=2934983 I was just going back to sleep after the PV2 shot, when I realized we should have something to compare against. Also, forgot to mention that one my favorite 1985 Cadillac features is direct access to individual sensors using the climate control buttons and displaying results on fueldata center (all standard - no need to pay dealer). 12-05-2004 10:58:03

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Updated all-black dump by "no CMOS clock" method (with transfer length corrected this time - ~ 2.5MBytes of data) : http://cexx.org/dakota/black1.zip I also (verrry carefully!) sucked the solder off pins 19 ~ 24 of the flash memory and lifted them off the board. Pins 20 ~ 24 don't actually do anything (non-connect); I just wanted them out of the way so I could get at 19, which is the WP\ signal (write protect) and wire it to ground. Result: read-only camera! Much to my surprise, picture taking still works most of the time. The "pictures remaining" even counts down while the camera is on (returns to 25 after powercycle). I was still getting occasional odd behavior in the lab; I don't know whether it's due to the various hardware mods or the cam simply doesn't like my bench supply (just haphazardly clipped onto the battery terminals). On a couple occasions, pressing the shutter caused the camera to start drawing a "large" amount of current for maybe 5-10 sec. (~ 85mA; idle current is ~ 17 mA), then reset. On another occasion it displayed the number 34 at the bottom-left of a black screen; and still another, it emitted a long, 3-tone descending beep (like a sound you might hear when your character dies in an old videogame), maybe 2 seconds in total, displayed the "Turning off" screen and shut itself off. I also have some descriptions of signals to the CMOS, which I'll clean up and post soon. 12-05-2004 14:54:59

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Notes on new blue..... Did all black [covered lens] black? data appears to start at e0000 and stopped 1eed7f could not determine where compressed data is ...... tried poking around with usb cmds leaving len 270000 $80 returned 269 bytes and 00 status others most of time dumped same as $52 tried $19 with firmware.bin noticed nothing unusual... later disconnected to take white pic's turned camera on it displayed 23 pic's did delete to 24 did delete again and was able to delete ..now display 25 but could not take any pics. keep hitting shutter sw and suddenly flashed and went to 24 ,,,but now would not take 24...and kept cycling on/off?? ..did 3button salute and came up with 24... did delete and went to 25 but could not take pics ..cycling .... put on pc did another $80 appeared to get previou results ...still could take no pics kept pressing buttons then suddenly took pic .. went to 24 tried again went to 23 ...tried again went to 22 did a delete went to 23 tried delete again .. could not...camera appears to have self healed???? tried white... data started at e0000 .... there appeared to be data embedded within the white ..... maybe camera didn't self heal... NOTE PV2-RED looked at the stopped cmos file ... all zero raw?? it appears to me that the compressed is full of a repeating 9 byte pattern FE FF 7F BF DF EF F7 Fb FD now what kind of compression is this??? 12-05-2004 19:35:32

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile I made a quick program, it's not working quite right, but it makes pictures that are at least recognizable. For filling in colors I just used one pixel that was close, and you can definately tell. icedragon can probably do it a lot better, but this can give a general reference. And for some reason all of my pictures turn out with a green tinge (most likely a stupid mistake in the code). I've been working on using interpolation but probably won't finish until next week after my finals are over. http://www.boodle.info/dakotacad.zip here's the Cadillac picture. 12-05-2004 20:26:41

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Thanks, boodle. I'm afraid that by time I realized I needed a comparison shot with old Blue, sun was higher in sky; making for a difficlut comparison. I would still have expected to better see lines between slats extending into bright area due to an extended dynamic range. I had also moved the car back into garage between two pictures. Hopefully another poker can take two identical shots using old and new cameras. Just puzzling over patent - if voltages are varied during shot to prevent washout, why would a pixel value need further modification (if the washout is all FF any shift right would still not add detail). We need futher understanding of icedragon's checkerboard patern. Hey wait he did indicate it was twice as big as image - I was thinking whole sections would be extended but if its pixel by pixel then there is alot more information to my PV2 Cadillac picture. 12-05-2004 20:56:47

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile A properly interpolated picture would probably look a lot better than that. If you compare what this program puts out of the stop sign compared to icedragon's, there is a big difference. http://www.boodle.info/dakotastop.zip The coloring is somehow wrong (greenish) and it's not nearly as bright. Because of the way I find the missing colors in the pixels, fine details that are actually there get lost. 12-05-2004 21:06:48

RE:Discoveries - 1 2 many 4 all (modified 1 times) morcheeba Profile Another small step in the USB command handling! So far, every command we've used has resulted in an error code of $64 (the last byte of the message we get back). I tried other command codes that looked like they would do interesting things, but no luck - always the same thing returned. So, I carefully went through the code again and figured out how to get a different error code! whoo-whee! Ok, it's not as exciting as it sounds because it's still an error code, but it means that I'm on the trail of the secret formula... On a side note, I thought I had broken my camera - it had stopped responding to the old commands. It took me a while to figure out it was a memory allocation error - something had run out of memory. Restarting my program didn't clear it, but restarted Project Builder (it's a mac) did it. Hmm. Anyway, that slowed be down a bit.. I have to finish trying a few permutations, and then find the new error code in the firmware. -- Ok, I've got a challenge for everyone. It concerns determining autobrite gamma. I've got access to a calibrated light meter (well. actually it's out of cal, but close enough), so I can measure some spots, take a picture, and see what value comes out of the camera. So the challenge is, how do I make a high-contrast image with a roughly linear gradient from dark to light? If the gradient isn't totally linear, I can take a few measurements to correct it. But, the trick is to get a large contrast range. I was thinking a bright light projected against a wall, but that won't get that dark. Maybe it will... any suggestions? (this can be a longer term project -- we can use an approximation until later. I can also do the color calibration to fix any tint shifts we see, although I'll be a lot of this is getting the gamma right) 12-06-2004 02:12:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile I think I've found something new with the usb, although I can't make it happen every time. I think it's my cable. If I plug my camera in without being powered on, sometimes nothing seems to happen. but if I open "Usbpoker" it recognizes the camera. Other times, the ready light will light up for about 10-20 seconds then turn off. This is the interesting part. When the ready light comes on for the extended time, I try to run usbpoker but it won't find it. However, when the ready light turns off, it is recognized. After I "Open it" in usbpoker, the ready light starts blinking. It seems like it's then in a state where it waits for a bulk out, waits for a bulk in, and after it's done sending after the bulk in it starts blinking again and it can be repeated over and over. I even made it error, but after I sent the bulk out and bulk in, it seemed to be fine and would accept more bulk out/in's. The bulk out that I was using was the memory dump one that we've been using, and the bulk in was 2600000. If this is something old, sorry. I just thought it was an interesting state that the camera goes into. 12-06-2004 08:43:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Potentially very significant boodle, I have never been able to do more than one bulkin, bulkout sequence without having to close usbpoker and replug camera. I never paid any attention to green light status. Do you get the $64 error when in blinking mode, I am not sure if usbpoker returns error codes - if not maybe Drmn4ea can give us a new poker. 12-06-2004 09:18:05

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile I've only been able to get it into that mode a couple times, it seems like my cable has to be in some exact way and I haven't figured out what that is yet. One of the times I did this, the first thing I sent was a bulk in expecting 2600000. It returned an error, I'm not sure what it was, because usbpoker just tells you that there was an error, not what kind. Then I sent the bulk out I've been using to dump the memory. After I sent a bulk in with 2600000, it returned data just like normal. I think I then did bulk out then in three more times. After every bulk in, it would start flashing again. 12-06-2004 09:25:04

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile boodle, another thing to try - change direction bit (look in morcheeba's usb maps) which will write instead of read on bulkin - I have done this but not been able to verify due to replug issue (which you have overcome). Next step is to keep trying other commands until you write to a code area and maybe end up disabling your camera which would deserve another post. 12-06-2004 09:26:16

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile morcheeba -- with the right equipment creating a gamma plot is a snap. Take an image of a brightly and uniformly lit background thru a Kodak callibrated step tablet. That's a strip of 21 neutral density filters where the opacity varies from near zero to 1000/1. (a range of optical density fro 0-3 for those used to thinking in this unit.)Once you have a good image you can charactorize the sensor and calculate everything from the gamma to the sensor well depth. If needed and I get my ritz blue working, I can do the measurements for the group. However I think we are too hung up on the autobright patent. Everything I've seen so far points to a couple ultra cheap cameras (average price to Pure Digital of maybe $35 in quantities of 5000 to 10000) and at that price there's no room--and IMHO no need--for any fancy technology. For example I took the BMP image of the stop sign, assumed it had a linear gamma, put it in photoshopCS, did a levels adjustment with the gamma box set to 2.2 and came up with an image that looked reasonable at first glance. But if needed and there's some problem with using the conventional settings, I can do the fancier measurments. scribble 12-06-2004 10:07:13

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I've got a chain of logic here, so let me start at the beginning... First, the fancier camera isn't necessarily more expensive. In terms of silicon area, the autobrite probably costs next-to-nothing -- I'd think the price would depend on packaging, foundry, and license costs more. It would be more expensive for SMaL to develop a special non-autobrite camera. Second, from what I understood of the patent, it's a piecewise-linear response curve. You can approximate it with a exponential curve, but it will have errors. Third, I think even small errors are important. Greyscale images would probably look ok, but color images would have slight color shifts because the error of the red, green, and blue channels would all be different depending where on the curve each individual component is. I think using another camera is a good idea (I don't know why I didn't think of it, darn!), but it may not have the contrast range of the autobrite (that's kindof the reason for the autobrite). I like the kodak calibrated chart -- 1000:1 should be very good. Does anyone have use of one of these? 12-06-2004 11:19:27

RE:Discoveries - 1 2 many 4 all (modified 1 times) boodle Profile I'm not sure if this helps with anything at all, I'm posting 4 raw dumps in a zip. http://www.boodle.info/dakotawhites.zip the first is a picture taken of a white piece of paper, I think it's the same as the one I posted earlier. The other three are pictures I took with the camera about 1-2 inches from some tin foil that was cuved a little so it reflected the flash back into the lens. All four have 1284 pixels on every line of all 255s or 0XFF or however you look at them. Each line ends with four bytes. These four aren't consistent from picture to picture. I'm not sure what these bytes are, but it might help with something...not really sure what. Possibly compression? Since all the lines are all FF's, the only differences are the line ending bytes, maybe looking at the correlation between the differences and the resulting compressed files will help with the compression? 12-06-2004 12:32:07

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Those are probably dark reference pixels. They're covered by some metal on the imaging chip so they should be as dark as possible. This helps the processing software determine the black level, which can vary from chip-to-chip and with temperature. They should be helpful with the compression, thanks! 12-06-2004 13:19:13

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile I think it bit odd (pardon the pun) that the "checkerboard patern" possibly Autobrite(tm) area in Drmn4ea's latest full size cut clock line black is not also all zeroes! Maybe the patern area is just a mask applied to raw image before compression. Any other ideas? I was going to post this in suggestions, but it seems the team including myself will probably continue to post suggestions here. Let's try to keep them relevant to recent posts and still use suggestions for less relevant ideas. Also there is a good chance that autobrite(tm) is handled by imager chip before it is stored in sdram. 12-06-2004 14:07:27

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile OK, compression solved? - there is none in sdram. Remember the earlier post where SMaL claimed no compression just encryption. I am bothered by $120000 - $12000 being equal to 1280x864 and the possibility that in sdram there is no compression only application of a mask that follows the raw image at 22FB00 dropping 8 columns since 22FB00 - 120000 is 1288x864! Everything is starting to look blurry - can someone please confirm! I do realize there is slight offset problem with the 9C header but I think that can be incorporated into this scheme. The only compression probably takes place when placing the image in flash. 12-06-2004 15:11:03

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Wrong again. Sorry forgot about 61K whites. There is a compression but it probably takes place after a mask and in a way that may allow for inabilty for any compression routine to be able to compress every random file to a smaller size. Either that or we may still have some autobrite info. 12-06-2004 15:27:49

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile morcheeba-- I own a steptablet. The big problem, now that I've thought about it, is focusing close enough so I could get a decent size image. The tablet is only 1 by 4 inches. Can the lens assembly be screwed in or out like in the old walgreens or is it fixed because of the shutter? As for the autobrite part of my post I maybe totally off base, but I seem to remember reading that sMAL stored both the pictorial information and the scaling information is a single byte. For example, if you wanted to scale your dynamic range by a factor of 4 you only have 6 bits left over for color and luminisity information--something that doesn't make for good pictures of Susie opening her XMas presents. That my only point and if I'm wrong it won't be for the first time. dakotamod--What version of libusb did you download? I'm using ver 0.1.8.0 from about a year ago and I had to come up with a different modification to libusb.inf in order to get win2000 sp4 to recognize my camera. But I now have pictures off the blue. The overall file size you pull off the camera is still 2555917 bytes but the uncompressed image starts somewhere near 920000 bytes. I'll zero in on the exact number if I get back to the camera later tonight. icedragon--How did you generate the decode3 jpeg? The exif info in the jpg says it was done using photoshopCS, but I've not been able to create anything close to a full size color image or a properly demosaiced greyscale image using photoshop raw. 12-06-2004 16:15:40

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile scribble - I am using release 20041118 scroll down on http://sourceforge.net/project/showfiles.php?group_id=78138 and download - libusb-win32-device-bin-20041118.tar.gz (I do not think it is necessary though). And also your memory map is probably offset by the lack of an LCD/TFT on the Blue - look back at icedragons post on old thread or I think morcheeba updated his maps based on that - please post a Blue map when you can. Sorry again, but $270000 was just a guess for getting all of raw image - which it did but we are missing more of the "checkerboard patern" after that, I recommend using 22FB00 + 10FB00 (another 1288x864) or $340000 in usb command and reading back 3,500,000 with bulkin. Drmn4ea, we are going to need that all zero black again with the rest of pattern, mask, autobrite or whatever it is. 12-06-2004 17:09:45

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I think the transfer size limit is $2C0000 -- that's what it appears to be in the code, but I remember I couldn't verify it with testing. It could have been other issues, though. Anyway, if $340000 doesn't work, try something a little less than $2C0000. That corresponds to $400000 in SDRAM memory, a nice power-of-two boundary. 12-06-2004 18:33:54

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Not sure what it means but all of my pictures starting at $22FB00 are over 90% the same. The same holds true for boodles initial white and black (and probably his newest whites). Thus no autobrite and a mask that varies primarily with camera (I also checked Drmn4ea's latest black). I am puzzled by the minor differences - perhaps these are due to a sequence counter. Based on the checkerboard pattern it is probably generated by a routine that hopefully morcheeba can find. I suggest that the $22FB00 pattern is applied (probably xor) against the image at #120000 leaving a result at $12000 (not a typo it has one less zero) which is then compressed in place. If Drmn4ea can submit a 3,500,000 long cut line black I think we might be able to see the remnants of pattern appliction to zeros following compressed image up to $120000. morcheeba, please post your magic code that did not return an error code or did you unknowingly experience boodles blinking green ready light. Yeah, I seem to remember $300000 failing - maybe if we can do multiple reads after getting into boodles blinking green mode. 12-06-2004 19:08:12

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile For anyone trying to work out a program or perform manual verification of masking - it most likely is only applied to 860 rows by 1280 columns dropping 4 rows and 8 columns since the orignal raw image is left untouched at $120000 and there is only room for 864 by 1280, dropping an additional 4 rows in addition to 8 columns allows room for a 9C header. 12-06-2004 19:43:46

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Another angle on helping morcheeba look at the code. He has already pulled and dumped his chip. There would be nothing illegal if he gave the chip and reader to someone else to disassemble on their own. morcheeba, do not mail it to me, my assembler is rusty (cut my teeth on IBM assembler modifying operating system code) in the 70s, got by PC protection using it in 80s, and even recently improved performance by a factor of 4 on an HP PA-RISC application by forcing C code to produce assembler instructions I wanted; using assembler is not allowed where I work now and really was never been given respect it deserves anywhere I have worked. I have thoroughly enjoyed this project, but am disgusted by the quality of the SMaL imager and fruitless claims of 500 times better dynamic range. I will continue to monitor and aid the PV2 progress, but hope someone else can help morcheeba with moderating these threads. I am thinking of taking my unopened CVS PV2s back. I returned one of my 3 original Blues when I bought the Red I have used on this project. There were two Blues left, and I placed them behind several new blues - so they may still have 3. I might wait till scribble performs a noise analysis on my posted white Cadillac and the linked one on photo.net, but I am really tempted to go back to Ritz for those Oldie but goodie Blues. I would also like to thank morcheeba for indirectly triggering my associative memory banks - when I was reading his biography a Lionell Ritchie song popped into my head which now appears as a caption: http://www.photo.net/photodb/photo?photo_id=2934256 12-06-2004 20:24:39

RE:Discoveries - 1 2 many 4 all (modified 0 times) grumpyoldgeek Profile Concerning the copyright issues with the disassembled code, there was an old trick that was used back in the CP/M days. A consistant method of disassembly was provided to all interested parties. The parties were each responsible to do the disassembly themselves. Then a copy of the *comments only* that were derived from the code were distributed in such a way as to line up with the disassembled code. Obigatory disclaimer: I am not a lawyer and this is not legal advice. 12-07-2004 00:07:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile grumpyoldgeek - I remember this was also done with Applesoft, too. What you've described is pretty close to what I've done. Go to my firmware.bin page and download the disv8 disassembler package. This package includes my file FIRMWARE.COMMENTS. There's no actual code (of course), but I've identified & commented about 360 functions and about 700 individual lines. The disassembler also does a good job of auto-commenting about 9000 other lines (mainly identifying constants & initializations). I've been analyzing the code to see what commands we should send. The first command has to be $80 and I think it needs to be a write to the camera. If the length is not $80, then you'll get error code $61. I've tried sending $00's (for lack of imagination), but no results. I need to find where that data goes & see what's done with it. Also, the Logical Unit Number (LUN) is used in this command, but I don't know how yet. Still more to explore... I've been adding to my command code analysis 12-07-2004 00:51:40

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile dakotamod, Are you 100% sure differences in your two whites posted on Links thread starting at $22FB00 are due to a sequence counter? Post a few more whites and an algorithm based on an incrementing sequence counter that produces the random differences! I liked your eye on photo.net; do not despair - with SMaL and some very brite light you may be able to capture your retina looking into one of these lenses. Do not bother taking your camera in to be processed by a network server. They have your 3 finger salute. 12-07-2004 06:33:24

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile The uncompressed raw image starts at E0000 (917504) It can be decoded partially in photoshopCS (money) and in Irfranview (freeware) to produce essentially the same image. The grey image is not demosaiced and there is no attempt to extrapolate the color or luminisity between the individual sensors in the bayer pattern. But all and all the image doesn't look that bad especially after applying a gamma correction of 2.2. Color images are more confusing. Depending on how I set the parameters I get a narrow strip of the image with wierd colors, three grey scale images scaled down by 3 and a composite grey scale image where the red channel is the top of the image, the green channel is the bottom and the blue channel a hunk of the pattern. Since for PhotoshopCS and Irfranview work the same way I'm hoping that with a proper header to go with the raw data we can make Irfranview do our raw conversions. Anybody know anything about raw image headers? Next discovery--I was able to find my second blue and decided to compare cameras and look for patterns. And since even the thought of searching out patterns in a list of 2.6 million numbers makes me shutter,I used a visual approach. I created images 1288 pixels wide and xxxx pixels deep and laid them side by side on the monitor to look for differences. To display them I used ImageJ, an excellent freeware scientific image analysis package that can be downloaded from the NIH website. To sum up what I discovered. The pattern/mask depends on which camera is used. It changes every 51 lines so it was created in 64k blocks. It's there when the camera turns on. You see it when you do a bulk download with no pictures. And it does not change when you take a picture. So I hate to disappoint, but it does not hold any autobrite data. Finally if you blow a 2.6meg image to the limits, all the data in continous except for a tiny partial line of pixels way down at the bottom. 51 pixels. 51 lines per pattern block. Coincidence? I doubt it. Dakotamod has said he'll post my data in his Yahoo briefcase. There will be the raw data with no pictures, a view of the bookcase by my window and of some blue green and red posters, plus the jpg images I used. The images sets were taken with both cameras. Finally there will be text files with the 51 bit camera signatures. I think the filenames are self explanitory but if there are questions post and I get back to you late tonight or tomorrow. 12-07-2004 15:22:59

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Firstly - some new dumps from the blackest camera of them all. Finally the MAXIMUM data that can possibly be transferred. By a little trial and error I found the maximum dCBWDataTransferLength appears to be 0x29FFFF, or 2,752,511 bytes. (If making a mad dash to update your 31-byte bulkout sequences, don't forget that the field is stored backward-endian!) http://www.cexx.org/dakota/pv2stuff/dumps/ A full "cold-plug" dump is here, just for reference. (camera off, no batteries, plugged into USB and dumped) I also took a few dumps by hot-plugging the cam at various stages of power-up. A representative dump is in poweringup_ready.zip; file comparison showed they all matched bit-for-bit whether it was plugged just after powerup, at "Camera Ready", or any point in between (before picture). Strange, no? All-black dumps under controlledish conditions (dumped after picture taken, "Camera Ready" and the screen blanked; both batteries and USB cable fully removed for at least 30 seconds before run) seem to differ only a few bytes: Comparing files allblack4.dat and ALLBLACK5.DAT 0004698B: 0D 09 0023337C: FB 7B Comparing files allblack4.dat and ALLBLACK3.DAT 000FCD90: 06 04 You'll notice these start at "...3.dat"...the first two (taken under non-controlled conditions, e.g. batteries not removed between runs, hot-plugged at a not-well-defind point after shutter press, maybe while updating screen or still writing FLASH) showed considerably more differences (pages and pages and pages and ...) both to each other and to the last three. The dump in the .zip file is allblack3.dat. Finally, have a look in "sw1.zip" - if the USB is plugged in (cold-plugged) with mystery button SW1 held down, the 2-tone beep on claiming the interface is replaced by a single high-pitched beep. This is the dump taken under this condition, it's quite different! Also, a new build of the USB poker with a couple little fixes (version 0.03) : http://www.cexx.org/dakota/usbpoker.zip In this build: * If data received is less than data requested, only the received data is written out (e.g. if you requested 20 bytes and got 1 byte, you don't get an output file with 1 data byte followed by 19 0x00s) - UNLESS there is an error reported during transfer, then the whole buffer gets written out (since it may still contain some valid data, but no telling how much). * In the event of a USB error, usb_strerror is called to report the error message from libusb. (no longer just "-1 bytes"). But see NOTE below! * Timeouts on bulk transfers lengthened from 5 seconds to 15 seconds (now specified in a #define). If short transfers worked but you were mysteriously getting "-1 bytes" on large transfers, that was probably the reason! At least on my machine, 5 seconds was not long enough to pump out 2.5MBytes. NOTE: When morcheeba talks about a camera command returning an error code, e.g. 0x64, this is the code returned in the last byte of the Command Status Wrapper, which should be returned at the end of a dump (look for the familiar "LaMS..." bytes near the end). USB errors reported by the operating system, including anything that causes "-1 bytes", are a completely different animal. Also note, if your dCBWDataTransferLength is very close to the maximum, you don't get a full (or any) CSW at the end of your data. 12-07-2004 23:09:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Another small breakthrough... I got some data back that's different from what everyone else has been getting. Basically, reading $80 bytes from command $80 will give you a portion of the file NVRAM.DAT stored in the flash. A dump is on my usb command page. No idea what this means yet; still disassembling... 12-08-2004 01:13:27

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile After rereading the patent and thesis again today, I am 99% sure there is no additional Autobrite(tm) data. It is still a puzzle as to why mask starting at $22FB00 varies slightly with each picture (could someone check to see if it varies with each power on off no picture). For Blue PV2s mask address appears to be $1EFB00, thanks scribble(if you can figure out a complete memory map please post); blues are half the price and IMHO the LCD sucks for photography. I have asked on other threads for comparison shots that show some Autobrite advantage using a camera with SMaL and one without(these could be any cameras not restricted to Pure Digital). How about you brite_eye from above - think you can give us some pics? Drmn4ea, Thanks for the update. Please read suggestions thread for more comments. We all (except "critical path" morcheeba) need to monitor 3 main threads (discoveries, questions and suggestions). 12-08-2004 02:21:53

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Just awoke realizing that since I already had all of scribbles files, rather than wait for him to resend in 5MB chunks for my lousy yahoo "brief"case (please can someone who wants hits offer to start posting downloads). Well in this particular case "no pain, no gain" may have significant meaning: My pain in putting these back together for scribble gave me an opportunity to see an 86% compression of camera1's nopicture and 46% for camer2's nopicture! Hopefully if someone can explain that we may better understand mask generation and even following compression. If anyone has further questions please post on Questions thread. Here is link to scribbles labor containing 3 zips: http://briefcase.yahoo.com/zqcpwr Click on scribble then each zip. 12-08-2004 06:30:14

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile Ok folks I warned you in a previous post I could be dangerous when it came to these pesky hex numbers. This is expecially true when I tried to use the plotting routine of a what I'm beginning to fear is a seriously buggy image analysis package as an impromptu hex editor. Obviously my 'signature' is a block of 64 numbers--not 51 as my embarrassing misreading of what the plot routine was saying. What's more disturbing--atleast from the prospective of a couple of my other home projects-- is that ImageJ seems to randomly miscalculate its pixel values by 0 to 3 units, something that certainly affected the noise calculations I've been making. So ignore the numbers in my sig.txt files. They are, to say the least, noisy. The one good thing about this fiasco is that I discovered the problem with ImageJ now rather than in the middle of a consultant job. That would be really embarrassing. Anyway, I still think it's interesting that there is a block of data sitting out all by its lonesome after what usbpoker and perhaps many other programs would consider to be the end of the file. scribble 12-08-2004 15:30:53

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile This may not be a discovery, but scribble discovered a pattern that I think has an interesting property and so I am following up his discovery with a suggestion here to avoid rabbit hopping (a white rabbit we are using daBass's highly compressed white images). I had previously failed to get some good numbers out of bartoni's recognition of 860 rows containing 60 9 bit "011111111" repititions - 9 cheers for bartoni (are you still here?). I suggest there may be meaning behind 1280/60 * 3 = 64. Clearly each row is encrypted (probably just xor'd with scribbles 64 byte masks) and compressed individually - it should be simple to decipher using above but my neurons are shorting out. The 3 may have something to do with going from single 8 bit pixel to 24 bit RGB. Hope no one falls in a whole chasing this rab bit. 12-08-2004 16:44:22

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Hole not whole - must of been thinking a white hole. Does Drmn4ea's cut line black have a black hole - 60 repititions of a 9 bit "000000000"? I have just posted a suggestion followed by a question in discoveries - hope I don't get a shared memory violation as a response. That white hole thing was accidental but it quickly led to black hole, thanks to a high regard for Stephen Hawking in my associative memory banks. 12-08-2004 16:57:33

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email $80 on cvs blue length 80 800 8000 80000 transfers ok 0000] 67 45 23 01 00-------00 0080] 3a 13 whatever .......up to xfer length and ends in good status length 300000 also worked data all looks same........... 12-08-2004 18:21:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile mike, please also post your results on "CVS digital 1 use Cameras...same as others?" thread. Posting your just achieved discovery here is good. Please add more detail to the CVS thread so others can replicate your results. We need to know what operating system, device driver, usb poking software ... and whatever else you have done such as are you able to use $52 to read image data. Perhpas there is no usb in camera and you need to write a pack file (goto link for daBass in Links - 1 2 many 4 all). 12-08-2004 18:54:46

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile scribble, I also thoroughly enjoyed Polar Express. dakotamod, have you found the tracks or are you still skating on thin ice. Do you really think 1280/60 * 3 = 64 belongs here on discoveries? Everyone, As I mentioned earlier in Questions thread, I am a Mathematician unlike dakotamod who is just a programmer. I love prime numbers. Looking at Drmn4ea�s allblack3 there is not a black hole, just same repeating pattern as in dakotamod�s whites posted on �Links � 1 2 many 4 all� (very cute dakotamod � you never forgot the perfect number pattern that always starts with a power of 2 progression) . Now for my discovery: Starting at $1209D in allblack3 there are 52,187 repetitions of the 9 bit pattern �111111101�. I immediately recognized prime factors 23 * 2269! In response to dakotamod�s and the caterpillars question �Who are YOU?� : �I--I hardly know, sir, just at present-- at least I know who I WAS when I got up this morning, but I think I must have been changed several times since then," 12-09-2004 04:38:59

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile Fogot to mention pattern "111111101" is the prime number 509. 12-09-2004 04:49:14

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Sorry about questions moon shot brite_eye. Your punishing primes put me back on track: 23 x 2269 = 23 x 2268 + 23 = 52164 + 23. If we use a JPEG 8x8 block then we have 1288/8 = 161 and 864/8 = 108. Now 161*108*3 = 52164 from above. Times 3 for RGB. The camera must be debayering. Why 23 and not 24? Perhaps a 7 bit intensity followed by 6 bit RGBs. Now who can answer if all we need is a JPEG header and if so create a such a header that works on all the images? morcheeba, we are getting close! I hope! 12-09-2004 17:19:47

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Forget about the 23,24 question it is irrelevant. Been busy today, last night my old 85 Cadillac (my new 85 Cadillac is garaged for winter) barely made it home chugging all the way. After 4 hours of grueling labor in the cold with grease up to my elbows, one broken plug and a few cracked knuckles, I made it it to work in a refreshed caddy that was purring like a chesire cat. 26 mpg on the way in 21 on the way back (it was getting just15). 12-09-2004 18:30:19

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile First the undiscovery. I modified the ain27.dat file as dakotamod suggested. 29FFFF didn't work but 29OOFF did. With the original ain27 file the contigious data ended at 27000D and the 'signature' started at 270FC0. With the new file it's 29000D and 290FC0. And since the "signature' are different and there is no obvious corolation between the two signatures, I suspect it's an artifact and nothing to do with conversion. Now the discovery. After reading a post in the CVS thread, I tried the three finger salute on camera 1 to see if I could bring up an id. During the process I accidently took a picture of my knee. This may or may not have incremented the picture counter. At the time I was doing several things and wasn't paying attention to the counter. Whatever happened, when I pulled rhe image off the camera, the first 80 entries were 00. Moreover if I now ask for a data file that is smaller than what the ainxx.dat file specifies, I get an error message, usbpoker closes the camera and the image is stored--something I can live with until we come up with a fix to restore the factory defaults Far more interesting is the pixel pattern in the compressed data. In the images I'd taken up till then it had alway looked like random noise. This time I was immediately struck by how much it looked like wood grain--the patteren you'd see if the cut in the log is a few degrees off axis to the three rings--a series of narrow hyperbolas. Here are the key points. There are 1mages, knee1, knee2 and knee3. I'll be uploading the raw data, plus jpeg and line profile plots to Dakotamod sometime tommorrow The hyperbola's are on average equally spaced. A line profile plot or slice thru their vertex consists of the region of random ADU's seperated by a region of spikes that on average don't drop below 128 ADU. The number of spikes increases as the number of hyperbolas increases. Knee1 has 4, knee2, 6 and and knee3, 8. When I measured the distance between the first spike of 6 adjacent parabolas in knee1, the averaged distances was 319.666, one quarter of the 1280 size of the 'truncated image'. This is the image where the 4 black pixels or either side of the 'total image' of 1288 have been truncated. The lines of the hyperbolas consist of overlapping segments. The length of the segments is equal to the length of the spike regions and consist of spikes patterns very similar to those seen in the vertex line profiles of their respective hyperbolas. Knee1 had a wide range of grey values and the spikes go from about 128 to about 255 ADU's. Knee2 had very little grey, just blacks and whites, and the spikes are apodixed by a triangle function whose base began at 128 ADU. Knee3 is also mostly black and white except for a grey patch in one corner. It has the most hyperbolas, eight. Of the eight, s seven are apodized like in knee2, but the eighth dropped down to 128 ADU like in knee1 Hopefully that hasn't been too confusing. So what's the point. If the collective math wizards in the group could come up with a list of possible math operations that could be used in a compression routine and would generate this sort of 3D plot, that would be helpful in sorting out the compression routine. If they also came up with a list of compression routines that wouldn't create this sort of plot, that would be even more helpful. scribble 12-09-2004 19:44:33

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile As far as I can tell the CVS camera and the RITZ cameras are the same ( or very very close ). I posted in more detail in the CVS thread, but I was able to extract a few images from the camera using the USBpoker, and a soldered on usb cable. I have used no special commands. I haven't been able to get a color image to work out correctly, but they look very clear in grayscale mode. I am curious what icedragon did to get the color images. One of the images i took goes from Black to white. The fade only takes place on the right 25% of the image, I can try and take another one if anyone is interested. The images are available here : http://bentfork.gomen.org/CVSpv2/ 12-09-2004 20:55:06

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile Shortly after I made my last post I occurned to me that image of the compressed data might simplify if I rearanged my x/y plane by dividing the 1280 rows by the number of hyperbola I was seeing. And the images certainly did when I converted the 4 hyperbola knee-1 image into a 320 wide image. And so on. Multiple dark hyperbolas coverged to form bright and wider hyperbola and detail jumped out of the image I'll post a few representive jpgs and the raw data; but if anyone is going to work on this they'll need irfran to create the x,y patterns and ImageJ to see the z axis data. Better yet, does anyone knows of a freeware x,y,z plot package were you can cut slices and see all coordinates of a point at once. That would be a very good way to visualize what is going on during the compression scribble 12-09-2004 21:54:08

RE:Discoveries - 1 2 many 4 all (modified 0 times) scribble Profile Bentfork--you are at about the same place I am when it comes to creating images. So far I've tried photoshopCS and irfranview. Both work the same way. The strange image in the middle is a composite. The red channel is the top of the image, the green is the bottom, and the blue channel comes from somewere outside the image. As for a fix, I'm hoping that adding a header to the raw data will tell the converter how to do its job properly. With luck all the problems will go poof. Can you do a usb dump of your black to white gradiant from 0 to the end of the image? If you zipped up the raw data and put it up on your site, I could use it to check the CVS compression scheme against the Ritz scheme. scribble. Ps I bet you put vinegar on your french fries. 12-09-2004 22:23:53

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile JPEG? JPEG 2000? Who knows JPEG? Looks like it may be JPEG to me. For Drmn4ea's allblack3 there are 52,187 repetitions of the 9 bit pattern �111111101�. 52187 = 23 * 2269 = 23 * 2268 + 23 = 52164 + 23. Now 52164 = 1288/8 * 864/8 * 3 (rgb). That indicates 8x8 JPEG blocks! The camera is debayering and creating a summarized image based on 8x8 blocks. All 3 colors are always zero in each block so it only takes 3 9 bit patterns per block. There are 161 * 108 = 17388 blocks. 17388 * 3 colors = 52164 repittions of a 9 bit pattern. Are there other photo formats that compress using 8x8 blocks? scribble, You can download raw photodesk free for a 30 day trial - probably doesn't do what you want but you may find it helpful. Let's try to keep long posts off this board and use questions and suggestions more. Even mine above which is a repost probably should be on suggestions(I think it identifies a key component of compression but could be wrong). If you haven't downloaded Drmn4ea's latest poker go to Links and get it. 12-09-2004 22:24:22

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile Scribble: The file http://bentfork.gomen.org/CVSpv2/blacktowhite_anger.zip contains a full USB dump of the black-to-white image. The uncompressed file is 3,100,000 bytes long, which is about as much as I can pull out of the camera. I can pull out a specific section if you like, but all of the uncompressed images seem to start at 0x0E0000 and end at 0x1EFB00 on my CVS. Vinegar? When you can get poutine you dont need vinegar... but you have the right idea. 12-09-2004 22:40:45

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile More progress. I think I found an authentication function -- it compares the sent packet with some stuff in memory. If it matches, I think we'll get further. If it doesn't match, the code erases both buffers & returns a new error code (which I'm seeing). Well, the investigation continues to see exactly which 1024 bits it is expecting. It may be some sort of crypto key. 12-10-2004 00:31:28

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile Finals are over, a little bit of progress on interpolation. I've been looking at different methods, so I'll probably attempt to implement a decent one sometime in the near future. For now, plain old bilinear. It's better than what I had before. I'll probably post the source and an executable soon- I'm not sure how soon though. http://www.boodle.info/dakotastop_bilin.zip http://www.boodle.info/dakotacad_bilin.zip 12-10-2004 01:14:33

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I was googling the data that I got back from the $80 command and got some interesting hits. A large number of bytes matched & it may be some sort of tcpip packet that needs to be sent to puredigital to authenticate the camera. Anyone care to research this further? And why is that data sequence in a PIC, a russian hacker site, and other places? It's not that google is good at searching - I only specified a few bytes and it matched many more. 12-10-2004 11:36:36

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email googled 29 23 --------b7 47 found sowbug.org VS.nets Leak Detector found ICEPIC in circuit emulator 90 page pdf ..... I haven't looked at it yet 12-10-2004 12:45:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Please read toml's suggestion on 12/7. Again everyone should read every thread. And everyone should try to respond in every thread, striving to keep this one short. If you think you have a discovery post a brief explanation here and further details in suggestions thread. His camera and others too have reported a LaMSSMaL id which may allow the $54 command to read flash files. I will be adding more detail shortly in suggestions. 12-10-2004 16:24:23

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile "29 23 BE 84" comes up a few times as a PPP magic number used to detect loopback conditions (is *supposed* to be random), but that isn't a PPP packet. Still smells networky though (seeing hunks of this data in Ethereal dumps in the google results). Off to snag some RFCs... 12-10-2004 16:38:31

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile I can reliably delete all the images off my CVS 6510 camera. ( more info in the CVS thread ) It turns out that sending the command 0x80 as a bulk out followed by a bulk read causes all previously stored undeletable images to disappear. The last image taken image is still present, even if it was deleted, and can be deleted again by pressing the delete button. 12-10-2004 17:16:33

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Sorry, my smeller might be acting up today. Now I'm starting to catch a whiff of a "standard" random number table (if there is such a thing)? Plugging in a few different blocks of that table... It's a random number example for a VNC server implementation. http://216.239.39.104/search?q=cache:vyJnZmp3adsJ:www.keyfocus.net/kfsensor/help/Manual/scr_EditSimVNC.php+%22f1+bb+e9+eb%22&hl=en It's the random cookie in an example of ISAKMP. http://msgs.securepoint.com/cgi-bin/get/linux-ipsec-0201/230.html It's a random PPP magic number example. http://www.netfor2.com/ppp.htm I wish I had a C compiler in front of me right now; I'd like to see what an unseeded (by not giving a damn, or by mistake, or..) rand() looks like. 12-10-2004 18:02:43

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Too many coincidences � it has to be JPEG! Are you ready, sit back and enjoy some factorization: allblack compressed image has 52187 repetitions of 9 bit pattern. 52164 + 23 = 52187 =(23*2269) 23 I can't explain - Who sang I that? Who?). The same repeating 9 bit pattern can be seen in all whites. I created an all white and all black 1288 by 864 image in Raw Photodesk and saved in jpg format. They both had 4347 repetitions of A2 8A 28. Now 4347*3*3 = 52164 same as above. If we have 8*8 blocks then 1288/8 = 161 and 864/8 = 108 and 161*108*3 =52164. Now forget about a 9 bit pattern, it makes more sense to think of it as a repeating group of 9 bytes. If you can see that the camera image has three times as much data per block then please take over from here and create some headers for us all. You do not want me going crazy again this time creating a battling trio talking to me, myself and I while quoting from Eminem, Do you? "I Tell myself that I'm doing alright Nothing else to do tongiht but To go Crazy, Crazy On You Lemme go Crazy, Crazy on you" A final note storing three times as much data per 8x8 block may have something to do with 500 times dynamic range! 12-10-2004 18:51:57

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Well its, not a suggestion, not a question, but encouraging news. I just bought 2 more Red CVS cameras. I used the $5 coupon mike posted and another $5 coupon from a stack at the store they put in with developed photos. They were putting up a "digital kit" consisting of a large sign picturing the CVS Red, a table, a tv, and a 2 hour video featuring the new digital camera! The Ritz 6410s will be dwarfed (maybe even obsoleted) by large quantities of 6520s! When my cable was working it seemed to have different memory offsets. Could someone post a link to their site with new layouts for CVS 6520s on Links (bentfork?). 12-10-2004 20:04:10

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile I got a different return code. This one is $B9. It is in responce to a write after a $80 command. While writing I noticed that you can zero out a LOT of memory. I wrote up to $E000 before I chickened out. You can verify the data written by doing a read after writing. (Dont forget to read the status command back first) I also figured out when the 3-tone descending beep occurs. It looks like mike wrote about the beeps and pictures deleting first. After sending a $80 command one image is deleted, and the camera is in a error state on startup ( 3 beeps, shutdown ). For each $80 command the next time you power up the camer it will beep thrice, then shutdown. After clearing its errors (?) it works as normal, with the image count going back to normal. 12-10-2004 22:43:04

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Playing with morcheeba's new $80 cmd on my Ritz PV2 red, firmware 6410. If I send it, requesting $80 bytes back, I receive 67 45 23 01 followed by all 00s; mike and bentfork reported the same. (Request more bytes, get the same as above + the same SDRAM contents we know and love.) Note, playing with USB and the mystery buttons I somehow 'reset' this camera's ID a long time ago (LAMSSMAL0000); I don't know if that makes a difference (but I'm not getting the table of numbers morcheeba got). Status response is 00. Here things get more interesting. I changed the command to a write, sent the 31-byte command followed by the poker readme.txt file (just wanted some junk data for testing, and that certainly fits the bill!) with the length bytes in the cmd set appropriately. Read back the 13-byte status packet, status was $b9. (Subsequent sends without replugging still go through, but return the familiar $64.) As long as protocol is followed (writes: cmd followed by the data length specified followed by a read of the CSW packet; reads: cmd followed by read of (length requested + CSW, if request is maxed, read the endpoint again to get those last 13 bytes)) it's letting me read and write as much as I want without replugging. Followed the $80 write with an SDRAM dump and got the entire file contents back at the beginning of the dump. Memory clobber! 12-10-2004 22:55:13

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile One more oddity with return codes for command $80. This time I got a $61. It seems that if the $80 command packet is less than 31 bytes long you get the new return code. The really intersting thing is it only happens the first time you use the $80 command. As for the number $67 45 23 01 it is almost the same as typing 76543210, except you start at 6 add 1 (7) subtract 3 (4) add 1 (5) and so on. It really looks like someone trying to make a 'strong' xor hash or something. 12-11-2004 00:56:52

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile The return code seems to be (from poking through the firmware) an initialization/authentication failure. Looks like the procedure is to read $80 bytes from command $80, and then somehow write the correct $80 byte password back. If what you wrote isn't what the camera expects, the function will zero out memory 140000-140100 (the first $100 bytes we've been getting back through the 'normal' buffer overflow method) and return the $b9 we're seeing. 12-11-2004 01:47:48

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile This belongs on suggestions, but sense the sequence 67 45 23 01 is mentioned three times above I am placing it here. I think all your seeing is big endian to little endian flip flops. No fancy formula just 01 23 45 67 stored as little endian. That may be the origin of LaMS also. So - when trying $54 with filenames you may need to do the same flip flop. morcheeba, please clarify and give us an updated status on your progress. 12-11-2004 02:06:06

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile It just occured to me that on a reset camera with LaMSSMaL id the password might just be 01 23 45 67. 12-11-2004 02:22:47

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Good Morning All (Good Afternoon Tea Overseas), Has everyone put me on ignore? Well OK, I'll stop quoting and stay stocking stuffer serious - there is little time remaining. The first post listed on this thread began with 4 tasks, we have made very great progress on first 3. I had hoped for more comparisons of a SMaL vs nonSMaL camera for number 4. I think there is an additional range on my 2 Cadillac pictures (thanks boodle for SMaL one) � I can see grass and individual cement blocks in the shadow of of boodle's SMaL Cadillac but it is totally black on nonSMaL image. Maybe scribble could take a window shot when it is sunny (I�ll post for you scribble), or bentfork could shine a very bright light on his white to black. Or someone could stand for 2 hours at CVS watching video promotion and report back here. Has anyone tried to apply a JPEG header yet? I was wrong about 3 times greater size being due to extended dynamic. I think it is related to camera NOT debayering before compression (wrong again). That would then create 3 times has many color combinations per 8x8 block (24 bit pixel with just red, one with just green, and one with just blue). Saving a same size all black and all white with Raw Photodesk of course used a nonbayered image with all pixels being identical in each block. If the industry is watching - we do not want any Grinches - nor do you. I suggest a simple solution rather than pulling from the shelves would be to add a cable, increase price, charge a little more to make CDs, and return cameras to rightful owners upon completion. Many will not want to bother making a cable that breaks, downloading several software packages (a libusb driver, a debayer routine, a photo enhancer ...) when a superior method exits at the corner drug store. 12-11-2004 07:38:16

RE:Discoveries - 1 2 many 4 all (modified 1 times) Drmn4ea Profile Extracting FIRMWARE.BIN from a Ritz Red (tested on 6410) over USB: Find mystery button SW1 and short it (or hold it down, if you have attached an actual button there). Put batteries in the camera, turn it on, wait for "Camrea Ready", then turn it off. Plug in USB (with the button still shorted / held down this entire time), claim the interface (you can release the button after this) and perform the usual overflow dump. FIRMWARE.BIN goes from the beginning of the dump to position $01F1FF. Note, this is not perfect; and the firmware received appears to have varying numbers of (different every time) corrupt bytes (randomish distribution, but on the order of 1 bogus nibble per 1500 bytes?). Maybe a program to take, say, 5 discrete dumps and take the "majority vote" for each byte would be helpful here. It appears only the high OR low nibble of a byte will be corrupt. Also, a lot of the actual firmware.bin (mainly the slack space at the end of each 'block', plus a few smaller places) is 0x30, but these spots are largely initialized to other data in the dump gotten by this method (guessing the 303030 is a placeholder for scratch area in RAM) - see morcheeba's firmware overview for more on the organization of it, and where the blocks of runtime-initialized stuff is (the firmware itself can't be distributed, for obvious legal reasons). Also - it looks like this isn't any good for the CVS cam; in the one I cracked open (three-finger stats in the CVS thread), the board has been re-laid-out somewhat and SW1 is gone. Luckily, it looks like the relayout makes it easier to "lobotomize" the camera; the flash WP\ pin has an easily-accessible trace coming out of it. (Want to do this before I accidentally LAMSSMAL0000 this one too) 12-11-2004 15:11:11

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile @Drmn4ea Wow! I tried this with my CVS (6510) and it seems to work. It has the unpopulated sw1. I noticed that when the USB cable is plugged in I heard only one beep not two. 12-11-2004 15:58:08

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Can you write it back? With a small change to an unused constant? 12-11-2004 16:09:59

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile The $80 read on my virgin CVS (firmware 6520) is byte-for-byte identical to morcheeba's. Guessing it's not a key block... (Or if it is, big "whoops!") 12-11-2004 18:18:22

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email CVS new Blue constant shorting sw 1 with camera off then plugging into USB causes camera to be 0DCA - 002F This Blue is Normally 0DCA - 0028 the dump $80 len 300000 did not appear to be firmware 12-11-2004 19:27:35

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile New download available for those with an SW1: "Filedata Finagler" Given three or more files containing possibly-corrupted copies of the same data, returns a file containing the best guess of the true data by byte-wise "popular vote". 12-11-2004 23:21:53

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile @mike - if you didn't already do so, with the button shorted, make sure to turn the camera ON (with batteries) until "Ready", then off again, then quickly plug into USB and claim the interface without releasing SW1 OR losing battery power. I think this is the critical step; on mine, plugging it in from being unpowered for a while returns what appears to be uninitialized memory (garbage). I haven't seen the CVS Blue firmware, but the Ritz Red starts with [E4 F1 E5 0D ...] and contains the strings LaMS / SMaL and references to filenames (FIRMWARE.BIN, and the .TFT and .DAT files). It would be great if this works on the Blue CVS, but it may not. 12-11-2004 23:41:18

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Great job, Drmn4ea! I think finding a secret test mode will be very helpful in the future. Is there any chance that the signal for button 1 goes to the connector? You may have found a procedure normally used at recycling. I've got some news of my own... I figured out the authentication mechanism / secret handshake and found the command to read the flash memory. I was able to retrieve my compressed pictures and a copy of FIRMWARE.BIN without opening the camera. Due to the method used, this won't work for all cameras -- see my link for more info. It seems the image decompression algorithm is the next thing necessary to make this camera interoperate with their owners' computers. 12-12-2004 03:49:56

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Closer on Decompression? I created a raw 1288x864 byte file of just zeros (like Drmn4ea's cut line black). I forget exactly how but think I loaded a large file into XVI32 stripped it to that size and saved it as black.raw, then opened it again and copy and pasted 2 more copyies to have a complete 24 bit RGB raw image of zeros. I then downloaded icae1: http://www.ggcomputer.com/icae.htm . Under advanced edits this allows quick size comparisons without storing file. The best I have found are lossless jpeg using dct ifast and photometric cmyk, or tiff packbits using packbit compression and photometric cielib or rgb. You need to first enhance colors and reduce r,g,b to 0 to get rid of upper left corner unregistred message which is a real pain and may be throwing off hex comparison in final files since you can not store without the message. If anyone has a registered version they have an advantage. Use Drmnr4ea's latest cut line black (somewhere above) to compare against probably starting near $12000. 12-12-2004 08:47:32

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile I found some promising German software containing a bayer to rgb routine. There is plenty of english documentation and training. I haven't tried the demo and can't vouch for any capabilities - Are there any Germans watching who can? You will need to download the debayer tool: http://en.commonvisionblox.de/common/pages/supDownloadItem.php?Group=dldCVB_Tools and Common Vision Box manager: http://en.commonvisionblox.de/common/pages/supDownloadList.php This may help create impressive images from uncompressed raw images starting at $120000 in our cameras. I am leaving for another Holiday party, oh my head still hurts from a long one yesterday. Hope someone makes progress on the suggested software, can provide some additional images, and document the details of processing. 12-12-2004 12:25:52

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile It appears that whatever clears the ID (LAMSSMAL0000) also resets the response key to an (unknown by me) value. I tried keys of all zeros, sending back 4 permutations of the new challenge [67 45 23 01 00...] [12 34 56 78 00...] [00... 67 45 23 01] [00... 12 34 56 78], and [40 00...]; she's all $b9, $b9, $b9. Someone might have to pull the flash on one of these! (Any volunteers?) A quick hypothesis in the Questions thread... 12-12-2004 12:26:36

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Drm4ea, try [4c 61 4d 53 00 00...]. It looks like the challenge [67 45 23 01 00 00...] comes from a default NVRAM.DAT table in FIRMWARE.BIN. I that response right below it in the table, and the content-id-numbers of the two match the id numbers of the data I found in found in NVRAM.DAT. 12-12-2004 12:56:57

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile I forgot to mention, morcheeba, great work! And - the LaMS key [4c 61 4d 53 00...00] it seems to like. I actually just tried it (saw the LaMS stuff coming just after [67 45 23 10] in firmware.bin and a lightbulb came on) and came in here to spread the news when I saw you'd beat me to it :-P Now to nab some files. Anyone tried the $54 (takes a filename) cmd yet? That's going to be my next step... 12-12-2004 13:55:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile the chdir $58 command only worked for "/" and not "DCIM", so that may not be a correct interpretation. I tried cmd $54 w/o success - both on picture files (IMG_0001.RAW) and root-directory files (FIRMWARE.BIN). Still lots of experimentation to try... I want to see if I can also write to FLASH memory. 12-12-2004 14:23:29

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email The $80 read on my virgin CVS (firmware 6520) is byte-for-byte identical to morcheeba's. The $80 read on my CVS (firmware 6430) is 76 54 32 10.... 00-00 I still was able to short sw1 on this one my 6520's have no sw 1 ......and there appears to be no direct connection to edge connector from sw1....on the blue and red that have sw1. pin 2 and 4 may be used on edge connector??? Retried CVS BLUE and do get what may be firmware??????/ it also rtns 76 54 32 10 ..00---00 12-12-2004 14:38:30

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile I'm posting my debayering program. It's just a command line program, drag your memory dumps onto the program and it will output a bitmap using bilinear interpolation. Right now it's only set up for raw images located at $120000. The next version I'll post will be with a better interpolation method and more flexibility such as where the raw image is in memory and stuff like that. http://www.boodle.info/programs/raw2bmp/ If you're building it yourself, make sure you build the "release" version, as it is much much faster than the debug version. 12-12-2004 19:19:36

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Thanks boodle! I applied a *very* quick hack to the FAT12 ISO reader I wrote in the old Dakota days, for those of us with crappy OSes that can't mount ISOs as file systems. As-is it will extract all the files from the root directory of the flash image (but not subdirectories) - you can grab firmware/etc. but not pictures with it. Source is included if you want to hack that function in; if you do, please post the update here Usage: chewfat.exe flashdump.bin 12-12-2004 22:59:26

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Publicity! If you have been a major contributor (you decide), please post a brief comment and a link to your website in Links - 1 2 many 4 all. Do NOT release any news to any form of media. I am trying to coordinate a timed release with morcheeba. Any others that have opinions or want to be directly involved please express in Suggestions thread. Besides cleanup and user friendliness, the only stumbly block is decompression - let's concentrate efforts on that. I am creating a new thread for all activity (discoveries, questions, suggestions) related to Decompression - 1 2 many 4 all. 12-13-2004 08:40:38

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I found the USB command to delete individual files. The "pictures remaining" counter even automatically increments again. And the command that I thought was a read seems to be more of an "open". And I'm confident in the chdir function. I'm still trying to read an individual file, though. 12-14-2004 02:04:35

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile two new commands verified -- one makes a directory, the other takes a picture (and returns it over usb in compressed format and also stores it to flash without a thumbnail). Still no file read, nor a cure for cancer. 12-15-2004 01:54:27

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile In my last post on suggestions I promised to provide some new Autobrite� photos using new flatfotocameras form radioshack. My hands were shaking on these tiny cameras and several came out blurred, but I think my heart skipped a beat once or twice allowing a halfway decent picture. Oddly the reds look a little better than the blues (I think I left the lcd running too long on the blue � it displays a continuous picture of what ever is on the imager until you turn it off � luckily it recharges through usb). Click on pictures to see equipment information at bottom of caption. I haven�t figured out how to get the raw photos like j_tetazoo did on the SMaL VGA imager camera. When I do I am looking for suggestions on valued images � obviously an allwhite (I am not going to cut clock lines for a black hole). Feel free to openly comment on the pictures in these threads, but please do not criticize photographer for cold shaky hands. Haven�t tried 3 finger salutes but software reports the following: Blue _Red 0006 0004 Hardware 6620 4380 Firmware 0029 0015 Type Still need to try unlocked Pure Digitals with new software. They each seem to need to use their own drivers and software. Software for Blue: ArcSoft PhotoImpression� and ArcSoft PhotoBase� Link to rather crummy pictures (may be my fault): http://www.photo.net/photodb/folder?folder_id=456596 12-15-2004 21:46:52

RE:Discoveries - 1 2 many 4 all (modified 0 times) hoppsan Profile I changed boodle raw2bmp program to use the gphoto2 debayer routine. It turned out to make no differnce in quality at all, probably the same algortihm. Anyway, the blue tint definitely wasn't a bug. I also added some gamma correction using the gphoto routines to brighten up and adjust the colour. I find that if you import the result in photoshop and do an auto adjust and then increase the saturation a little you get some pretty decent pictures. http://peggus.freelinuxhost.com/dakotapv2/picture.jpg Here's the program and source, you'll have to use the debug version as the release wouldn't link and I have a headache now. http://peggus.freelinuxhost.com/dakotapv2/boodles_raw2bmp.zip 12-15-2004 22:30:42

RE:Discoveries - 1 2 many 4 all (modified 0 times) hoppsan Profile I meant auto levels, not auto adjust. 12-15-2004 22:32:21

RE:Discoveries - 1 2 many 4 all (modified 0 times) hoppsan Profile Sorry about this guys, it seems my hosting company is redirecting the links. Copy and paste the URLs and it will work. 12-15-2004 22:34:56

RE:Discoveries - 1 2 many 4 all (modified 1 times) boodle Profile Thanks hoppsan! The output looks much better. I'm working on a better de-bayering method, but I have a really annoying bug that I can't figure out. If I ever do, I'll definately include that gamma correction, that makes a big difference! I just noticed, I think you have to include a copy of the GNU Lesser General Public License with those files you included. It has the GPL but not the LGPL. 12-15-2004 22:53:31

RE:Discoveries - 1 2 many 4 all (modified 0 times) hoppsan Profile Thanks, it's been updated to include the lgpl license as well. Let me know if I can help with that bug. 12-15-2004 23:38:41

RE:Discoveries - 1 2 many 4 all (modified 0 times) hoppsan Profile I guess I was bitten by the debayering bug. Gphoto2 also contained a pattern recognition based demosaicing algorithm. I implemented it in boodles program and it does produce a lot less chroma artifacts than bilinear, but it also blurs the image quite significantly. This seems to be consistent with litterature I found on the algorithm. If anyone is interested in trying it out, it can be found at http://peggus.freelinuxhost.com/dakotapv2/boodles_raw2bmp_pattern.zip 12-16-2004 02:29:16

RE:Discoveries - 1 2 many 4 all (modified 0 times) j_tetazoo Profile dakotamod: AFAIK, you can't get the .raw files off the FlatFoto's built-in flash. You have to use an external SD card, and then pop it out and put it in a flash reader. Make sure to do this BEFORE running the "syncing" the camera to the desktop. Failing to do so will result in the .raw files being replaced by .jpgs! 12-16-2004 10:23:50

RE:Discoveries - 1 2 many 4 all (modified 0 times) tapostrophemo Profile I broke down and took the camera in to CVS today to get the pictures "developed". The quality of the prints isn't great, but I wasn't expecting that (from such a cheap camera nor from the corner drugstore) anyway. That said, the contents of the accompanying CD are *very interesting*. One item, for example, is that the pictures they "give you" are 1800x1200 pixel jpg's (see http://www.geocities.com/tapostrophemo/camera/dash.jpg). However, I'm not sure if according to the EULA I can upload the most interesting files. So, and this should probably belong in the "Questions" thread, are there any lawyers in the house that are willing to tell us whether the EULA lets me discuss the "juicy bits" from my "PhotoCD"? Of course, up to this point I have always "disagreed" (not accepted the EULA), and thus have not used the "Software". But, are some of the what appear to be data files, and also what appear to be "interesting files" for purposes of this discussion thread, considered part of the "Software"? Finally, what say all of you regarding whether knowing what the processed images look like affects the "clean room" status of the "project"? --- For those who are interested in reviewing the EULA: - http://www.geocities.com/tapostrophemo/camera/eula-1.png - http://www.geocities.com/tapostrophemo/camera/eula-2.png - http://www.geocities.com/tapostrophemo/camera/eula-3.png - http://www.geocities.com/tapostrophemo/camera/eula-4.png - http://www.geocities.com/tapostrophemo/camera/eula-5.png - http://www.geocities.com/tapostrophemo/camera/eula-6.png - http://www.geocities.com/tapostrophemo/camera/eula-7.png - http://www.geocities.com/tapostrophemo/camera/eula-8.png - http://www.geocities.com/tapostrophemo/camera/eula-9.png (Sorry they're all cropped images from screenshots; I couldn't find a eula-esque text file.) 12-16-2004 23:42:32

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile j_tetazoo, dakotamod has been quarantined by daBass. I have no SD cards nor a flash reader. If compression remains unsolved too long I will obtain both. I am hoping that others with Blue FlatFotos will join our efforts. tapostrophemo, very interesting questions. I think you can discuss what you see as long as you are not reproducing a copy of it; they are your photos and you own the copyright. My compressed stop sign, a bayered version, an interpolated image, and just recently an imaged processed using software that came with my FlatFoto have already violated "clean room" if your worries are justified. There do not appear to be any legal lurkers, so for now we need to rely on morcheeba's opinion (he seems to have done the most research in this area, hope he can offer some advice). Exceeded data transfer rates are blocking your recent links. Please follow daBass's lead and setup a Legal - 1 2 many 4 all thread (dakotamod has happily retired). I suspect the biggest hurdle would be a patent that covers applying Autobrite to an image (we still are in the dark on this) as it could prevent completion of this project. 12-17-2004 00:31:26

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile @t'mo - does the photo CD come with some kind of .EXE photo viewing software, photo browser, image editing program etc.? I'm certain that's what the EULA is intended for - Sam's Club photo CDs have the same thing, all the pictures are just .jpg files and thumbnails in a directory, but the CD autorun points to the installer for a photo-browser executable in the root directory of the CD. I'm not a lawyer, obviously, but see "no way in hell" that the .jpg's on the CD would be restricted in any way (after all, you're the copyright holder). (Aside from the author of the license not knowing how to spell 'tortious', it looks like a pretty standard software license) 12-17-2004 08:37:59

RE:Discoveries - 1 2 many 4 all (modified 0 times) bentfork Profile t'mo Thanks for the photo! the Exif data is interesting. It looks like the cameras serial number is in there, did you get a chance to write that down before you processed it? *** Filename : dash.jpg JFIF_APP1 : Exif Main Information Make : Pure Digital Technologies Model : legends | LAMSSMAL0000 Software : 2_7_CVS_RC7 (server #104) | ip=V2.7 delivery 08/03/04 Unknown Information ExifInfoOffset : 178 SelfTimerMode : 0 Sub Information DateTimeOriginal : yyyy:mm:dd hh:mm:ss Flash : Fired UserComment : GretagD4M.CDOnly In the unknown section there is something a little 1984 ish. Why would they want to know if it was a self timer shot? *** I've obscured some info in the above dump. The serial is now the default serial, I changed the timestamp. 12-17-2004 12:52:09

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile Alright, a couple discoveries-I have to organize all the steps I did. I have set my challenge/response keys to somehow read from firmware instead of nvram (it's now 67 45 23 01 00 00 ... challenge and 4c 61 4d 53 00 00 .. response). I am also downloading pictures from the camera through TWAIN using The GIMP. However, there are a couple problems, and I still have to find out what the commands are that are sent over USB. It turns out the program I tried was only reading 32 commands, and only the first 8 bytes of every command...so that's pretty useless. I'll post more, including some pictures when I figure out what I did. Thanks go to brite_eye, he figured out how to do most of this. 12-17-2004 14:55:16

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile Not a discovery, but a follow up to my last post...I managed to kill my laptop. In the process of installing usb sniffers, I think I installed a bad one, maybe it wasn't fully compatible with windows XP or something. It won't boot anymore, even to safe mode. Anyway, I'm going to try to get this up and running on another computer, but it's at least slowed me down a little. Hopefully I'll have some more information later. 12-17-2004 15:27:00

RE:Discoveries - 1 2 many 4 all (modified 0 times) tapostrophemo Profile >Exceeded data transfer rates are blocking your recent links That may actually be that yahoo/geocities don't like direct, external links to images. To (hopefully) correct the situation, here are some links to new HTML pages: http://www.geocities.com/tapostrophemo/camera/eula.html http://www.geocities.com/tapostrophemo/camera/dash.html And here are a few more observations that I feel I can discuss at this point: 1. Yes, there is an *.exe on the CD; this is what the EULA refers to. From the accompanying readme.txt - "The Photo CD application on this disk will allow you to view, email, print, and save your pictures." 2. The sample picture I posted came from a directory named "Pictures" at the top level. (BTW - I renamed the file from photo001.jpg to dash.jpg.) However, due to the directory structure on the CD, my guess is that the *.exe doesn't actually reads those files. There is another folder named "PD" (PureDigital), which contains, among other things, what appear to be data files. This is where the most interesting files are, and the ones I'm not sure if I'm able to discuss. 3. Despite my reservations stated in #2 above, I will mention that some of the apparent data files have image data in them (I examined them in a hex editor and also a separate image-displaying program), where the images are "my pictures". Perhaps I could argue that if they do indeed contain my image data, copyright law says that I'm the owner and can do whatever I want with them (including giving out juicy details about their content, size, and structure). In short, does the EULA covering "the Software" also cover "the data"? 4. I also examined the files in the "Pictures" directory using a hex viewer and saw some of the EXIF data. (Speaking of EXIF, did anyone else read this: http://www.joelonsoftware.com/items/2004/12/03.html ? An interesting optimization, I'd say, for anyone maintaining websites...) And yes, I had written down the serial#/firmware/etc. before taking the camera back in to be processed. Finally, a bit of humor. Who the hell did they hire as a proofreader? Gollum? From near the end of section three of the EULA: "You, not PureDigital, remain solely responsible for all Content that You uploads, posts, e-mails, transmits..." 12-17-2004 23:19:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) boodle Profile I was just looking at my NVRAM.DAT and realized that whatever happened to my camera, the challenge/response keys in NVRAM.DAT were changed to the ones in firmware. Before I had just assumed that it was checking the version in firmware instead of NVRAM.DAT. Here is the order of things (or as close as I can remember) that I did between when the challenge/response was normal and when it changed: Installed the radioshack drivers for the 1.3 flatfoto plugged in the camera, unlocked it with usbpoker (with the 1.3 drivers, not libusb drivers), tried to extract pictures using the twain driver. I think I then tried to go to "configuration" in the menu on the driver, or options or something. I'm pretty sure whenever I tried to click the configuration it froze. Could this have something to do with it? unplugged it, plugged it in, tried without unlocking, maybe tried configuration again switched drivers to the foxz2 driver, tried to unlock with usbpoker, but I think usbpoker froze. Unplugged it, plugged it in, tried running the twain driver without unlocking. It didn't like that. Used "update driver" and updated to libusb 0.1.8.0, tried to unlock it. It wouldn't unlock and I checked the key it had given to me and it was the 67 45 23 01 with 00's after. So I sent the 4c 61 4d 53 with 00's after it and it unlocked. (I just realized today that 4c 61 4d 53 was LaMS...) Somehow I have managed to mess up either the camera or the driver. Now after I unlock it and try the twain driver it says that it isn't permitted in boot loader mode. I have a feeling it's a problem with the driver, because I can get .raw files by using usbpoker with command $54. 12-20-2004 21:00:15

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I've got a new version of my disassembler. A minor fix to how disv8 handles variable names and banks, plus lots more comments! earlier version: disassembly = 54k lines, 2.4MB, FIRMWARE.COMMENTS = 3102 lines, 122KB (from about november) this version: disassembly = 55k lines, 2.5MB, FIRMWARE.COMMENTS = 4635 lines, 182KB I found a routine (L81A3C) that has both the address of the compressed image and the uncompressed image, so I assume it does something. It also seems to have two nested for loops: for v=0 to VERT_SIZE for h=0 to HOR_SIZE/4 I had to stop looking at it because my head spun. There are some hardware registers accessed, but I can't tell how much work is being done in software vs. hardware. (those accesses could be just getting data from SDRAM). I found where LANG-EN.DAT gets loaded (memory map updated), and then found where the two-finger-salute stuff gets printed -- (only 2 fingers are actually needed - shutter+display). It should be easy to find out where the other text gets printed, but I was lazy I also found the registers that read the buttons (and mapped which is which), and successfully wrote to the FLASH memory. 12-21-2004 03:48:55

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile Since no one appears to be working on Applications #5 (writing new firmware), I decided to try stripping firmware off my camera (brite_eye's done some stripping too tonight). Trying to follow standard poking procedure (brite_eye wasn't following any standard poking when I left), I began getkey, read 141, sendkey, read 13 - and immediately said $#!t realizing I screwed sequence (brite_eye's getting screwed) and would have to unplug, close and start again. But wait, I am thinking maybe this was magic stupidity for resetting to LaMSSMaL - so then being stupid again I getkey, read 141, error and $#!t again. Why did I bother with the extra steps, now I don't know if all are necessary. How to Reset your Camera to LaMSSMAL: 1. getkey, read 141 2. sendkey, read 13 (note this should come after bulkout of key.bin instead of now) 3. no response or error - dont remember 4. close it (poker button), close window, USBPoker.exe, open it (note all without unplugging) 5. getkey, read 141, error which I should have expected - once an error always an error until unplugged and replugged. Bingo! Bango!!! (quoting Micky Redmond and missing Red Wing hockey) after unplugging my Red CVS and using Vulcan nerve pinch: HARDWARE 6520 FIRMWARE 06 TYPEID 2B CMP TYPEID 2B ID LaMSSMaL0000 REALM ID 00 Thanks for your support on Annoying thread Drmn4ea, which is where sidetracks should be (but sometimes we just can't resist exposing 4 all). 12-22-2004 03:36:19

RE:Discoveries - 1 2 many 4 all (modified 0 times) dakotamod Profile I picked up an SD card reader ($9 key chain style) and a 256M SD card for my FlatFotos. Seems most of my discoveries are more accidental then intentional. I previously had installed Blue FlatFoto drivers and was now trying to download images for Red FlatFoto using Blue drivers. While it worked the pictures were ugly! So I now believe there is a lack of downward compatibility - pictures were much better when I installed Red 1.3 drivers. Corollary: Foxz2 is a bad idea for 1.3 Ritz and CVS. I'll bet your ugly greens and blues fade away if you download and use Foxz drivers instead of Foxz2. Does anyone know a utility that cleans out unwanted drivers? Back to my original intent - 256M SD card. I can snap snap snap and snap again with this card. I wonder if I circled around an object taking several shots, then fed into an animator if I could get some amateur Matrix effects. I had thought that camera would write jpg files to external card - WRONG again, they do not get written until you hook it up to PC and download converting raws to jpgs. What good is that, once I have jpgs on computer I do not need to take card out plug it into a reader and access files directly. 12-22-2004 21:50:46

RE:Discoveries - 1 2 many 4 all (modified 0 times) ForkBoy Profile Morcheeba, Could you please give an example of how you successully wrote to Flash Memory? Was this by sending a USB command, modifying the firmware, or other? Thank you! 12-23-2004 13:16:14

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Here's some christmas-day fun you can have when you modify LANG-EN.DAT. Since this worked, any of the TFTs should also work... but next I'll try FIRMWARE.BIN and see if it uses a checksum. 12-26-2004 04:11:27

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile Argh! Frustrating how morcheeba wets our appetite with juicy tidbits, but does not provide details. However, it is clear that compared to us mere mortals morcheeba is most likely going to provide a final firmware solution; and IMHO should not bother taking time for details, but rather move on with checking firmware checksum. 12-26-2004 05:12:58

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email I have tried cvs-blue and cvs-red with flatfoto blue driver ...and so far have not had any success after unlock It looks like the driver [my-computer..right click driver -- get photos ]requests the configuration ....and apparently does not like 27/28..... all I see in usb dump after unlock then issue get photo are low level cmds get config 80 06 00 01 00 00 12 00 get configuration of 18 bytes then somtimes issue/reissue "LaMS xx 00 00 00 04 00 00 00 80 00 00 5E 00 1c 00 00 00 --- 00" thes 4 bytes seem to be important.. then bulkin read status I get 00 00 00 00 on cvs blue and 64 status....camera contains some photos I get 40 00 00 00 on cvs Red and 64 status...camera contains some photos 12-26-2004 07:33:11

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile mike, Please provide a phone number and a time to call in response to one of my emails. I will phone you from my cell (unlimited nights and weekends). We need to get your photos out. 12-26-2004 08:41:04

RE:Discoveries - 1 2 many 4 all (modified 0 times) ForkBoy Profile For anyone who has had success with using Windows drivers please provide the driver details. This can be done by taking the following steps: (1) Go to the device manager (2) Find the Camera Driver in the list and double click on it (3) Click on the driver tab (second tab) (4) Click the driver details button (5) For each driver in the list, PLEASE post the following: A. The driver file name B. The provider C. The file version If we can get a working set of drivers this will allow myself and others to reverse-engineer what is happening by disassembling and tracing the code. * I can't do this until I have a working set of drivers for my CVS Red: FIRMWARE 6520, HARDWARE 06, TYPEID 30, CMP TYPEID 30, ID LAMSSMAL0000, REALM ID 00 If anyone wants to email me the Flatofoto Blue drivers I'd love to take a look at them (forkboy at verizon.net) And Morcheeba, please be a sport and provide us with some details on how to write to the flash - I'd be happy to write an app for people to tweak their .tft screens. You can have full credit for it, have the source, post it on your site, whatever. After all without you we would be nowhere 12-26-2004 09:39:24

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile ForkBoy, Please send me an email or provide your phone number. I have few ideas to discuss directly with you. You can obain my email be requesting it after signing up for a free membership on photo.net. 12-26-2004 10:31:43

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Writing to flash is pretty simple --It's been up on my webpage since I discovered it. Basically, it's the opposite of reading. Use command $52, LUN=1 (FLASH), set the block address, length=512, and set flags to $00. You should experiment with the FLASH read (flags = $80) first to make sure you know where you're writing. I first experimented on an unused block near the top of memory. Forkboy - a TFT editor would be useful - and the credit for it can be all yours. I was thinking simple command-line TGA2TFT, but Are you thinking paint-brush clone that's aware of the bayer pattern? 12-26-2004 12:16:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) ForkBoy Profile morcheeba, Thank you for verifying this - It is how I thought it should work, but without verification, I didn't want to spend to much time on it. Yes, an easy to use "paintbrush" type .tft editor would be fun. I'll need to dive back into the other bayer code out there for this, but I think this should be something I care take care of. I would also like to combine the USB util with a "file" explorer of sorts to read and write to the flash file system at will. This will require some FAT code to make things get written to the correct place. What fun are .TFT images without being on the camera? 12-26-2004 12:33:47

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile Please consider using applications thread for any discussions, questions, discoveries, suggestions ... on what I hope will become our final set of applications. 12-26-2004 12:43:10

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Ok, I took the plunge and modified FIRMWARE.BIN. My first mod was to swap two TFT images -- instead of displaying the camera instructions at startup, the self-timer instructions were shown. (and vice-versa, holding the display button down showed the camera instructions). That worked!! It was a simple swap of two bytes in the same block. Then, I tried a slightly more sophisticated mod: instead of swapping, I tried to set both images to the same thing (either case would display the self-timer instructions). This killed the camera -- When powering on or connecting the USB, I get two closely-spaced beeps of the same tone (sounds like a one-second beep with a slight stutter). So, it looks like there is a checksum, but it's really simple (not position-dependent) or I got lucky. So, that leaves me two leads... one is to explore what the camera does now (can I reprogram it through the bootloader, for which I have no code?). The other option is to see if I can find the checksum in the file. I suspect it is at the end, and now I know it isn't position-dependent, I can see if I can replicate it. 12-26-2004 14:52:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email ForkBoy... Why not add some simple script support for issueing cmds chk status etc to aid in tracing etc...... 12-26-2004 14:57:28

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile update... camera responds to USB after messing up checksum on FIRMWARE.BIN - it's the same Product/Vendor ID, but I think the pipes are different. I'll have to stick on my linux box and cat /proc/whatever to get more details. 12-26-2004 15:41:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Enters official 'failsafe' bootloader mode from ASIC? This will be fun to explore.. (The Foxz1/2 Windows drivers have mentions in them of detecting corrupted firmware, and loading new firmware onto the camera... could it be as simple as corrupting the firmware checksum, and letting the Windows driver of choice re-load it from the exe / .pack file?) 12-26-2004 22:42:34

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Found a command that allows you to put anything on the screen!! It waits for the user to press a button, though, so it isn't so helpful as a constantly-updating status screen. There are some beeps that happen, too. Basically, command $5d, byte17=0E, length=$10000, flag=$00 (write), LUN=1. Send the command with 31 bytes. Then send packets of 512 bytes each until you've sent 64k of picture data. Whalah! You can also do a read of $00 bytes to get it to display whatever happens to be in memory @ $140000 (which will probably be junk) I think I figured out the FIRMWARE.BIN checksum, too, but I've been just double-checking some commands to see if I can somehow read the bootloader from the ASIC to verify my guess before I fry another camera. 12-27-2004 01:45:09

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile morcheeba, no point in you frying all your cameras; I am willing to fry a CVS Blue 28, If you can provide a test sequence first (the blue seems to have different offsets and firmware). I suggest you fry a bunch of blues they are half the price. 12-27-2004 02:13:23

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email brite_eye if you have a repeatable sequence you need to trace the usb commands if you can.... incase needed for later use.. the best I found is usbmonitor by HHD software ,,, you can get 14 day trial a capture in complete mode will generate a very very large html file..100meg+ which can be xported as text file[html very slow] you can also use usbsnoop and get a soso trace.... I will try the sequence you posted....I have only been useing the filterdriver{libusb) 12-27-2004 07:46:36

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile brite_eye - I've got the flash programmer, so it's not much of a loss. It's a pain to solder in, but I'm sure I could recover the camera. 12-27-2004 13:07:50

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email smallsuccess....followed brite_eyes post was able to download 2 images...... I am using Win XP2 the driver switching is hokie....when chez is loaded driver shows up under imaging ....when libusb is loaded the driver shows up under usb stuff... NOTE!!!! when changing from chez-fox to libusb the fox name shows up under usb stuff but apparently is libusb,,,the name does not get changed sometimes... ...also photobase grabbed these 2 images before I could load ifranview...... when I get the sequence down better I will try to get a usb trace ....got 10 days left on another pc..... 12-27-2004 19:18:45

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile I modified a byte of FIRMWARE.BIN and the checksum is accepted!! Thanks to bartoni who pointed out the proper range of byte to checksum. I then found a second similar checksum. details here. The tool I'm writing is still pretty crude & it's easy to destroy a camera. 12-30-2004 01:58:30

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile More FIRMWARE.BIN modification. This time I changed one of the commands to simply read back a local 16-bit processor address. Finally I can see what's in the memory map between the code ($4000) and registers ($F000). I was hoping to find the bootloader code, but no such luck -- it's just a repeat of the code at $0-$3FFF. There is a little insight into the registers at the top of memory, but not much. updated page. There must be a bank switch that swaps out the bootloader, or maybe it was loaded at $1000-$3FFF and overwritten by the first bank switch. 12-31-2004 02:10:22

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile It's taken me a while to put this up (I'm working hard on a 2-week trip), but on December 31st I changed the firmware in my camera so it would be automatically recognized by the Foxz2 driver. Once modified, it works perfectly with a non-modified driver installation. Only the 6410 version firmware is currently supported, and ones that haven't been changed to LaMSSMaL0000 -- but it would be easy to change it to support LaMSSMaL0000. If you have different firmware in your camera, you can probably make the necessary changes, too. Currently the tool is mac-only, but it should be easy to port. I've got a new summary page describing the camera & what it's capable of, and I've got a page describing my mod tool. Note, this modtool isn't like a modchip you'd install on an xbox. It will not allow you to play pirated games -- it will only let you get your pictures out of the camera easier, or add your own changes to the existing firmware. The summary sheet has a timeline of major accomplishments - I'm amazed at all the steps everyone has contributed & wanted to show our story. I know it's flawed and missing important info; I'd appreciate any improvements. There are names on it, but I just want to make it easier for people to search through this BBS... I don't want it to be a scorecard of sorts. 01-06-2005 18:59:40

RE:Discoveries - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Morcheeba, sweet! I finally posted the results of probing the signal lines into the CMOS imager. This still needs a lot of work, but at least identifies some clock and likely parallel data lines. Free pizza to the first person successfully interface their own microprocessor to the imager and document it. 01-08-2005 04:08:04

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Looking at Morcheeba's modfile's 6410 remove $80 and change Pid Looks like.....Others verify please..... Firmware.bin Morcheeba 6410 CVS_Blue = 6430 CVS_Red = 6520 $80 change ABS Addr> 6912 = e0 01 ABS Addr> 68F8 = e0 01 ABs Addr> 690f = e0 01 6914 = c8 21 0f 68fa = c8 f5 0e 6911 = c8 f5 0e 6917 = b9 68fd = b9 6914 = b9 change 6913 = 02 68f9 = 02 6910 = 02 CS 1f1ef old = CS 1f1ef old = CS 1f1ef old = 49 DA new = new = new = 4A DA CS 3ffe old = CS 3ffe old = CS 3ffe old = 84 67 new = new = new = 84 67 Pid byte 6af7 = 27 [Not understand this 6add = 27] 6af4 = 27 [ see no ref 0dca 0028 ] need look more.. Morcheeba... do we need to change the CS @ 3ffe ?????? I'm unclear about this....... Forkboy...how about addin mod to pvtool to be able to select 3 buffers to write ...lower cs block, changed block, upper cs block ...I can hand patch the blocks... 01-08-2005 08:10:05

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Looking at Morcheeba's modfile's 6410 remove $80 and change Pid Looks like.....Others verify please verify Firmware.bin Morcheeba 6410 $80 change ABS Addr> 6912 = e0 01 6914 = c8 21 0f 6917 = b9 change 6913 = 02 CS 1f1ef old = new = CS 3ffe old = new = Pid byte 6af7 = 27 Firmware.bin CVS_Blue = 6430 $80 change ABS Addr> 68F8 = e0 01 68fa = c8 f5 0e 68fd = b9 68f9 = 02 CS 1f1ef old = new = CS 3ffe old = new = Pid byte [Not understand this 6add = 27] [ see no ref 0dca 0028 ] need look more.. Firmware.bin CVS_Red = 6520 $80 change ABs Addr> 690f = e0 01 6911 = c8 f5 0e 6914 = b9 6910 = 02 CS 1f1ef old = 49 DA new = 4A DA CS 3ffe old = 84 67 new = 84 67 Pid byte 6af4 = 27 Morcheeba... do we need to change the CS @ 3ffe ?????? I'm unclear about this....... Forkboy...how about addin mod to pvtool to be able to select 3 buffers to write ...lower cs block, changed block, upper cs block ...I can hand patch the blocks... 01-08-2005 08:22:33

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Brite_eye your right I semi trashed my CVS blue.... Somehow my firmware version has changed/updated?? from 6430 to 6520 which is probably bastarized... cs 1f1ef=05 1f cs _3ffe=AD b4 the 6430 cs 1f1ef = fb 3c and 3ffe = c2 e0 I can still take pics and download with flat drvrs. this apparently has occured between 1/6 and 1/8...and I was only playing with drivers... 01-08-2005 09:54:35

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Mike, right on! The $80 mod looks good - I don't have your firmware, so I can't tell for sure, but there is only one pattern like that in that memory area. And the new address that it stores the flag to ($0ef5) is in the same bank as in the 6410 (just under $1000). I should have given more context for the USB PID. Try looking for the text below: 13aa7: 04 03 09 04 1e 03 44 00 69 00 67 00 69 00 74 00 | D i g i t | 13ab7: 61 00 6c 00 20 00 43 00 61 00 6d 00 65 00 72 00 |a l C a m e r | 13ac7: 61 00 0a 03 53 00 4d 00 61 00 4c 00 06 03 4f 00 |a S M a L O | 13ad7: 4b 00 08 03 42 00 41 00 44 00 a7 3a c9 3a ab 3a |K B A D : : :| 13ae7: d3 3a d9 3a ee 00 12 01 10 01 00 00 00 40 ca 0d | : : @ | 13af7: 27 00 01 00 01 02 00 02 09 02 20 00 01 01 03 80 |' | Looks like you've got the checksum correct. My modfile has a bit of extra redundancy because I didn't want to mess up any of the checksums. If the bytes being modified <=0x3FFF, you need to modify both the upper and lower checksums (modify the lower checksum first. Then the upper checksum is modified by both the byte change and the new lower checksum). But in both cases above, the bytes being modified >=0x4000, so only the upper checksum needs modification. Looks like the delta to upper checksum you did is correct. 01-08-2005 16:53:19

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email morcheeba what will the write to flash packets look like???? ABS> 6800 BULKOUT patch 4c 61 4d 53 | 1d ba ab 1d | 00 02 00 00 | 00 01 00 52 | 00 34 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 ABS> 1F000 BULKOUT csum 4c 61 4d 53 | 1d ba ab 1d | 00 02 00 00 | 00 01 00 52 | 00 F8 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 01-08-2005 18:18:55

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile mike - looks good to me! When I did it, I double-checked the blocks with my FIRMWARE.BIN that mac os retrieved from my flash .iso file 01-09-2005 04:35:45

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email ABS> 6800 BULKOUT patch 4c 61 4d 53 | 1d ba ab 1d | 00 02 00 00 | 00 01 00 52 | 00 34 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 ABS> 1F000 BULKOUT csum 4c 61 4d 53 | 1d ba ab 1d | 00 02 00 00 | 00 01 00 52 | 00 F8 00 00 | 00 00 00 00 | 00 00 00 00 | 00 00 00 changed byte 12 to 80 [input] and tried....but was not getting firmware data????? this is on my [CVS Blue with comprimised firmware].... [the cam functions ok with pvtool and flatfoto drvr..] I tried a $26 of 1f200 bytes start blk0 and get firmware data but do not get good stat.... using anything but blk 0 gets challenge data and some firmware data and bad stat.... 01-09-2005 09:45:13

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile whoops mike, my bad!! The offset that I used is the offset into the file, not the flash memory. I had to parse through the FAT, following it cluster-by-cluster until I got to the right part on the disk. Those commands have the correct file offset, but are being used where the camera expects a flash-memory offset -- so it won't work. Feel free to copy my code (it's GPL'd), or just search the flash for the correct data (and make sure it occurs only once). 01-09-2005 17:05:42

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Morcheeba...thx ,,,I thought that might be the prob.... Now can I upload 1f200 bytes to flash with 1 52 cmd..[manual usbpoker mode].... looks like the block offset on my CVS BLUE starts E0 [1c000] And Note !! My CVS BLUE is not comprmized...it is 6520 blue I apparently had a brain fart!!!!..I have 3-reds-6520 and 1-Red 6430 01-09-2005 18:32:43

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email If I change my pid to from 28 to 24?? will cheez download/decode pictures correctly???? 01-09-2005 18:35:06

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile mike, did you look at morcheeba's "edge of the rockies". I would say the answer you seek is YES. That assumes you didn't do what I did and change 23 and 24 to 27 and 28 in driverx.inf. This could be another confusing trip of discovery, accident, it still does not work, mistake, and now it works. Even before trying I would remove all evidence of Che-ez driver, libusb driver and then reinstall an unmodified Che-ez driver. Or if you want to simplify and minimize risk you might consider leaving type as 27, adding 27 to Foxz2 .inf file, but still removing and reinstalling. 01-09-2005 19:25:02

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile mike, if not completely sure, wait for an ok from morcheeba. I think leaving 27 requires a different check sum. 01-09-2005 19:26:50

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email Clobbered CVS BLUE tried to write firmware change ...was able to change the challeng 01 to 02 and changed pid from 28 to 24 this appears ok.... however cannot write the last block that has csum...... The CVS BLUE switches from type 28 to type 2F when clobbered this way.......and poker talks to it ok... 01-10-2005 20:09:00

RE:Discoveries - 1 2 many 4 all (modified 0 times) binaryweaver Profile I took apart the CVS Red that I just purchased a few days ago and carefully examined the edge connector. It was apparently used before because some of the contacts had slight indentations and others did not. I don't know how useful this information is, but for the record, the processing machine at CVS is using the following: 2 - Ground 6 - USB +5 Power 8 - USB Data + 9 - USB Data - 10 - Ground 01-10-2005 20:27:54

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile Mike, that should have worked You were just writing those three blocks, right? My program writes everything all together, so if it starts (sometimes it times out when first run), it's pretty reliable. Interesting it went to 2F when buggered. My PV2 stayed at the same PID, but it was operating with different pipes. I guess the PID is hard-coded into the bootloader. I thought maybe it was coming from the tags at the end of FIRMWARE.BIN, but that doesn't make a lot of sense because if you don't trust the file well enough to execute, you probably shouldn't trust it to get a PID. Bootloader mode would be fun to try to understand - my first real code mod was to try to extract a copy of it, but the code wasn't where I guessed it was. After I messed up my first camera, I quickly transfered the cable to a fresh camera ... eventually I'll have to transfer it back. 01-10-2005 22:19:49

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile mike & morcheeba, why bother even trying to change PID? Certainly it is easier to do that on the driver side. Would it be possible to just change the $80 01 to 02 and another 02 to 01 in the same block (or if not possible another block) so checksum change is unnecessary? 01-11-2005 02:38:19

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email FYI-- 2F00CA0D occurs @ 3FEB and 1F1EB things may have gone from bad to worse I seem to be only able to retrieve 1st 512 bytes of firmware with 52 command ...get 60 status read/writes the 26 cmd still appears to download all firmware 8-11=1f200 12=80 15=26 17-20=0.... This is on a w98 machine....whereas was using xpsp2 01-11-2005 09:01:10

RE:Discoveries - 1 2 many 4 all (modified 0 times) morcheeba Profile brite_eye - that's hacker heresy! The answer is, of course, "because you can". Since I'm modifying the firmware anyway, I might as well make it easier to use stock drivers. Also, a nice benefit is that you keep the PID's different for the two programs: original PID for PVTool & general hacking, Foxz2 PID for the Foxz2 driver -- I don't have much experience playing with windows USB drivers, but it seems that conflicts here have caused people lots of problems. Mike- $26 command downloads firmware? I hadn't tried it yet - great find! Yeah, I saw the two VID/PIDs near the checksum -- there's also the version number & other stuff. All I know about that is in the firmware.bin overview section of this page. I'll have to look up the $60 status code to see what that means. 01-11-2005 17:24:26

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email just purchased 2 cvs blue and 1 cvs red..... tried BLUE hum....6a31 shutter/delete/pwr unable to get libusb to detect!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1 usbview shows Device Descriptor: bcdUSB: 0x0100 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 (8) idVendor: 0x03E8 (AOX Inc.) idProduct: 0x2480 bcdDevice: 0x316A iManufacturer: 0x00 iProduct: 0x00 iSerialNumber: 0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x01 Open Pipes: 4 Endpoint Descriptor: bEndpointAddress: 0x81 Transfer Type: Isochronous wMaxPacketSize: 0x0000 (0) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Interrupt wMaxPacketSize: 0x0004 (4) bInterval: 0x0A Endpoint Descriptor: bEndpointAddress: 0x84 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x05 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0x01 01-11-2005 19:07:44

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile morcheeba, certainly compared to you I am a heretic hacker! But until someone replicates your 3 block change, don't you think it might be worthwile to attempt a one block change? I believe the Foxz2 driver related problems are with the combination of libusb and smalunhj.inf and failures only occur after unlocking using libusb first - changing just $80 01 to 02 would eliminate any need for libusb. Also an individual with a real 2mp Foxz2 may want to use hacked Pure Digitals along with a slimmer more compact edition with expanded memory card included. Now you might think I am just being selfish about my flatfoto blue - but that isn't a 24 it's a 29. Please consider, as only you can, a little more effort to simplify your change (doubt rest of thread wants to remove my heretic head). 01-11-2005 19:12:20

RE:Discoveries - 1 2 many 4 all (modified 0 times) brite_eye Profile mike, what is AOX? whether headphones scanner or something else turn off remove whatever else before tring again. 01-11-2005 19:19:16

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email AOX is popping up when I connect this blue.....I have no other usb's connected The new Red is still dca 27 ....... 01-11-2005 19:36:24

RE:Discoveries - 1 2 many 4 all (modified 0 times) mike Profile | Email new blue 000000: PnP Event: Device Connected (UP), 11.01.2005 20:28:29.7847888 The USB device has just been connected to the system. 000001: PnP Event: Query ID (UP), 11.01.2005 20:28:29.9350048 +0.1502160 Device ID: USB\Vid_03e8&Pid_2480 000002: PnP Event: Query Device Text (UP), 11.01.2005 20:28:29.9350048 +0.0 Description: USB Device 000003: PnP Event: Query Device Text (UP), 11.01.2005 20:28:29.9350048 +0.0 Location: USB Device 000004: PnP Event: Query ID (UP), 11.01.2005 20:28:29.9350048 +0.0 Instance ID: 1 000005: PnP Event: Query ID (UP), 11.01.2005 20:28:29.9350048 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000006: PnP Event: Query ID (UP), 11.01.2005 20:28:29.9350048 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000007: PnP Event: Query ID (UP), 11.01.2005 20:28:30.7862288 +0.8512240 Device ID: USB\Vid_03e8&Pid_2480 000008: PnP Event: Query Device Text (UP), 11.01.2005 20:28:30.7862288 +0.0 Description: USB Device 000009: PnP Event: Query Device Text (UP), 11.01.2005 20:28:30.7862288 +0.0 Location: USB Device 000010: PnP Event: Query ID (UP), 11.01.2005 20:28:30.7862288 +0.0 Instance ID: 1 000011: PnP Event: Query ID (UP), 11.01.2005 20:28:30.7862288 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000012: PnP Event: Query ID (UP), 11.01.2005 20:28:30.7862288 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000013: PnP Event: Query ID (UP), 11.01.2005 20:28:34.9922768 +4.2060480 Device ID: USB\Vid_03e8&Pid_2480 000014: PnP Event: Query Device Text (UP), 11.01.2005 20:28:34.9922768 +0.0 Description: USB Device 000015: PnP Event: Query Device Text (UP), 11.01.2005 20:28:34.9922768 +0.0 Location: USB Device 000016: PnP Event: Query ID (UP), 11.01.2005 20:28:34.9922768 +0.0 Instance ID: 1 000017: PnP Event: Query ID (UP), 11.01.2005 20:28:34.9922768 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000018: PnP Event: Query ID (UP), 11.01.2005 20:28:34.9922768 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000019: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.0123056 +0.0200288 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000020: Control Transfer (UP), 11.01.2005 20:28:35.0223200 +0.0100144 Pipe Handle: 0x845760e0 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000021: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.0223200 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000022: Control Transfer (UP), 11.01.2005 20:28:35.0223200 +0.0 Pipe Handle: 0x845760e0 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000023: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.0223200 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000024: Control Transfer (UP), 11.01.2005 20:28:35.0523632 +0.0300432 Pipe Handle: 0x845760e0 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000025: Select Configuration (DOWN), 11.01.2005 20:28:35.0523632 +0.0 Configuration Index: 1 000026: Select Configuration (UP), 11.01.2005 20:28:35.1124496 +0.0600864 Configuration Index: 1 Configuration Handle: 0x843e06b8 000029: PnP Event: Query ID (UP), 11.01.2005 20:28:35.1124496 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000030: PnP Event: Query Device Text (UP), 11.01.2005 20:28:35.1124496 +0.0 Description: USB Device 000031: PnP Event: Query Device Text (UP), 11.01.2005 20:28:35.1124496 +0.0 Location: USB Device 000032: PnP Event: Query ID (UP), 11.01.2005 20:28:35.1124496 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000035: PnP Event: Query ID (UP), 11.01.2005 20:28:35.1224640 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000036: PnP Event: Query Device Text (UP), 11.01.2005 20:28:35.1224640 +0.0 Description: USB Device 000037: PnP Event: Query Device Text (UP), 11.01.2005 20:28:35.1224640 +0.0 Location: USB Device 000038: PnP Event: Query ID (UP), 11.01.2005 20:28:35.1224640 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000041: PnP Event: Device Disconnected (UP), 11.01.2005 20:28:35.8034432 +0.6809792 The USB device has just been removed from the system, all drivers unloaded. 000042: PnP Event: Query ID (UP), 11.01.2005 20:28:35.8234720 +0.0200288 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000043: PnP Event: Query ID (UP), 11.01.2005 20:28:35.8234720 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000044: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.9837024 +0.1602304 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000045: Control Transfer (UP), 11.01.2005 20:28:35.9837024 +0.0 Pipe Handle: 0x845760e0 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000046: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.9837024 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000047: Control Transfer (UP), 11.01.2005 20:28:35.9937168 +0.0100144 Pipe Handle: 0x845760e0 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000048: Get Descriptor Request (DOWN), 11.01.2005 20:28:35.9937168 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000049: Control Transfer (UP), 11.01.2005 20:28:36.0137456 +0.0200288 Pipe Handle: 0x845760e0 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000050: Select Configuration (DOWN), 11.01.2005 20:28:36.0137456 +0.0 Configuration Index: 1 000051: Select Configuration (UP), 11.01.2005 20:28:36.0838464 +0.0701008 Configuration Index: 1 Configuration Handle: 0x843e06b8 000054: PnP Event: Query ID (UP), 11.01.2005 20:28:36.0838464 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000055: PnP Event: Query Device Text (UP), 11.01.2005 20:28:36.0838464 +0.0 Description: USB Device 000056: PnP Event: Query Device Text (UP), 11.01.2005 20:28:36.0838464 +0.0 Location: USB Device 000057: PnP Event: Query ID (UP), 11.01.2005 20:28:36.0838464 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000058: PnP Event: Query ID (UP), 11.01.2005 20:28:36.0838464 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000059: PnP Event: Query Device Text (UP), 11.01.2005 20:28:36.0838464 +0.0 Description: USB Device 000060: PnP Event: Query Device Text (UP), 11.01.2005 20:28:36.0838464 +0.0 Location: USB Device 000061: PnP Event: Query ID (UP), 11.01.2005 20:28:36.0838464 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000062: PnP Event: Query ID (UP), 11.01.2005 20:29:29.0600224 +52.9761760 Device ID: USB\Vid_03e8&Pid_2480 000063: PnP Event: Query Device Text (UP), 11.01.2005 20:29:29.0600224 +0.0 Description: USB Device 000064: PnP Event: Query Device Text (UP), 11.01.2005 20:29:29.0600224 +0.0 Location: USB Device 000065: PnP Event: Query ID (UP), 11.01.2005 20:29:29.0600224 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000066: PnP Event: Surprise Removal (UP), 11.01.2005 20:30:13.1834688 +44.1234464 The USB device has just been disconnected from the system. 000067: PnP Event: Device Disconnected (UP), 11.01.2005 20:30:13.2235264 +0.0400576 The USB device has just been removed from the system, all drivers unloaded. 000068: PnP Event: Query ID (UP), 11.01.2005 20:30:36.8575104 +23.6339840 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000069: PnP Event: Query ID (UP), 11.01.2005 20:30:36.8575104 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000070: Get Descriptor Request (DOWN), 11.01.2005 20:30:36.8675248 +0.0100144 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000071: Control Transfer (UP), 11.01.2005 20:30:36.8675248 +0.0 Pipe Handle: 0x843b97b0 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000072: Get Descriptor Request (DOWN), 11.01.2005 20:30:36.8675248 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000073: Control Transfer (UP), 11.01.2005 20:30:36.8775392 +0.0100144 Pipe Handle: 0x843b97b0 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000074: Get Descriptor Request (DOWN), 11.01.2005 20:30:36.8775392 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000075: Control Transfer (UP), 11.01.2005 20:30:36.8975680 +0.0200288 Pipe Handle: 0x843b97b0 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000076: Select Configuration (DOWN), 11.01.2005 20:30:36.8975680 +0.0 Configuration Index: 1 000077: Select Configuration (UP), 11.01.2005 20:30:36.9676688 +0.0701008 Configuration Index: 1 Configuration Handle: 0x83fb1ca8 000080: PnP Event: Query ID (UP), 11.01.2005 20:30:36.9676688 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000081: PnP Event: Query Device Text (UP), 11.01.2005 20:30:36.9676688 +0.0 Description: USB Device 000082: PnP Event: Query Device Text (UP), 11.01.2005 20:30:36.9676688 +0.0 Location: USB Device 000083: PnP Event: Query ID (UP), 11.01.2005 20:30:36.9676688 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000084: PnP Event: Query ID (UP), 11.01.2005 20:30:36.9676688 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000085: PnP Event: Query Device Text (UP), 11.01.2005 20:30:36.9676688 +0.0 Description: USB Device 000086: PnP Event: Query Device Text (UP), 11.01.2005 20:30:36.9676688 +0.0 Location: USB Device 000087: PnP Event: Query ID (UP), 11.01.2005 20:30:36.9676688 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000088: PnP Event: Surprise Removal (UP), 11.01.2005 20:30:57.6173616 +20.6496928 The USB device has just been disconnected from the system. 000089: PnP Event: Device Disconnected (UP), 11.01.2005 20:30:57.6774480 +0.0600864 The USB device has just been removed from the system, all drivers unloaded. 000090: PnP Event: Query ID (UP), 11.01.2005 20:31:17.5460176 +19.8685696 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000091: PnP Event: Query ID (UP), 11.01.2005 20:31:17.5460176 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000092: Get Descriptor Request (DOWN), 11.01.2005 20:31:17.5560320 +0.0100144 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000093: Control Transfer (UP), 11.01.2005 20:31:17.5560320 +0.0 Pipe Handle: 0x843e1020 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000094: Get Descriptor Request (DOWN), 11.01.2005 20:31:17.5560320 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000095: Control Transfer (UP), 11.01.2005 20:31:17.5660464 +0.0100144 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000096: Get Descriptor Request (DOWN), 11.01.2005 20:31:17.5660464 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000097: Control Transfer (UP), 11.01.2005 20:31:17.5860752 +0.0200288 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000098: Select Configuration (DOWN), 11.01.2005 20:31:17.5860752 +0.0 Configuration Index: 1 000099: Select Configuration (UP), 11.01.2005 20:31:17.6561760 +0.0701008 Configuration Index: 1 Configuration Handle: 0x845840e8 000102: PnP Event: Query ID (UP), 11.01.2005 20:31:17.6561760 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000103: PnP Event: Query Device Text (UP), 11.01.2005 20:31:17.6561760 +0.0 Description: USB Device 000104: PnP Event: Query Device Text (UP), 11.01.2005 20:31:17.6561760 +0.0 Location: USB Device 000105: PnP Event: Query ID (UP), 11.01.2005 20:31:17.6561760 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000106: PnP Event: Query ID (UP), 11.01.2005 20:31:17.6561760 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000107: PnP Event: Query Device Text (UP), 11.01.2005 20:31:17.6561760 +0.0 Description: USB Device 000108: PnP Event: Query Device Text (UP), 11.01.2005 20:31:17.6561760 +0.0 Location: USB Device 000109: PnP Event: Query ID (UP), 11.01.2005 20:31:17.6561760 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000110: PnP Event: Surprise Removal (UP), 11.01.2005 20:31:41.0297856 +23.3736096 The USB device has just been disconnected from the system. 000111: PnP Event: Device Disconnected (UP), 11.01.2005 20:31:41.1099008 +0.0801152 The USB device has just been removed from the system, all drivers unloaded. 000112: PnP Event: Query ID (UP), 11.01.2005 20:31:59.1057776 +17.9958768 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000113: PnP Event: Query ID (UP), 11.01.2005 20:31:59.1057776 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000114: Get Descriptor Request (DOWN), 11.01.2005 20:31:59.1157920 +0.0100144 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000115: Control Transfer (UP), 11.01.2005 20:31:59.1157920 +0.0 Pipe Handle: 0x843e1020 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000116: Get Descriptor Request (DOWN), 11.01.2005 20:31:59.1157920 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000117: Control Transfer (UP), 11.01.2005 20:31:59.1258064 +0.0100144 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000118: Get Descriptor Request (DOWN), 11.01.2005 20:31:59.1258064 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000119: Control Transfer (UP), 11.01.2005 20:31:59.1458352 +0.0200288 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000120: Select Configuration (DOWN), 11.01.2005 20:31:59.1458352 +0.0 Configuration Index: 1 000121: Select Configuration (UP), 11.01.2005 20:31:59.2159360 +0.0701008 Configuration Index: 1 Configuration Handle: 0x83cfe0a0 000124: PnP Event: Query ID (UP), 11.01.2005 20:31:59.2159360 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000125: PnP Event: Query Device Text (UP), 11.01.2005 20:31:59.2159360 +0.0 Description: USB Device 000126: PnP Event: Query Device Text (UP), 11.01.2005 20:31:59.2159360 +0.0 Location: USB Device 000127: PnP Event: Query ID (UP), 11.01.2005 20:31:59.2159360 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000128: PnP Event: Query ID (UP), 11.01.2005 20:31:59.2159360 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000129: PnP Event: Query Device Text (UP), 11.01.2005 20:31:59.2159360 +0.0 Description: USB Device 000130: PnP Event: Query Device Text (UP), 11.01.2005 20:31:59.2159360 +0.0 Location: USB Device 000131: PnP Event: Query ID (UP), 11.01.2005 20:31:59.2159360 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000132: PnP Event: Surprise Removal (UP), 11.01.2005 20:32:18.8241312 +19.6081952 The USB device has just been disconnected from the system. 000133: PnP Event: Device Disconnected (UP), 11.01.2005 20:32:18.8641888 +0.0400576 The USB device has just been removed from the system, all drivers unloaded. 000134: PnP Event: Query ID (UP), 11.01.2005 20:33:17.0578672 +58.1936784 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000135: PnP Event: Query ID (UP), 11.01.2005 20:33:17.0578672 +0.0 Compatible IDs: USB\DevClass_00&SubClass_00&Prot_00, USB\DevClass_00&SubClass_00, USB\DevClass_00, USB\COMPOSITE 000136: Get Descriptor Request (DOWN), 11.01.2005 20:33:17.0678816 +0.0100144 Descriptor Type: Device Descriptor Index: 0x0 Transfer Buffer Size: 0x12 bytes 000137: Control Transfer (UP), 11.01.2005 20:33:17.0678816 +0.0 Pipe Handle: 0x843e1020 12 01 00 01 00 00 00 08 E8 03 80 24 6A 31 00 00 ........�.?$j1.. 00 01 .. Setup Packet 80 06 00 01 00 00 12 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x100 Index: 0x0 Length: 0x12 000138: Get Descriptor Request (DOWN), 11.01.2005 20:33:17.0678816 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0x9 bytes 000139: Control Transfer (UP), 11.01.2005 20:33:17.0778960 +0.0100144 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B ..�....?K Setup Packet 80 06 00 02 00 00 09 00 ?....... Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0x9 000140: Get Descriptor Request (DOWN), 11.01.2005 20:33:17.0778960 +0.0 Descriptor Type: Configuration Descriptor Index: 0x0 Transfer Buffer Size: 0xaa bytes 000141: Control Transfer (UP), 11.01.2005 20:33:17.0979248 +0.0200288 Pipe Handle: 0x843e1020 09 02 AA 00 02 01 00 80 4B 09 04 00 00 02 FF 00 ..�....?K.....�. 00 00 07 05 81 01 00 00 01 07 05 82 03 04 00 0A ....�......?.... 09 04 00 01 02 FF 00 00 00 07 05 81 01 00 01 01 .....�.....�.... 07 05 82 03 04 00 0A 09 04 00 02 02 FF 00 00 00 ..?.........�... 07 05 81 01 00 02 01 07 05 82 03 04 00 0A 09 04 ..�......?...... 00 03 02 FF 00 00 00 07 05 81 01 00 03 01 07 05 ...�.....�...... 82 03 04 00 0A 09 04 00 04 02 FF 00 00 00 07 05 ?.........�..... 81 01 F8 03 01 07 05 82 03 04 00 0A 09 04 00 05 �.�....?........ 02 FF 00 00 00 07 05 81 02 40 00 00 07 05 82 03 .�.....�.@....?. 04 00 0A 09 04 01 00 02 FF 00 00 00 07 05 84 02 ........�.....?. 40 00 01 07 05 05 02 40 00 01 @......@.. Setup Packet 80 06 00 02 00 00 AA 00 ?.....�. Recipient: Device Request Type: Standard Direction: Device->Host Request: 0x6 (GET_CONFIGURATION) Value: 0x200 Index: 0x0 Length: 0xaa 000142: Select Configuration (DOWN), 11.01.2005 20:33:17.0979248 +0.0 Configuration Index: 1 000143: Select Configuration (UP), 11.01.2005 20:33:17.1680256 +0.0701008 Configuration Index: 1 Configuration Handle: 0x84f1a458 000146: PnP Event: Query ID (UP), 11.01.2005 20:33:17.1680256 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000147: PnP Event: Query Device Text (UP), 11.01.2005 20:33:17.1680256 +0.0 Description: USB Device 000148: PnP Event: Query Device Text (UP), 11.01.2005 20:33:17.1680256 +0.0 Location: USB Device 000149: PnP Event: Query ID (UP), 11.01.2005 20:33:17.1680256 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000150: PnP Event: Query ID (UP), 11.01.2005 20:33:17.1680256 +0.0 Device ID: USB\Vid_03e8&Pid_2480 000151: PnP Event: Query Device Text (UP), 11.01.2005 20:33:17.1680256 +0.0 Description: USB Device 000152: PnP Event: Query Device Text (UP), 11.01.2005 20:33:17.1680256 +0.0 Location: USB Device 000153: PnP Event: Query ID (UP), 11.01.2005 20:33:17.1680256 +0.0 Hardware IDs: USB\Vid_03e8&Pid_2480&Rev_316:, USB\Vid_03e8&Pid_2480 000154: PnP Event: Surprise Removal (UP), 11.01.2005 20:33:35.9450256 +18.7770000 The USB device has just been disconnected from the system. 000155: PnP Event: Device Disconnected (UP), 11.01.2005 20:33:35.9850832 +0.0400576 The USB device has just been removed from the system, all drivers unloaded. 01-11-2005 19:41:37