Post/Find new camera keys here

Re: Using keys
Forgive the naivity, I'm more of a hardware person, how would one go about trying these keys in PV2Tools? Do they need to be included in a DLL or .txt file, or can they be entered manually while the program is running? Thanx for the info. Have you tried the "Legal Single Camera Hack" in the How To Section? Yours should work fine. -R

From a 6550, 2B, DB5051603083, S YourNameHere.1 C 02134d8d38621655b5ac2f60d6c4b69fd8c4eba806969c5dd2b9e0c82441084a C f220d3f511a5e1364b426ab7b1923083329ab26c6d50a3aac4599ac4b2170bb4 C 5ee376467097dec123507dc99b72b6847aec4bfcaebdd0c48cb760df23828edd C cae59e47fc41f63d665ecf5e3d6a30e8d53f1d2071e50cf5545898e0208b790e R d2d301cb5e20174263f423ab1f678a630f3adeb8556f6865fc4a5f345faf38ea R 3a1643de05db3a2a2d497e98f9adbe24ae2cc92a3e091df170b7d77622b0a12f R 82fbb5c4786c6a69152405919080c1cd7de801db6b273edd79e8290047c44f8b R 544c68123f02bbd4fdb3bf72adf14d458e9113cc381ed9f7f6faa5795e1bb23a

Thanks Brite_eye Thanks BillW S RayM 6550 2B DB604 371 6803 C 0231642253361fdbaed1853f03953582827e82babb7019f160e0e4784cd12f7f C c5030ae3fe67ee47e0d5a3660a0160a717ac35f31f17a6c380bd997dde417200 C 68a67c7d5dbe8b8acfe5df71a8ef4cceea5e98593bd82500a0d9cf3989a61896 C 0e82839978233dcb03670208e2443f1d84fd7495169cddcf499c515455e66a68 R 4cd57dcbe3e71236a251b0a79a14723ea7217c7c6523e5f7466ca4a56ad80c9a R 8df6b21643d45b7242974ef7a7d163834a45c5b2a5742537b2e4bbce592024a6 R f0e0cdf2f1c947ea396d828c35e0e941ccdbb85193bbed8136fb27f1a1e5ac5a R c45f7f07daa147c82432e931145633776de4a6965ee3a2ce0bdea7b66373208f

I think we should give up on this post the key thing now. They keys all seem to be rather random now and I am not seeing any repeating keys. I think its just something to do with the camera ID which they convert into a key on the machine. Hmm so if that is true, then key+id might actually have a purpose if you can figure out how to convert the key to a different format or figure out how the ID changes into it.

I can't find the motivation but someone else may want even more keys to research/find the algorithm that is generating keys. It certainly would be nice for new members to be able to unlock cameras without taking back cover off. It may also help when returning "unused" cameras for a newer model to not have holes in skin on back cover. I believed from the beginning that any effort to produce a key database where others could find their key was futile and even posted a poll at top of this thread with my vote going to futile.

I somewhat agree with brite_eye about the key database approach - it is looking like each camera has it's own, unique key. So, a database isn't useful for general unlocking since it won't initially have your camera's unique key... However, the approach for building a database has been very useful - this gave us the pv2keys.txt mechanism where we can easily use any camera's key once we find it. Also, a database of your personal keys _is_ a useful thing to have around. I continue to dabble at looking into challenge -> response algorithm. Since early cameras all had different ID values and the same c/r key pair, I am reasonably certain that the ID isn't part of the algorithm for calculating the response key. Having the data from several key pairs is a vital piece for figuring out and validating the c/r algorithm. At this point, however, I think we have enough pairs for development purposes - no reason to post any more (IMHO). So... this effort has been futile for easily getting into new cameras, but very useful overall. :-)

Yep - I have to agree with brite_eye on this one. The cameras don't have any algorithm contained in the FW - they just send a precomputed challenge, and wait for a precomputed response. That means that we can't glean any information from the firmware itself. This was a good design decision on the part of PureDigital - not only does it make building a "keygen" harder, it makes the firmware simpler. It would have worked great, if it weren't for the decision to include a bootloader with USB capability. These guys really "cheaped" out - and in ways that made it easy to break in. If they had gone with JTAG programming the flash, and left out the bootloader, we might still be trying to get in. This is one reason why I'm less hopeful about the camcorder, though they might have done the same thing there. That said, even the regular FF2's are experiencing "flash corruption" in the same way that BillW induced on the PV2 - so maybe the USB idea was a good one after all. Perhaps using the same flash to store both pictures AND the firmware was the bad one. Who knows... Regardless, without a sizeable sample size, by which I mean more than the few hundred people on this site, I don't think we can reliably reverse the algorithm. That said, maybe some math geek will see the pattern. So - if I obtain any more cameras, I'll continue to post the keys.

So if the keys arent based on the ID and based on a challenge and response, do we know what the challenge looks like?

All the keys posted above have both the challenge and response - a "C" preceeds challenge and a "R" preceeds response. :roll:

