View Single Post
Old 06-28-2012, 03:57 PM   #2
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by hawhill View Post
I wanted to write much more and how I'm dissecting the K3's SoC-based USB downloader mode. I'll do that later in this thread, but just wanted to write a big correction to what I always wrote up to now: That it would not work to use Advanced Toolkit from Freescale out-of-the-box.

Instead, I just proved myself wrong there and successfully dumped (not yet: wrote!) the first 16MByte of my Kindle's flash.

For those who want to join the party: The relevant settings for ATK are: "TO2" model, MDDR RAM. I think it was a bit flakey here in the past because after sucessfully switching from the "ROM Kernel" over to the "RAM Kernel" the USB connection is reset, which irritated my VirtualBox'ed WinXP.

Now comes the harder part: Deciding to try to use it to actually flash something. I think I'll go and try and try with a big "marker" file on the VFAT partition...
Keep in mind that tool probably only understands the storage media, not the file system riding on top of it.
I.E: You will have to update the file system FAT-32 file allocation table + put the data on the correct clusters.
That might be a bit tricky if your DOS disk edit skills are as rusty as mine are.

Maybe like this?
Dump all of mmcblk0p4;
Keep in mind there is an 8,096 byte offset to the start of the file allocation table;
As USB storage, write your marker file;
Dump all of mmcblk0p4;
Compare first and second dump - noting the file allocation table clusters used, and the location in the media of the data you wrote.

This process lets the USB storage system do all the math about converting "next directory location" and "next cluster(s)" into physical offset addresses.
Once you have the physical address on the media of your marker file, then it is simply one addition to add in the offset from the start of the device to the start of p4.
The copy of the partition table in the dumps can give you that information.

To turn one of the dumps into a usable file system -
losetup -f
(returns first available device - the X below)
losetup -o 8096 /dev/loopX dumpfile.img
Now you can use fdisk (or whatever) on /dev/loopX to get the partition information.
mount -t vfat /dev/loopX /mnt/my_mount_point
Now you can read/write the marker file.

Got all your file system to physical storage location stuff figured out?
Now use the toolkit gui to alter the contents of the physical location of the file.

Repeat as required.
Use that "erase all" feature only as a last resort.

Last edited by knc1; 06-28-2012 at 04:00 PM.
knc1 is offline   Reply With Quote