3.62 Only!! Hardware Method v3 - KILLS MODELS 3.7 AND UP!!

Joined: 10 Oct 2005 Posts: 40 Location: Denver, CO

This method no longer works on new 3.7 or 33.04 cameras because both USP.BIN and FSP.BIN use the same unknown key. Added by brite_eye 2/17/06.
Updated camcorder model and firmware versions on 7/18/06 by GotAnMP3.
This method is based on work done by:
Brite_Eye - who first suggested corrupting USP.BIN with a battery drop
BillW - running with the idea, coming up with the original hardware hack of shorting the I/O on the flash to corrupt USP.BIN
Gyro - who realized a similar result could be had by shorting the Chip Enable to the battery + to disable the flash, and
MUOTUC - who published the schematic that allowed me to trace pin 9 to an easier location on the board.
carpespasm - who put all the software pieces together into the QuickInstaller that makes our lives easier.

I'm just the gatherer of information...

With this method, all you have to do is open the back of the CVS Camcorder, have a steady hand and a fair sense of timing (and probably some luck).

Apparently, this is much safer than the 6-7 short, less chance of ending up with a dead camera, and any existing videos on the camera are recoverable.

0) First things first!

Download and install the QuickInstaller. This includes the USB library files, the camera driver files, and Ops that talks to the camera and allows you to download videos and change settings.
Do a Vulcan Nerve Pinch on the camera to see what version you have (hold down Record & Delete buttons, then press Power button):
Model 200:
3.40 - Nice! Stop here. Simply plug your cam in and use Ops!
3.62 - Carry on...
3.70 - Carry on with patience... May take more short attempts to get the sweet spot.
23.82 - CAN NOT be hacked using this method.
Model 220:
33.04 - No firmware versions of this camcorder are hackable using this method.
33.17 - "
33.19 - "
Model 230:
53.05 - No firmware versions of this camcorder are hackable using this method.

1) Open the battery case by releasing the latch with a paperclip or whatever.

2) Slide the battery holder out of the case.

3) Lift the 4 corners of the sticker and unscrew the 4 silver fasteners.

4) GENTLY pry the case open. 2 catches at the bottom of the battery case, and 1 on either side in line with the screen.

5) Here's what you're looking at on an unhacked camera: The video preview screen shows the status text and time remaining.

6) Cut yourself about a 6" length of wire. On one end, strip as little insulation as you can. This will be the end you touch to the circuit board, so you don't want a lot of bare metal flapping around in there.

7) Pop the lower battery out, slide the long end of the wire behind the spring contact on the positive side (+) and pop the battery back in to secure it.

8) Now, your target is the tiny resistor R101 below the flexible cable of the LCD screen. It's not next to it's text, but closer to the top left corner of SW2. It will have "103" printed on top (if your eyes are that good). You want the side that's facing SW2. According to MUOTUC's schematic (and verified), this is connected directly to Pin 9 (CE) on the flash chip.

You may need to clean the solder joint at the end of the resistor of the oxide layer (a thin, nonconductive film that forms over the solder that may prevent your wire end from touching metal). Use a pencil eraser (if you can get in there), or scuff it up with an Xacto (careful!). [Thanks vnikuda!]

9) Now the tricky motor skills vs. timing part. BE CAREFUL. When you press the power button (SW1), about 1/2 second later the unit will beep and the screen will light up with the CVS welcome. You want to touch the stubby end of the wire to the right side of the resistor RIGHT before the beep. It will probably take you several tries.

[Update] There's some evidence that for 3.62's the sweet spot is right before the beep, and for 3.70's it's right after the beep. Either way, you don't need it on there for very long.

