Easy As Pie - firmware rewrites 4 all!
Easy As Pie - firmware rewrites 4 all! I found the free block pointer and a relative to physical mapping table: 53.12 ptr-801ddf30, map-801dcf70 53.14 ptr-801ffed0, map-801fef10 Procedure to rewrite a 128K block on a 53.14 back to its original physical location: 1. Run OPS, open, unlock, download flash option unknown/sdram, exit/close OPS. 2. Update desired portion of a relative block using f103, ef00 "wl 801b13c4 0x05", f200, bulk write 3. Send monitor comand "wl 801ffed0 0x0000xxxx" xxxx is the physical block associated with the relative block before move in step 2. 4. Perform step 2 again. Certainly there is another member with the necessary coding skills to perform the above procedure. Currently I have only used it to move -*test*-('") blocks in the no_name partition, but as soon as I figure out what I want to modify in my next firmware update I will use this procedure. Note the next free block pointer does not have to always point at a free block, but if it doesn't firmware is smart enough to jump around allocated physical blocks (happened during one of my -*test*-('")s).

Bravo

And if that isn't simple enough here is a refinement that eliminates usb bulk write commands: unsigned char buffer; unsigned char buffw<4> = {0xFF,0xFF,0xFF,0xFF}; // set to always unlocked int data<2>, result, monlen, mon2len; string moncom, moncom2; moncom = "wl 801b13c4 0x05"; // 53.14 monlen = moncom.length(); moncom2 = "wl 801ffed0 0x0000000d"; mon2len = moncom2.length(); data<0>=0x1b08d0; // offset of word to patch (from whole image) data<1>=4; result = usb_control_msg(udev,0x40,0x01,0xf102,0,(char *)&data,8,50000); result = usb_control_msg(udev,0x40,0x01,0xef00,0,(char *)&moncom<0>,monlen,50000); result = usb_control_msg(udev,0x40,0x01,0xf200,0,buffw,4,50000); // above repeated after moving free block ptr to original location result = usb_control_msg(udev,0x40,0x01,0xef00,0,(char *)&moncom2<0>,mon2len,50000); result = usb_control_msg(udev,0x40,0x01,0xf102,0,(char *)&data,8,50000); result = usb_control_msg(udev,0x40,0x01,0xef00,0,(char *)&moncom<0>,monlen,50000); result = usb_control_msg(udev,0x40,0x01,0xf200,0,buffw,4,50000); This 4 byte patch permanently unlocks the cam allowing easy access by webcam software (Aiptek and maybe others). It's getting better all the time I used to get mad at my school The teachers who taught me weren't cool http://www.lyricsfreak.com/b/beatles/getting+better_10026427.html

I have the executable files, each where created with snippets of daBass' cvs-*test*-('") and brite's code. All i need now is someone to host it publicly, anyone interested, please pm me.

Great job on a combo compilation (daBass' CVS-*test*-('") with a few magical eye lines). Waiting for delete confirmation to expire on mass storage hack is a bit annoying but it only takes about 3 seconds. Please report back on your experience with using it as a webcam and mass storage device.

Edited above hacks to reduce risk changing f103 to f102 (if accidentally plugging something other than a 53.14 writes will go to no_name instead of p2. The wl xxxx 05 hack of BillWs accesses whole flash from first block regardless of which partition (2,3,4,5 oddly with 2 being no_name, 3 p2, 4, p3, 5, p4). But if it fails then the write would not go where intended. I believe the elimination of bulk commands will also prevent a brick when forgetting to close OPS.

Please refer to my applications at: forumer.com/viewtopic.php?t=5783" target="_blank">http://camerahacks.10.forumer.com/viewtopic.php?t=5783

I believe with minor changes the above process can be used to rewrite firmware on any PD model that uses a single flash chip for both firmware and videos. To my knowledge the only camcorders that do not are the model 100 and model 225. To find the logical to physical block assignment table use OPS to dump unknown/sdram partition and then search for "FF 01 00 00 FF 02" with a hex editor. You will also need to upload a file to no_name (or record a short video) and dump sdram a few more times to determine location of free block pointer shortly after the end of the block mapping table. Post your findings and cross your fingers hoping for a greater OPS by BillW.

I am looking in the possibility to modify the code that works to unlock FW53.14 in FW53.05. I have read the postings of Brit_eye and I do understand the basic principle, but you loose me in the specifics. Using the "allflash" dumps of fw 53.05 and 53.14, I did the following: - In the code of Brit-eye to unlock FW53.14, I seem to understand that offset 0x1b08d0 is to be patched with FF FF FF FF FF to the create the permanent unlock. - I thought I found the same position in FW53.05 and verified this with Brit_eye, but the position seems to be incorrect, so back to the drawing board Note that in my opinion there are two ways to find the patch positions and to change the code for a different FW version: - The smart way: demip the firmware, understand the brilliant steps of others before me - The dump way: find the patch positions in FW 53.14, find the same position in the other firmware and adapt the program (and pray when you run it....) I am trying to see how far I can get the dump way as it probably takes me another year to do it the smart way..... Still, there is progress. In the FW53.14 dump the patch locations are 5DDB8/5DDB9 and 1B02D0 to 1B02D3 To be continued...... Peter

To be safe you should download "all accessible flash" and "unknown partition" and understand the differences. The flash will have the lockword initialized as zeros and the SDRAM (unknown to BillW) will have the lockword set to all FFs after a successful OPS unlock.