Well here it is folks, the long-awaited ability to dump your SPMP8k over USB!  What used to take 6-8 hours will now complete in just a few minutes.  It’s a truly beautiful thing to watch, especially if you already suffered through Fetch or our other serial tools.
We were considering releasing our USB NAND dumper tool called nandoori at the end of the week last week.  You may have even enjoyed watching our online debug session on IRC - don’t worry, we’ve got the USB packet flags right this time..  But nandoori provides so much data in the blink of an eye that it’s probably not useful for anyone except the hardcore hex-editor who wants to see the allocation tables and raw page data.

What is needed is the reverse of FRMPro - a tool that, via USB, can extract the Bootware IMG file and the Software IMG file quickly and simply.  That is exactly what you’ll get with

FRMorp - USB IMG Dumper for the SPMP8k

What, no link?  Well, we have to put it on the second page to count the article views.  It’s even gotten worse since so many people are using adblockers to remove our Google ads.  C’mon people, they pay for the cost of the site.  Or would, someday, we’re hoping.  But if you guys keep stripping the ads off this page then we can guarantee you that eventually, you’ll kill off the site.  We’re not EDN here with heinous full-page takeovers, just simple ads in between the pages of the articles.  Some of them are actually pretty good, cheap USB logic analyzers and the like.  We’ll keep weeding out the stupid ones whenever we see them, too.

Soapbox OFF!  Back to the tech.  FRMorp - get it, the reverse of pro?  We’re hilarious, we know!  FRMorp is designed to get back the BOOT_Vxx.IMG and SKxx_yy_zz.IMG files that are programmed into the device using FRMPro.  For this and other articles, we will call this the BOOTware and the SOFTware.

Now this data is not just two files in a directory somewhere - it’s actually broken up and placed in various locations in low flash memory.  The program does a fair bit of reconstruction, so if you want to read through the source you may want to use this article as a guide.

There are three main functions in FRMorp.  They were written in such a manner that they *should* be easily rippable to new programs, or compiled to a lib or dll for general-purpose usage.  The main functions are:

1. getBOOTFSfile - Given a starting page in nand flash, getBOOTFS file will go searching for a PAT - page allocation table.  If it finds one, it will dump all the data that is marked in that file’s PAT to a file on your HDD.  Normally, you get RedBoot’s PAT from the first good page.  You get the first assistant program we called DRAM_Init1 from the first good page after RedBoot’s PAT.  And another assistant we called DRAM_Init2 from the first good page after 0×12.  So getBOOTFSfile is called 3 times with the arguments 0, n+1, and 0×12 to get three files: RedBoot.mmp, DRAM_Init1.mmp, and DRAM_Init2.mmp.  These are the constituents of BOOT_Vxx.IMG.
2. packBOOTimg - This was going to be a seperate tool, but we said WTF.  Give it the names of the three bootware files from getBOOTFSfile, and it will pack you up the full bootware img file BOOT.IMG.  This file contains the 3 files from above, but adds some stupid headers and a completely retarded checksum that Sunplus must have throught of after drinking melamine-tainted milk or something.  FRMPro requires these headers and checksum, so we must pack the files or learn to flash ourselves.  Soon, my friends, soon.
3. getSOFTimg - This one is still VERY primitive.  As far as we can tell, the device reads page 0×2000 to find the length of the software partition, and then the ROFS is blindly written starting at page 0×2080.  But that seems highly unreliable due to bad blocks in the nand, etc.  So for now, getSOFTimg also reads blindly.  The output that we get is a perfect binary comparison to what we flash to the device, but someday this routine may need to be updated with some additional smarts.

That’s where we need your help.  If you dump an IMG that is not a perfect binary comparison to what you’ve programmed into your device then we REALLY want to hear from you.  We’ll send you nandoori and you’ll make us some raw data dumps that we will use to debug the issue and update the FRMorp tool.

But please, go easy on us.  If you see we’re already flooded with users commenting about bad dumps, please don’t post duplicate issues.  Once we address their problems with an update, then please DO post if that update does not cure your problem as well.

Thanks in advance!

Ok folks, time for the obligatory page turn and more info on FRMorp and how to use it.

Continued on Next Page…      Jump to Page 2    

Pages: 1 2

Related Posts:

Fun with AES-128. Example Encryption with AES Trainer (March 3, 2010)

Nandoori - SPMP8k Raw USB NAND Dumper (February 16, 2010)

SPMP8k FRMorp v1.1 - Improved the Linux side (February 9, 2010)

SPMP8k Serial Port Pinout (February 4, 2010)

SPMP8k - A door with a lock is sometimes less secure than a door without (February 4, 2010)

Metadata:

RSS feed for comments on this post.
TrackBack URI