10) If you get it right, the preview screen will come up with no status or time text (looks black here because it's face down on the table. Will show video preview). If not, power off and try again. After 250 trys on a 3.70 and no video preview without status, Dino reports success by plugging in with dark gray/black screen. Also others have had better luck soldering wire to resistor and touching battery contact instead of trying to hit resistor each time. edited by b_e

At this point, I was able to connect the unit directly to the computer and use OPS 0.13 to Open and Unlock the camera (see Applications, Quickinstaller). Others have reported they had to power down first, then connect to the computer.

Good luck and let me know if there are any corrections needed![/b]

Posted: Wed Oct 12, 2005 7:42 am

Captain Obvious,
Great photos. None of that appears obvious to me. I stickied your how to and changed it to version 3. 8)

That looks so easy, why should anyone even bother looking into OldGuru's RSA hint on decrypting all keys.

Joined: 12 Oct 2005 Posts: 1

Thanks, I tried this last night for a while and I was on the wrong resistor. This morning after reading your how-to, first try I got it to go blank then unlock with OPS.

couldn't have been easier.

Now to have some fun

Posted: Wed Oct 12, 2005 12:02 pm

I'm in agreement with brite_eye, Captain Obvious. The new short location is totally worth a version bump and a hack-author status for yourself.

Kudos on this excellent detective work, and thanks for all of the attributions! (You should co-attribute the flash short method to brite_eye, as it was his suggestion that we might corrupt USP.BIN with a hardware short.)

Joined: 05 Aug 2005 Posts: 1554 Location: jacksonville, fl

sweetness, this looks much nicer than the 6-7 short. is the chance of bricking the cam reduced by this method?

Joined: 10 Oct 2005 Posts: 40 Location: Denver, CO

I really don't know the true risks of corrupting too much and frying the cam, but according to Gyro's analysis and Brite Eye's assesment, it's merely disabling the flash chip during a write and much safer.

Big benefits here are that any existing video you've got on the cam is still there.

Joined: 01 Oct 2005 Posts: 33 Location: Annapolis, MD, US

Thats a pretty good howto, nicely detailed and seems easier than the other methods.

Joined: 08 Oct 2005 Posts: 23 Location: Cypress, TX

would be help if you soldered a wire off this pad and then touched the wires together outside the case? Thinking it would reduce missing the pad and having to try again.

waldo

Joined: 12 Oct 2005 Posts: 1

Thank you! I got my cam after lurking around this forum for a day or so - but I completely missed the threads about 3.62. It was my 9 yr. old's birthday and he has been wanting make his own movies for a year now. No way can I afford to give him a real cam (I certainly don't have one)and frankly, he's a great kid, but it will get lost/broken/stolen, etc. He was super hyped when he got it and I was sort of struggling with a centronics cable build (big fat fingers) but I finally got it hooked up and boy was I dissapointed when it didn't unlock. That's when I started reading this forum more closely and following all of your progress. Anyway, I just didn't want to risk the 6 & 7 short with my fingers, so this was a great save.

I will say I didn't quite get the timing right a couple of times so when I finally got it to work the old videos were gone. Kind of sucks, but he'll get over it and now on to produce his first "indie" Very Happy

.

Thanks again!

Posted: Wed Oct 12, 2005 9:49 pm

Success! May the deities of hacking bless you amply!

Thanks, now I need not fear the 3.62!

I used a 4 inch piece of leadfree solder, and got close maybe five times (losing text, but no unlock) before it took. About 40 attempts in all.

That's versus 120 tries and no wins with the 6&7 method.

Yippee, and thanks again!

(Note to self: Send 50,000 influence to Cpt. Obv.)

Joined: 02 Aug 2005 Posts: 7

docwebhead wrote:

Quote:

I used a 4 inch piece of leadfree solder, and got close maybe five times (losing text, but no unlock) before it took. About 40 attempts in all.

For all who wants to use this method - clean first the resistor connection by using eraser or scalpel from oxidized film on solder.

Posted: Thu Oct 13, 2005 12:10 pm

Heh. Good call. There may even be a conformal coating to breach.

My connection was pretty ...polished... by the first few attempts (with stranded wire). I switched to solder cause I figured it wouldn't do as much damage.

