OUTDATED 6550 Single Camera LEGAL Hack
6550 Single Camera Legal Hack: Most of the credit should go to BillW for his initial work on hardware method and an email exchange where he confirmed my belief that a shorted camera goes back to normal when removed. 1. Remove cover, use screws to tighten board down. 2. Have USB cable partially plugged in but not contacting. 3. With bottom facing down count up 5 or 6 pins on right side of SDRAM next to batteries. (no need to remove LCD) 4. Stick pointy end of mutlimeter wire between 2 pins. (5,6 6,7 sorry unsure which worked). 5. Hit power on (far left) and hope for death beeps. 6. Quickly plug camera in upon hearing failure beeps. 7. PV2Tool Open, Transfer Memory with SDRAM, size 200000, offset 0. 8. Disconnect camera. I found 5 copies of NVRAM in transfer memory dump - at 45000, 46000, 47000, 48000, 49000. The response key was at offset 208 for each of those copies. Maybe I had tried 5 times, maybe I did 5 pinches earlier - I had been trying several other thoughts before resorting to shorting SDRAM.

Nicely done brite_eye!!! For those of you that don't understand the full ramifications of "brite_eye's unlock method" ( henceforth what we should all call this technique ) you can now unlock your 6550s without needing a firmware.bin file! PD must really hate us at this point! ;)

Nice............ If you were to have posted a poll regarding a "legal hack", I would have never guessed it would be so soon. Awesome find!!!!!!

Need some confirmations! Note that SDRAM is volatile and when shorting the firmware file ended up with many mutli bit flips per byte throughout causing a checksum failure. There was a 1-2 minute delay between when I had verified cable with cover removed trying unlock (without a valid key), unpluging, taking pictures, and pinching before starting shorting process. Due to volatility none of the keys in dump of SDRAM nvram copies matched the "True" key which I knew from other methods. The first two 128 byte responses each had 1 byte that was off (I didn't bother scanning the other 3). However all had the same and correct first 4 bytes. You may want to review my earlier post "How to get your challenge and last 124 bytes of response key". Perhaps less of a delay between using camera to populate SDRAM and shorting procedure might result in identical keys.

@brite_eye: Regarding "bit flips" / mushy SDRAM bits: I was noticing the same thing when using buffer-overflow method + "mystery button SW4" (on the old PV2 PCB) to extract firmware copies over USB. I wrote a small program to take several "bad" copies of a file and use them to extract a single good copy (assuming the "bad" bits aren't the same ones every time...they didn't seem to be). Maybe this + SDRAM-corrupt method can be used to recover firmware, or at least response key?

Thanks, Drmn4ea. In most cases I doubt that any advanced program logic needs to be applied. It is easy to obtain an accurate copy of last 124 bytes of key before using above method (as described in "How to get your challenge and last 124 bytes of response key" How to post). With a need to just find first 4 bytes of key, if one has several copies in SDRAM dump just eye_ing those bytes will yield a valid key in most cases. Again we need some confirmations. All 5 copies of my key had same first 4 bytes. Once one has a key there would be no need to repeat shorting process several times to obtain a valid firmware. But we should keep your program in mind for when PD stops leaving so many copies of NVRAM in SDRAM memory.

I dunno eye - I think Drmn4ea has a point. We could make a button in pv2tool that downloaded SDRAM and then sucked the potential keys out, voted the correct bytes in the key, and then wrote out a pv2keys.txt file - the voting would be pretty much like Drmn4ea's original firmware voting program. The advantage would be a much simplified procedure - which would take the pressure off anyone writing start-to-finish docs. I'll try to confirm tonight. A question in the meanwhile - was it actually the whole NVRAM.DAT file in SDRAM (including challenge) or just the response key? If it was NVRAM.DAT, it would make identification a lot easier. That way we wouldn't have to rely on the keys being in a certain location in memory.

Another theory to -*test*-('") out - does FLASH shorting avoid the corrupted keys? (answer is likely yes)

I do not think short caused bit flips except in firmware - the keys were loaded way before shorting process and may have degraded during power outage - even plugging in a hot camera may cause a brief power fluctuation. Note again thatwith 5 keys and first 4 bytes being identical there is no need to try harder methods. Please someone try this simple less than 15 minute procedure and report back. Be sure to "exercise" camera first with on and offs, pictures and pinches.

Is the challenge key visible in the downloaded memory also? If so, we could compare the downloaded challenge key to the good challenge received from the camera by the c/r sequence. If the challenge key isn't corrupted then it might be safe to say that the adjacent response key also isn't corrupted?

Yes challenge is there - I had 5 complete copies of nvram. Note even if challenge matches unless last 124 response bytes match beginning of a valid uninterupted locked transfer mem dump there could be issues. There is virtually no issue if first 4 bytes of all responses match (as was true in my case). I'll try keeping sdram fresher tonight and see if I can shoot delete 10 times creating 10 copies of nvram - seems to be a routine pushing $1000 bytes before each nvram read into sdram.

Any one with a unlocked camera can participate in verification. Just take a pic/delete pic 3 times, plug in while still powered up, open, transfer mem sdram offset 0 length $200000. Reset LaMSSMaL dumps will be easier to spot bit flops in all zero response. By varying power offs/ons plug in/outs, bit flipping volatility may become "controlled" or atleast better understood.

I have a fresh 6550 I want to donate to the cause, but I am a little fuzzy on some steps around this procedure. Did I understand it correctly that taking three pictures and deleting all three pics will help locate the last 124 response bytes? Now if I follow the directions on downloading the sdram from 0 to 200000, what do I do with it after that? I am little fuzzy at this point. I know I have to play in a hex editor, but are they any pv2 programs to run on the recovered data?

Please see my revised "How to" (seperate thread) procedure which seems to avoid bit flips in nvram data. I use xvi32, goto $45000, backup up 1, delete to cursor, drop down to $390, delete from cursor, save as NVRAM.DAT. Then use nvramparser utility that comes with PV2Tool 2.12 to create a pv2keys.txt file and place it in directory with pv2tool exe. You should then be able to unlock your still virgin 6550. I have not figured out reason for different $45000, $45600 ... offsets or which one is the most recent when there are more than one - but if you follow my la-*test*-('") procedure one of them should be valid and if you start with a camera that has been powered off for several hours you should find only one copy of nvram.

sd card
haz any 1 ever thought of trying 2 wier an SD card to the thing or just a Wrighter im sure there some way 2 do it. i know it would make it alot ezer 2 do this if i could just eject the SD card and put it in my reader. or it duzent even half 2 be an SD just something that is removable and a computer will read. maby modified ram card? i dont know you guy are the smart people here. if you figer out how i would like 2 know about it caz i usez a copel of the not so ez 2 do hacks and would like an ezer 1 for a change. sodering is no problum i know how 2 do that prity good. please email me @ viper3905gt@yahoo.com