Amyn: Huh? GotAnMP3, BillW: Actually, I'm confused again. Looking a little further at Keys.h, the reset response seems to be the same as the challenge, so my code should have worked. The format for saturnkeys.txt is the same as the one people have been posting in the challenge/response thread, right? If that's the case, I don't need a copy.

The reset response is the same as the reset challenge. That said, I'm a bit concerned about this... WRITE: bReq=01 val=fe00 idx=0101, 4 bytes -> err=0 data: 80 00 00 00 READ: bReq=01 val=ff00 idx=ffff, 4 bytes -> err=0 data: 00 00 00 00 0 - response of 0 Looks like you have a newer camera, trying response == challenge ...I'd actually expect a short challenge retrieval before the real deal to screw up 33.04 and later cams, but it seems that it's retrieving the rest of the response just fine (which is why I didn't mention it earler) Still, you might want to drop that bit as a -*test*-('"), or do a full 128 bytes for it followed by an unlock-check to see if the problem is there. Otherwise everything in the log looks alright to me. And yes, the saturnkeys.txt follows the format of the posted keys.

BillW: I had just decided there wasn't much else to do but remove optimizations when I read your post - nice to know we're thinking similar things. I assumed the camcorder was stateless so it wouldn't matter. http://koiproductions.net/PureTool%20alpha%200.2006.09.23.zip === Edit (2006.09.24): My school account is expiring soon, so I'm updating the URL, and pointing at a newer version. The original post references versions 0.2006.08.05 and 0.2006.08.05-2

The 3.XX cams were stateless, but as part of the 33.04 cam's anti-hack measures they added the 256 offset thing *and* internalized the index value. The internal index gets set on the first attempted challenge fetch and increments for each one after that, until an unlock check. I verified this by running a challenge fetch for location 0x100 32 times and it fetched the whole challenge correctly. I don't know if they removed that for 53.05 or what - it's the only reason I can think of that your code is actually fetching the challenge correctly for GotAnMP3. Still, I think your removal -*test*-('") is probably a good idea.

I'm leaving @ 5AM PST tomorrow, I can't try this sorry. I'll be back August 19 though.

It's been a long time since I've been in that code - it's entirely possible I've misremembered something. I could have sworn a scan from 0-512 wouldn't reveal the challenge, but as I've said it's been a long time.

brite_eye: Do you mean after any FE command, or just the challenge access? Because unlock verification is also FE... or is it that once unlocked, the lockword isn't cleared? Reordered to be all reads then all writes === Edit (2006.09.24): My school account is expiring soon, so I'm updating the URL, and pointing at a newer version. The original post references version 0.2006.08.05-3

Misremembered - if you don't pay close attention to detail and publish false glimmerings of the truth - you should seek a memory upgrade using less volatile components. I also recommend avoiding dosing those components with alcholol. Until I realized your mistake on lockword, I spent hours shorting trying to flip a single bit. After reviewing disassembly it became obvious that the FA command sets each of the 32 bits in lockword corresponding to a valid match with each of 32 words in response. From the "what next thread" forumer.com/viewtopic.php?t=2634" target="_blank">http://camerahacks.10.forumer.com/viewtopic.php?t=2634 Can you be more specific has to which command flips the single bit Sure... ... does it get flipped with the FE command with index 1A0. ...it's that one. FE is a bit complicated, with a bunch of conditions because it's a multiuse - it can be used to pull other data, like firmware rev, IIRC. The write 1 or 0 to the lock word is a pretty small chunk of the code. You plan may work, though I still think a solely human attempted short attack will step on code blocks being fetched for the CPU. If there was an easy way to get a single pulse of the appropriately short length you'd probably have a better chance. I'd suggest hitting up the chip select pin, to turn whatever sdram command the cam is sending into a no-op. I will grant that by only reading SuperHack's comments one might have come to a wrong conclusion. Note that new firmware appears to have added more index functions (202 and 203) in FE and FA commands (not on morcheeba's outdated pages). If CameraHacking is going to keep breathing we desperately need more eyes on disassemblies! :roll: :shock: 8)

GotAnMP3: Is the offer for an M230 still open? The process of making a small change, uploading it, waiting or a -*test*-('"), repeat is rather annoying. Alternately, someone with a Mac and a newer camcorder could try fiddling with the code and send me a patch once they get it.

status
Good: +Builds should now be Universal (note that I don't have an Intel mac to -*test*-('") on, so it probably won't work... but at least there's a chance now) +Downloads are about an order of magnitude faster. I think I had limited the speed due to limitations on the original blue camera and never checked the camcorder. Bad: -Builds might no longer work on 10.3 -Still no idea if the newer cameras unlock, the supply of -*test*-('")ers seems to have dried up (needone, you're getting back soon, right?) I'll post a build sometime this weekend. Sleepy now.

I am back with a crapload of videos taken at Quadra. Now to try that...