As a side effect, it turned out to have a great consistency for the job: I was able to form it into an approximate shape and then just press it slightly to make contact. It was springy enough to make trying a good bit easier once I noticed it.

Joined: 01 Jul 2005 Posts: 1542 Location: is everything

Well that figures... ;)

I am (was) days away from having my keyscan FPGA up and running. I pretty much have the FPGA board and design done, I just had the front end buffer board left to do. Now, it appears I can scrap the design.

Well, at least now we don't have to worry about the 3.62's anymore - I can divert my FPGA board to other tasks...

(On a positive note - I did refresh my memory on all the oddities of the board, and discovered that you CAN make Quartus II compile for obsolete parts if you know the exact part number -> Flex 10K100GC503-3 )

Posted: Thu Oct 13, 2005 2:47 pm

I wouldn't scrap it just yet Radarman. Unlike the hardware hack on the PV2, there are ways they can guard against this attack with changes to the firmware.

Also, it sounds like you may have a fairly general purpose approach. That could be handy when Pure Digital comes out with a one-time-use holographic cam. Smile

Joined: 07 Aug 2005 Posts: 214

Agreed, having a brute-force toolkit that doesn't depend on the behavior of the camera's firmware is still a worthwhile venture, IMHO.

Personally, I'd still want a way to just sniff out the keys. Call me a purist, I just don't like the idea of losing original data and falling back to a default key. Who knows, maybe firmware 3.8 will cripple the camera if it detects the Reset Keys are being used in USP.BIN. If I were working at PD, that's exactly what I'd consider doing.

Besides, I was looking forward to getting my feet wet in Xilinx programming.. something I've always wanted to do, but never had a Real-World reason to invest in the hardware. Very Happy

Joined: 01 Jul 2005 Posts: 1542 Location: is everything

Hmm, perhaps my investment of many hours of VHDL programming wasn't a waste.

Unfortunately, due to the extreme age of the FPGA I have, I had to use the Altera megawizard functions to get my design to run at speed (defined as 24MHz for this gadget). With a pure VHDL FIFO model, I was getting around 16MHz. (yikes!) With the Megawizard generated FIFO, I get nearly twice that (30MHz according to the timing analyzer)

The FPGA design is practically done. I still need to fully simulate the compare & capture logic (I ran a small sim, but by no means thorough).

Other than that, it does what I wanted. You program the parameters through a RS232 serial port. You can actually start or stop the scan from either the serial console, or discrete buttons. Serial comms is fixed at 8N1, but it can detect if you are using CR or CR+LF on its own and adjust accordingly. Baud rate can either be 9600 bps or 19,200 bps. (I didn't feel like implementing faster rates - though it would be fairly trivial to modify the design to operate at almost any data rate) 19,200 is more than fast enough for what this board does, though. 9600 was a throwback to my old 486 laptop, whose serial port isn't reliable above 9600! (it's a Comcrap^h^h^h^hpaq 486LTE)

The only concession is that the Altera FIFO's don't have RT (retransmit) signals - so once you dump them, they are "dumped". Basically, you had better be watching when you type in the (D)ump command. ;)

The FIFO models are the only Altera specific code I used - so if anyone else wants the remainder of the VHDL - I'd be happy to share. The design has a working UART (you can remove the TX and RX FIFO's if you don't need them, I actually just added the FIFO's recently, and the changes are trivial), simple command processor, message generator, and scanner core with parallel capture. (it has a "sliding" window, that is instantaneously compared with the trigger sequence, allowing for single clock comparisons)