Personally, I have NO idea what anyone was thinking at DP when they came up with this scheme in the first place. I could understand sending out a 128 byte challenge and waiting for an encoded response (just like secure websites use). That makes sense, even though 128 byte encryption seems like overkill for a dinky little camera. But what's up with their storing the response in the flash right next to the damn challenge key?? AND in plaintext, to boot!! I only have one guess. The challenge is preencoded and stored in flash. At CVS, the challenge is sent and the bigger, faster CVS processing computer decrypts the challenge, reencrypts a response and sends it back to the camera. The camera, having limited resources and buzzing along at just a few MHz, might take like 15 minutes or something to decrypt the response. So PD probably gave up and just stored the decrypted response right there next to the challenge where the camera could just do a simple compare. Maybe they paid for an NSA level engine, and found that only the processing computer could handle it. Still, they could have stored the response/challenge strings with simple bit manipulation, but they didn't. Makes me wonder why...

...But what's up with their storing the response in the flash right next to the damn challenge key?? AND in plaintext, to boot!! IMO, it's forgivable. If you own the camera enough to get into flash or arbitrarily read memory, the game is over anyway. As radarman has pointed out, their key mistake was including bootloader mode. With bootloader mode, you don't even need to know what the response is - you can just patch firmware. Maybe they paid for an NSA level engine, and found that only the processing computer could handle it. RSA is a low-cpu patent-unencumbered public-key encryption algorithm that would have worked on the camera. Pictures would been encrypted with the Pure Digital public key, and only Pure Digital would have had the necessary key to decrypt them. The firmware might still have been patched to store unencrypted pics though... I'm still shocked that they used a pitiful additive checksum algorithm, instead of some more powerful mojo. The bootloader should be checking that the firmware has been cryptographically signed. It's a fairly standard approach, found in TiVo Series 2, Xbox, ..., which usually requires hardware methods to break. (Yes, I know both of my examples have software based exploits too ! ;) ) Given the current climate of clueless management, development staff cutbacks, and general corner cutting for short term profit, I'm not all that shocked they didn't do it right. For the record, my guess is the key generation algorithm is:


for(i=0;i<128;i++)
{
    challenge[i]=rand();
    response[i]=rand();
}

From that you probably know how I voted.

For the record, my guess is the key generation algorithm is:


for(i=0;i<128;i++)
{
    challenge[i]=rand();
    response[i]=rand();
}

From that you probably know how I voted. Only one problem with that, Bill...The processing machine couldn't read that response until after it sent that response. So the challenge can be random, and almost certainly is, but the response MUST be calculable by the external processor. This could mean that a keygen is possible. However, your rand method could still be used to build a massive database of challenges and responses (IOW, a lookup table) which could be stored in the CVS processor. Once a standard DB is established, then a random challenge/response sequence could be assigned each camera. This would mean that no keygen is possible, and at the same time we could record thousands of C/R entries before we came across a duplicate. Hmm..the more I think of it, the better that sounds. It's secure, and you could put half a million C/R entries in a single 128MB rom. I'd even bet that there's a 5-byte sequence embedded in the challenges that are sequential that the processor extracts and uses as a direct address to the rom. That would eliminate binary searching. Yup, this is beginning to sound robust enough to bet money on it... :-) Oh, and it also makes it one more vote for "futile".... :x

If it were as simple as that formula, then it would be easy to identify a seed. I still think that DA, DB, DD (what's wrong with DC :wink: ) IDs may be involved in determining a seed value which may generate both challenge and response keys. To my knowledge all lotteries have gone to truly random physical processes rather than using computers - due to ability of some to hack seeds. I believe original 2 keys (reset key and Ritz 6410 key) were essentially hard coded and have no bearing on current PD algorithmic generation used to create nvram.dat file values.

Lister - The questions about PD’s weak security measures seem to me to be better addressed by looking it from an ‘economics’ point of view. Due to the low target ‘sale’ price of the cameras themselves, PD probably had very little ‘wiggle-room’ in the amount of money that they could spend for the development and production of the camera. There is a whole range of solutions PD could have used to try to stop any ‘unauthorized’ use. The low-end ‘solution’ might be to simply cover a standard USB port with a piece of tape that says “Do Not Remove.” Of course, if they had done that, they would probably only get 1 or 2 percent of their cameras back for processing! And, PD would have gone broke. The high-end solution would be to spend millions in development costs, RSA licenses and special decoding chips in the camera in order to make the thing almost impossible to hack. This would probably have made the cameras cost $200 each. And, PD would have gone broke. In other words, the economics of the situation practically forced PD to do something similar to what they did! Be glad! Topaze

IMO it wouldn't take a whole lot to implement RSA in the camera. The hardware is adequate enough to do it in software; RSA originally ran on computers with not much more resources than our pv2. Still worried about processing delay? Just encrypt the RAW headers. No licensensing required for RSA, as of year 2000, when the patent expired. Development costs? Rip the code out of a BSD project, like Dropbear SSH or OpenSSH. That said, I think the RSA is overkill too - but there's no excuse for how open the firmware loading scheme is.

View Full Version: Post/Find new camera keys here