The current brickmaker has some unusual problems. All you need is to include the "if(partition==0)" and "if(wholeimage==true)" sections from download flash in the upload flash code and set the data<0> and data<1> to appropriate start and size. I recommend placing start on a 1K boundary and setting size to 1K. The first firmware rewrite should just attempt to rewrite the last 1K of firmware. And before that you need to experiment (step 12) on a 1K(2 sectors) inside no_name partition to determine how many times you must loop to get back to the same physical sectors (or give up trying). Or if you are anxious to try the routine at top of this thread you just need to review and include the code for wholeimage download in the upload routine.

The race against time is on. New discovery: Using nandreadp on a model 230 requesting 4 sectors with a sector number that is on 2K minus 1K boundary returns just two sectors followed by 64 extra bytes (providing logical block addresses)! I think PD really should consider using a more current version of RTOS and Threadx to properly interface with newer Zoran Coach processors and large block flash. Not sure yet but nandread seems to be reading a complete block into memory even though only a few sectors are requested. I expect to avoid complicated loop coding and hope to produce a firmware rewrite success in a few days.

Update on progress: My coding is almost done (of course it is quick and dirty and will never be released). I have managed to update a 1K block in a -*test*-('") file I uploaded to P4 several times watching m230 release a large block of flash and grab a free block. Although the choice of a new block seems random, I am hoping I can get back to the original without too many rewrites. After filling the camcorder with videos there appear to only be 24-27 free blocks. I wonder if it is possible to claim more than 1000 logical blocks on the large block flash by writing past the end of P4 which is currently at offset 131072000 (128,000 K). That would reduce the free blocks and increase my chances of getting back to the original. Note that when I actually try updating the last 1K of firmware I am hoping to have been able to complete the P4 -*test*-('") in less than 1 hour.

Success! :D I was able to rewrite the last 1K of firmware on a model 230. I had -*test*-('")ed with a file in P4 and proved that on the 34th rewrite it was back to its original location using a bat file set to execute my Borland C program 17 times. This worked 3 times for my -*test*-('") file on the second invocation of the bat file. However after an unplug and replug of my m230 Saturn on my first execution of the bat file I saw the non all FF 64 extra bytes (which I was logging) show up after about 8 rewrites - using a nandreadp as described above followed by a special 64 byte download of memory (F101 download unknown partition). I then executed the bat file again for another 17 updates of the last 1K of firmware followed by manually executing the program until I saw the non all-FF extra bytes (representing that the update had come back to the original physical location). The total number of rewrites was around 42 times. Note that each of my 1K rewrites results in the Zoran Coach (or maybe firmware) copying a whole large block of 64 2K chunks (128K) to a free block and then freeing up the current physical block. Next step - flip a couple bits (similar to my hold PV2 firmware hack producing the same checksum) and perform another rewrite. I am hoping that if there is any checksum it is simple, but a brief scan of the firmware does not seem to reveal any hash or checksum. If that works then I will disable the lock and enable mass storage (may need to import code if not already in m230). 8)

great progress!

Congrat..

This is exciting! :D

I'm so glad, I'm so glad. I'm glad, I'm glad, I'm glad. http://www.eric-clapton.co.uk/ecla/lyrics/im-so-glad.html I have succeeded in a permanent unlock for my 53.05 model 230. I can now use it as a webcam on any PC with IS-DV installed without having to unlock with OPS. After the rewrite of the last 1K of firmware, I flipped a bit off in one word and the same bit on in the next word (hoping for a simple checksum) with success, followed by flipping just one bit proving no checksum (and no sophisticated hash), followed by writing FF FF FF FF to the lock word (indicating all 32 words of the challenge had been matched by a response). 8) Is any member of this "1 2 many 4 all" community willing/able to follow my process and update BillW's OPS or provide a more powerful Linux tool 4 all? Eye will not provide code - just English instructions. My last 3 rewrites took 24, 8, and 16 iterations respectively to get back to the original physical block keeping the firmware contiguous.

Amazing perseverance Mr.Eye! Kudos and congrats! I'm not interested in adding an "unlock patch" button to Ops, but enabling the "firmware upload" button might be worthwhile... can I have a show of hands of people wanting to actively hack the firmware?

--raises hand-- i'd like for it to be actively developed, but i'm not the one to do it. i'll stick to client side apps, thanks.

I'll raise my hand, if only to experiment with the firmware and create some bricks while learning :)

Ok, it sounds like there's still some interest in firmware. I'll look into it, though I'm pretty busy as of late so don't expect miracles on the turnaround. There's some tricky aspects to the code. Brite's hack was on the 2k-block 230's, and wether it can be made to work on normal 512 byte block cams is unknown.

firmware
I would love to download my m230 53.12 firmware and do some -*test*-('")ing. I will soon be hexing in the battery indicator that saturn_nites found but would also do any steps necessary to perm. unlock my cameras.

I now have 4 quick and dirty Borland C programs that allow me to upload a new firmware on model 230s in less than 5 minutes (dwfirm, mid2end, upfirm, extra): 0. Open with OPS, unlock, format no_name, exit OPS 1. dwfirm, change firmware lockword to FF FF FF FF. 2. mid2end - this creates a block in middle of no_name and moves it to end of flash minus 16 blocks. 3. upfirm and check using extra that it is located in last 16 blocks (if not you probably goofed somewhere). 4. upfirm again, verify at start of flash. 5. Open OPS, click open, then click on powerdown button (probably not necessary but safer). 6. Power up, Open OPS, no need for unlock, format storage (to remove temporary block in relative middle of flash). dwfirm - downloads from start of flash for 16 blocks. mid2end - downloads middle block of flash then uploads it unitl it reaches the end of flash minus 16 blocks. upfirm - uploads from start of flash for 16 blocks. extra - displays result of nandextra. Any coders wanting to duplicate? - Please ask questions in the Questions forum.

I have suceeded in writing a 53.14 firmware, p2, p3, p4 and fisrt block of p0/no_name to a 53.12 using a modified version of the above procedure. I had some extra difficulty due to firmware + used part of p2 now taking 17 blocks instead of 16. On my write of the 17 blocks the 16th and 17th were reversed causing a noncontiguous memory - so I had to quickly recode (without powering down or screwing up) and move the pointer back through memory rewriting just those last 2 blocks a couple more times to get them in proper continguous locations. A 53.12 reflashed from a 53.14 can ZOOM! 8)