MP4 Nation Forums
Back to MP4 Nation - The MP4 Nation Blog - The Raz Special - Themes

Ok, as i promised, i release my first version of s(UN)pack Tools here, exclusively at the mp4nation forum.
It is the first and maybe a little buggy version, it is not labeled BETA, but hey - it is!

There are not all functions implemented yet, but those implemented seems to work pretty well.
No crushes for me. Be patient while working with this tool and do not harry to push all possible buttons at the same time
Some checks are there, some - are not. So do not do wrong things.

Bug reports and ideas are welcome! I'll try to improve my app and fix bugs as fast as possible.



For now app can unpack the whole rom image, extract/replace single files (max new file size is limited to old file size, or some bytes bigger - up to 31 byte bigger, depending on exact file, any way, app will not allow to do the wrong, i hope ), extract single folders (including subfolders), change version and descript info. Preview is available for bmp/jpg/txt/xml files, all other formats can be viewed as plain text if you are lucky enough (this function is implemented 'coz some config files havo not the xml or txt but bin or smth alike extension).

The only thing that not implemented for the moment - packing back your own image - this is the one i left for the next version - along with fixing bugs And of course there is another way for the moment to pack your own image using ISPtool from sunplus.

Be careful not to spoil your FW image - tool works directly with image file, so better make a copy of it for backup.

Little bit more info:
- app unpacks FW to the "Extract" folder to the folder with the same name as image file;
- app extracts files and folders to the root of the "Extract folder";
- "Output" folder will be used as a default folder for packing tool;
- "Input" folder will be used as a default source folder for packing tool;
- "Temp" folder is a temp folder

So, you see - for the moment you are not allowed to choose any folders by yourself. I still think if it is necessary...

Ok, taste please....


P.S. Pls, do not redistribute to other web resources. Only those two in about dialog allowed and openschemes.com and only along with a link to original resource - this topic.

AWESOME! Can't wait to try it!
Thanks for your hard work!

works! very good looking tool as well.

Our developer request: It would be great if you could add new files, or replace files with different filesize. I guess that means recomputing a lot of ROFS table entries but it might not be too difficult depending on how the ROFS tables are treated in software.

Anyway, great stuff!

openschemes,

yes, adding files and replacing with a files of a bigger size wold be great i think. adding files is especially easy, while replacing needs some of my funcs to be rewritten... must study ROFS specs.

See, i was not successful to find needed ROFS node/file tables descriptions in the net, so i was analyzing the rom image with winhex and calc to investigate the way it is working in. i've investigated the order in which files/folders are placed in the image from the source folder, and don't know if i can put the file to the end of the image and just insert one node item and one fs item to tables to say it exists and to what folder it belongs to and just to update some offsets after that. and the other question is that i don't know - hidden partition are dynamically created while flashing or its size is a constant? But hey - yes i can add functionality you request, but must test the results after request accepted.

Gordgelin, fantastic job keep on going my friend!

I thought the table order was entries for dir/file, then subdir/file, etc. So I was thinking that insertion of a new file would have to split the table entries as well as the data. But just slapping it on the end is an interesting idea.

However, I have some suspicion that the device "walks" through the dir entries, loading as it goes using something like datapointer+=thisfilesoffset. In that case, one file placed at the end might blow up the pointer and have the device looking in empty space for all files after that one.

As far as the amount of space, I think it's plenty. You can estimate it by the amount that seems to be "missing" when you plug USB. Mine looks like about 256MB missing. I will find the real values later.

Ok, i thought inserting file will look like this:
- inserting new node item to node table into the proper place;
- inserting new fs item to the fs table into the proper place (depending on the dir it belongs to);
- updating file offsets/file header/some other stuff;
- inserting file data at the end of the rom image;

But then i began to think as you do. i don't think that puting file data at the end will blow up the pointer, 'coz all file offsets are stored in the node table. But that will blow up my app when calculating new file max size for replacing... and for now the new algo looks like this:
- append new node item to the end of the node table;
- inserting new fs item to the fs table into the proper place (depending on the dir it belongs to);
- updating file offsets/ file header/some other stuff;
- inserting file data at the end of the rom image;

Yes, it is. And that's the reason i was doubting if i can store new file data at the end.. For now i think i can. Just need to put node and fs items to appropriate places and correct offsets.

Yes, i've noticed that too..mine is missing about >300 mb..

P.S. 'coz don't know ROFS specs, pls tell me, is that node table, that goes after rom image header also flashed to device or that is for flasher only? 'coz if not flashed, than you are right - must split data too...

Yes, the node table is flashed to device at page 0x2000 - the start of ROFS in nand. So that must mean that the first 32MB is reserved for RedBoot, and the next 200-300MB is reserved for ROFS. After that, it's the FAT partition the user can see. I will give you the real size data soon, so you can check the limit when adding new files.

However, I think I have found a real bug this time. Replacing the OS file 8000_MMI.RAP would not boot, so I traced the problem and it seems there may be a difference/issue with arrays used to hold the data? maybe i, i+1 issue? Here's how to duplicate it.

Open image, extract 8000_MMI.RAP. Replace with extracted file. New image will not match the old image in two bytes. Last byte of RAP and first byte of next file, perhaps?

Do we both mean under "rom header" first 32 bytes of image?



Accepted and fixed, new version uploaded. Thnx for report. Just messed up some index, so had one byte lost and one junk byte

Yes, the first bytes in page 0x2080 of flash are the 32-byte header starting with .moR. Then, the table data.



No problem - glad you were able to find and fix so quickly!

Hey, guys! Download the new version 1.1! Great compatibility improvements done.
Recently i found in the web a great bunch of FWs which were ununpackable by my tool 'coz of their not standart order of packaged files, so i fix my app to support them too! If you had any issues - try this version.

And another known issue - do not try to replace the last file in this folders:
.\Resource\Xml\video\ - if you have ascending order of folders in your fw
.\Image\Game - if you have descending order of folders in your fw
.\Image - the same as previous, but only if do not have GAME folder

Cool - a new update!

Do you mind explaining what these file restrictions are?



They sound very logical, so I'm interested as to the root cause. For now, I'll follow your rules when replacing.

This restriction caused by one tiny bug in the replacing file algo. I have no time to fix it yet. But during weekend i will try to do that and to add functions you have requested.

Bug is that for now app decides if the replacement file size is valid in this way:
(next file offset - this file offset). But those mentioned files are last files in fs items table, so NO next file offset. Sorry that was late night when i was coding that part

Great

Very clear explanation - thanks for sharing the details. You've got a very nice tool here, I think that soon it will help bring a lot of new hackers into the fold.