Because I wasn't sure how fast the host's READ_EN* signal is, I chose to use it as a clock. If someone could use a scope, and tell me the effective data rate of the FLASH, I might be able to use an internal clock, and sample the data the "normal" way. My board has sockets for two clock oscillator modules (original design had no PLL's, and was required to run at either 50 or 66MHz on command - a very interesting design actually...)

Commands are (as you would expect) simple - single characters for most commands.

Commands:
(@) Reset - performs a synchronous reset of the entire design.
(S) Start - Starts the keyscanner state machine
(D) Dump - Initiates a dump of the capture FIFO to the serial port
(F) Flush - Flushes the capture FIFO (not really useful with the Altera FIFO's - but already in the design)
(M) Mask - Sets or reads the trigger mask
(P) Sample Count - Sets or reads the number of samples to capture AFTER the trigger is found. Effectively acts as a (P)ost-trigger capture size.
(C) Trigger Count - Sets or reads the Trigger (C)ount. Number of times the trigger phrase is found before data is captured.
(A) Actual Trigger Count - If you abort, this will tell you how many times the trigger phrase had been seen. (read-only register)
(T) Trigger Phrase - Sets or writes the trigger phrase.
(<CR>) Issues a prompt, or confirms a command
(<ESC>) Cancels the current command.
(=) Indicates that you are going to write new data when used after the M,P,C,T commands.
(?) Indicates that you want to read the current value when used after the M,P,C,T commands.

Examples:
(M)(=)(F)(F)(F)(F)(CR) sets the Trigger mask to 0xFFFF
(A)(?)(CR) reads the actual trigger count.
(S)(CR) Starts the scanner
(T)(=)(ESC) Begins to write the trigger sequence, but then aborts.

Note, I used a double buffer for all registers, so data is not changed unless the sequence completes. This means that if you abort, the old data will still be present.

Lastly, there are 10 LED's that indicate system state, including a 4-LED progress bar. Smile

Joined: 05 Oct 2005 Posts: 2

Thanks a lot to all involved in cracking the camera yet again.

I got lucky and unlocked my 3.62 on the first try with method 3.

It has been great fun breaking out my soldering iron again after so long (I spent most of the 80's sitting at a bench soldering under a scope at a defense contractor).

Posted: Fri Oct 14, 2005 12:08 am

radarman wrote:

Hmm, perhaps my investment of many hours of VHDL programming wasn't a waste.

Unfortunately, due to the extreme age of the FPGA I have, I had to use the Altera megawizard functions to get my design to run at speed (defined as 24MHz for this gadget). With a pure VHDL FIFO model, I was getting around 16MHz. (yikes!) With the Megawizard generated FIFO, I get nearly twice that (30MHz according to the timing analyzer)

The FPGA design is practically done. I still need to fully simulate the compare & capture logic (I ran a small sim, but by no means thorough).

Other than that, it does what I wanted. You program the parameters through a RS232 serial port. You can actually start or stop the scan from either the serial console, or discrete buttons. Serial comms is fixed at 8N1, but it can detect if you are using CR or CR+LF on its own and adjust accordingly. Baud rate can either be 9600 bps or 19,200 bps. (I didn't feel like implementing faster rates - though it would be fairly trivial to modify the design to operate at almost any data rate) 19,200 is more than fast enough for what this board does, though. 9600 was a throwback to my old 486 laptop, whose serial port isn't reliable above 9600! (it's a Comcrap^h^h^h^hpaq 486LTE)

The only concession is that the Altera FIFO's don't have RT (retransmit) signals - so once you dump them, they are "dumped". Basically, you had better be watching when you type in the (D)ump command. ;)

The FIFO models are the only Altera specific code I used - so if anyone else wants the remainder of the VHDL - I'd be happy to share. The design has a working UART (you can remove the TX and RX FIFO's if you don't need them, I actually just added the FIFO's recently, and the changes are trivial), simple command processor, message generator, and scanner core with parallel capture. (it has a "sliding" window, that is instantaneously compared with the trigger sequence, allowing for single clock comparisons)

Because I wasn't sure how fast the host's READ_EN* signal is, I chose to use it as a clock. If someone could use a scope, and tell me the effective data rate of the FLASH, I might be able to use an internal clock, and sample the data the "normal" way. My board has sockets for two clock oscillator modules (original design had no PLL's, and was required to run at either 50 or 66MHz on command - a very interesting design actually...)

Commands are (as you would expect) simple - single characters for most commands.

Commands:
(@) Reset - performs a synchronous reset of the entire design.
(S) Start - Starts the keyscanner state machine
(D) Dump - Initiates a dump of the capture FIFO to the serial port
(F) Flush - Flushes the capture FIFO (not really useful with the Altera FIFO's - but already in the design)
(M) Mask - Sets or reads the trigger mask
(P) Sample Count - Sets or reads the number of samples to capture AFTER the trigger is found. Effectively acts as a (P)ost-trigger capture size.
(C) Trigger Count - Sets or reads the Trigger (C)ount. Number of times the trigger phrase is found before data is captured.
(A) Actual Trigger Count - If you abort, this will tell you how many times the trigger phrase had been seen. (read-only register)
(T) Trigger Phrase - Sets or writes the trigger phrase.
(<CR>) Issues a prompt, or confirms a command
(<ESC>) Cancels the current command.
(=) Indicates that you are going to write new data when used after the M,P,C,T commands.
(?) Indicates that you want to read the current value when used after the M,P,C,T commands.

Examples:
(M)(=)(F)(F)(F)(F)(CR) sets the Trigger mask to 0xFFFF
(A)(?)(CR) reads the actual trigger count.
(S)(CR) Starts the scanner
(T)(=)(ESC) Begins to write the trigger sequence, but then aborts.

Note, I used a double buffer for all registers, so data is not changed unless the sequence completes. This means that if you abort, the old data will still be present.

Lastly, there are 10 LED's that indicate system state, including a 4-LED progress bar. Smile

...you had me at hello! Laughing

That's quite the project! Now I'm hoping that Pure Digital closes the new hole so you can really take it out for a spin!

Joined: 06 Aug 2005 Posts: 19

Excellent tutorial/pictorial! Well done!

Joined: 25 Sep 2005 Posts: 14

silly question. . . .after getting the short at the right time, does the camera still beep? I have gotten the screen to go blank but no beep. I then can not shut the cam off and have to remove a battery to shut it off.

I have tried hooking to USB and unlocking with ops13 before powering down, with no luck at all.

Joined: 05 Aug 2005 Posts: 1554 Location: jacksonville, fl

try power cycleing it once or twice

Joined: 15 Oct 2005 Posts: 1 Location: Philadelphia

This method worked great. Took several tries. Anybody else get a screen with the numbers 1 1
2
The way that you see them abobe are the way that they displayed. Black screen with white numbers. I plugged the camera in and was able to unlock it.

Joined: 16 Oct 2005 Posts: 2 Location: USA

Hello,
I have been lurking on this forum for awhile now. I was able to score a 4.3 camera and with all this information I was able to build a cable and using OPS12 able to make my cam-corder a cheap digi-cam.

I have two questions
1) When using Ops to download the flash is the flash copied from the camera or removed?

2) If I have a USP.BIN from a 4.3 can I corrupt the flash on a new cam and upload the USP.BIN from the 4.3?

Thanks for all the great work. You make it easy for those who don't mind spending time reading. You all have done a great job of documenting your work and posting well written howto's

devnull

Posted: Sun Oct 16, 2005 1:26 am

devnull,
3.4 not 4.3!

1. copied not removed.
2. you only need to succeed once in corrupting a 3.62 or 3.7 flash. After that OPS can unlock everytime using "reset" key. I am not sure if anyone has verified USP.BIN still has an identical format on all the releases. On PV2 cameras the format changes slightly with new releases.

Joined: 16 Oct 2005 Posts: 2 Location: USA

brite_eye,

Thanks for the reply. Sorry about the 4.3 3.4 thing. I have learned alot from all your posts. Especially those on the still camera.

devnull