Database Users

Actual size of file (extracted using dumprom) is not OK

Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance

XIP files would report incorrect size. Because they are XIP

If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!

I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem

Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel

IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem

If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).

Tool to create custom Ext roms for Alpine

Hi folks,
I've had some sleep now so am editing the original posting to make it clearer and give due credit!
The attached application is based mostly on Wilems (itsme) tool (http://nah6.com/~itsme/cvs-xdadevtools/xda2nbftool/alpinenbfdecode.pl) - so the bulk of the credit goes to him. All I did was work out the checksum algorithm; but as I really suck at Perl, my tool is written in C.
Anyway, this tool allows the decoding of ms_.nbf extended rom files to their header and fat16 image (which can be mounted and modified).
The sneaky part of this tool then allows these two components to be encoded to give a working rom file that can be uploaded to the Alpine device using the usual ROMUpgradeUt.exe application.
Now, PLEASE USE WITH CARE - as I won't be held responsible if using this tool results in a dead Alpine device! Usual disclaimer ..... Also this is an alpha version, so any feedback would be appreciated.
The tool is command line based (no GUI yet - although I will do that soon).
Run the tool without any parameters to get the help - but here's a quick guide:
1. Extract a suitable upgrade (e.g. XDA_IIi_Upgrade_v1.11.162.exe) to a directory like c:\upgrade
2. delete nk.nbf & radio_.nbf files
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. run it to extract the fat16 file and header :
alpine_ext_rom_tool.exe -d -n ms_.nbf
5. this creates ms_.fat and ms_.hdr
6. edit the ms_.hdr (see comments in this file for instructions)
7. mount ms_.fat and add/remove files as needed (updating Config.txt)
8. delete the old ms_.nbf file in c:\upgrade
9. run the tool to create a new nbf file:
alpine_ext_rom_tool.exe -e -f ms_.fat
10. make sure the files been created
11. run ROMUpgradeUt.exe or MaUpgradeUt_noID.exe to update the extended rom on your alpine!
Let me know how you get on if you do decide to give it a go!
Cheers
There's a new GUI version of this tool now available here : http://forum.xda-developers.com/viewtopic.php?t=34783&highlight=

Splash screen
Well as a follow up and after some experimenting - seems like the splash screen is hidden within the extended rom somewhere.
I used the Imate and O2 extended roms as bases, and even after deleting all cabs, etc, within these files and placing my own cabs within - I still get a splash screen which is different between. That is the Imate one using the imate extended rom and the o2 one using the o2 extended rom.
I assume that this is hidden somewhere, but not as a file. It would be nice to be able to edit this as well. Does anyone have any information on where the splash screen may be?
Although I haven't tried using a new, clean, FAT16 image file ... maybe that would give just the default windows mobile splash.... hmmmm
Hey ho

splash image
Splash screen is appended at the end of the FAT16 image.
The size of the fat file extracted from the nbf file is 0x18C0000 and the last 0x40000 bytes of this file are the splash screen in nb format.
So theoretically if you replace the last 0x40000 bytes of the fat file with your chosen splash screen (format as nb using nb_image_converter_859_418.exe) then that's the splash screen you'll get on startup....
Hmmmmm, quiet round here ain't it? Maybe I'll just talk to myself :wink: - more than likely this has all been figured out before ... perhaps I should've done some searching before I started?
Hey ho

hey ho! ;o)
bro, you've made a cool proggie!
don't be disappointed by no answers... maybe there are not so many Alpine users out there...
keep it up and take care...
buzz

Hi Buzz,
Dakujem - thought I was talking to myself there for a little while .... not unheard of!
I suppose until hacking these roms becomes simpler (at least until there are some nice gui programs) it'll remain a bit of a niche market.
But I'm learning to live with the short-comings of the XDA 2i ... nearly :shock:

;o)))
nemas za co... ;o)))
buzz

I don't think the same as bal666.. In fact there are many people waiting for their Alpine 's to be mungled and squeezed just like the BlueAngel There are just so many stuff for the BlueAngel and it makes some people buy BlueAngel. I believe there are a lot of non-posters here that are waiting for some stuff like yours <g>

Hi all
Yes i'm another, doing the rounds of the forum's and threads looking for a convienient solution to the extended ROM. I been sitting on the outer cause i don't think i can make a worthwhile contribution to your quest.
I'm just not prgram savy
Good at following instructions thow!!
I'm desperate to build a nice extended ROM with all the features of Special edition you guys produced some time ago.
Could you point me to a CABS listing that can tell me whats worth retaining/ updating/removing. I'm using the Dump ROM out method.
Which incidently is giving a little grief with format of the created files, ext .img. Any thoughts
So keep up the good work, i'm sure theres a stack of people counting on your good work.
Mike

Hi SubZero & Mike,
thanks for that - makes it seem somewhat more worthwhile. I actually wrote the tool out of boredom, and the fact that I continually play with my XDA and wanted an easy way to restore all my programs and settings; rather than doing it manually.
Mike, there are a number of pages/sites with extended rom cab listings - like http://www.dmmh.nl/xda/ although I couldn't get into it today.
As for your dumprom problems ... sorry mate I've never used it - although there is a thread somewhere here with that (although I'm sure you've seen it) ...
Anyway, the next program will do the same as now but also allow the alteration of the built-in splash screen image - might as well now I've started. But I doubt I'll do a gui version, it's just not worth the aggro!
Cheers

Your right link seems to be down, any other sites would be good.
How could we, the alpine community convince you to develop a GUI??
Think of the incredible personal prestige and total job satisfaction you would get from this.
This is a terrible suck job if you hadn't realized by now.
Thanks
Miket

I thought I'd post this here as a link to a thread I started on updating the XDA2i extended ROM (you are not alone in your crusade)
http://forum.xda-developers.com/viewtopic.php?p=171104#171104
There are lots of bits inside there but the method pointed to works if all you want is to modify the Extended ROM.
http://en.pdamobiz.com/en/forum/forum_posts.asp?TID=373&PN=1
Have fun,
Graham.

Checksum Algorithm
Hi GBird,
thanks for that.
Also I've had a few people ask how the checksum is calculated, so the code is included below. The alpine_crc_key_lookup uses the same keyset as the blue angel - see nbfutils from wilem (itsme); and I suspect the algorithm is the same as well (I'm not going to go and look ... too much effort involved).
Generate a crc for the fat16 image portion of the extended rom and add this to the crc for the header portion (without the checksum field, meaning only the first 120 bytes). This gives you the key you should be using to encode the whole extended rom.
Enjoy!
Bal
--------------------------------------------------
DWORD alpine_crc(
char data[],
int data_len,
DWORD crc)
{
int i = 0;
DWORD crc_new = crc;
/***********************************************************
* Calculate the CRC for this data stream
* Based on a decompilation of the RUU.dll loc_1000C174()
***********************************************************/
for (i = 0; i < data_len; i++) {
crc_new = (crc_new >> 8) ^ alpine_crc_key_lookup((data & 0xFF) ^ (crc_new & 0xFF));
}
return(crc_new);
}

Dear bal666
As a newbee, please instruct in detail the upgrade process from step # 6, 7 & 9
wait for your news
thanks for your hard work

Hi Harry
simple instructions would be as follows:
1. Extract a suitable upgrade, preferably from your provider to a directory like c:\upgrade. Mine is O2, so I use e.g. XDA_IIi_Upgrade_v1.11.162.exe
2. delete nk.nbf & radio_.nbf files from the c:\upgrade directory
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. Open a dos window and cd to c:\upgrade
5. Run alpine_ext_rom_tool.exe to extract the fat16 file and header, like this : alpine_ext_rom_tool.exe -d -n ms_.nbf
6. this creates ms_.fat and ms_.hdr
7. download and install "Extra Drive Creator Pro" from http://www.extradrivecreator.com/download/
8. In Extra Drive Creator add a "File to Drive" using the ms_.fat file in the c:\upgrade directory
9. Add/remove files cab files as needed
10. update the Config.txt file on the mapped drive, open it in a text editor and you'll notice it contains a list of cab files and the order to install them
11. delete the old ms_.nbf file in c:\upgrade
12. run the tool to create a new nbf file: alpine_ext_rom_tool.exe -e -f ms_.fat
13. make sure the ms_.nbf file has been created in c:\upgrade
14. run ROMUpgradeUt.exe to update the extended rom on your alpine!
Hope that helps
Bal

Hi there,
Do you know if there is an issue with the size of the files that are added to the extended ROM ie can you use the whole 24MB?
Using the SD card method with the ntrw.exe file, you are limited to 20.8MB otherwise you start have corrupt CAB files in your extended ROM.

Hi Pug,
alot of my understanding of the Alpine device is based on supposition and blind experimentation .... :shock:
But, from what I believe the extended rom nbf file to do; I reckon you can use the whole 24Mb to store cab files. Let me explain:
The length and structure of the so-called fat16 image that exists in the nbf file maps rather nicely to the rom structure of the Alpine (and I assume the same holds true of other 64rom devices) - see the following web page for what I mean http://wiki.xda-developers.com/index.php?pagename=AlpineRomStructure
If you take an extended rom nbf file and decode it, you end up with a file (excluding header) that is layed out as follows:
0x0000000 - 0x17FFFFF = extended rom fat16 image
0x1800000 - 0x187FFFF = 0xFF padding
0x1880000 - 0x18A57FF = Splash image in nb format
0x18A5800 - 0x18BFFFF = 0x00 padding
This is an exact match to the rom structure - so the so called fat16 image contains alot more than just the extended rom files!
Errrr, to get back to your point - I think you can fill the whole 24Mb with cab file; but best approach would be to try it ....
Bal

Pug,
just had a thought about what you said. The size of the fat16 image (as a whole) is 24Mb on the nose.
So with overhead of MBR, FAT tables, etc - you're probably looking at something like 23.7Mb of storage ....

Thought that's what you'd say so I'm experimenting now.
23.4MB didn't work so I'm trying to slim it down now. Shouldn't have to slim it down more than about 0.5MB so I'm reckoning that 23MB will be the limit.
Now I've put it on a diet I'm trying to find files to beef it up from 21.5MB, suprising how difficult that actually is.
Will let you know when I've found out.
For the record though.....YOU ROCK.

Why thank you
Let me know how it goes ... I'm trying to get some time to update the tool to extract and insert splash screens too - but I have some real work to do too!

Thought I'd try and help out a little here:
0x0000000 - 0x17FFFFF (Extended ROM Fat 16 image)
This is a size of 25,165,824 bytes (24Mb)
FAT tables are usually in 512 chunks and each 512 chunk gives you a pointer to 256 blocks of memory. The blocks are usually in 1,024 bytes (1Kb) though this can vary (in a full file system the blocks are usually much larger).
In a standard OS there are usually two FAT tables (as a backup system) so I will assume that there are two here also.
On top of this there will be at least one block taken up with the directory structure (more if you have subdirectories).
So if my numbers are close then you will need 96 * 2 512 byte FAT tables (This makes an overhead of 98,304 bytes).
On top of this there is 1,024 bytes for the root directory giving a total overhead of around 99,328 bytes.
This leaves you with 25,066,496 bytes for data (23.9 Mb).
You may lose an extra 512*32 (16,384) if there is an MBR on the front of this, though I would think that would be elsewhere.
The rest of the space you will lose through slack space (1,024 blocks that are not completely filled by the data you are using) so if you have a large number of files this theoretical 23.9Mb may drop significantly.
For instance, the Config file is probably around 600 bytes so you will lose the rest of the 1,024 block (424 bytes) as slack space.
If any of this helps you then great
Hope you have fun,
Graham.

Extracting files from a segment with SRPX signature, how?

I am trying to extend the bepe's kitchen in order to include support for Mio A701 and Mio A700 (Scoter platform). Some of you are already aware of it.
Our DOC architecture is quite simple:
- DOC's static RAM: G3/G4 Initial Program Loader
- DOC BDK0 Binary partition that keeps the Bootloader
- DOC BDK1 Binary partition that keeps the Microsoft Initial Program Loader (also called SPL over these forums, isn't it)
- DOC BDTL0 TrueFFS partition that keeps the WM5. This partition is exactly 50MB (0x3200000 bytes). It is a MSFLSH50 image containing a 0x400 bytes header followed by 4 subpartitions.
- DOC BDTL1 TrueFFS partition that keeps the user data in a FAT32 filesystem.
BDTL0 has 4 subpartitions:
- Part00 Starts at offset 0x400 inside the MSFLSH50 image. Unknown format, it has 'SRPX' signature at offset 0x40.
- Part01 Unknown format, it has 'SRPX' signature at offset 0x40.
- Part02 IMGFS segment.
- Part03 segment with an empty FAT16 filesystem used for padding the size of 50MB required for the BDTL0_MSFLSH50 partition.
I can extract everything but those files stored in Part00 and Part01. IMGFS can be easily extracted and built with the IMGFS_tools by Mamaich.
In HTC devices the kernel and critical drivers are stored in 2 XIP chains, but these files do not seem to be XIP chains since they are compressed or encrypted. Thew SRPX signature is not very common, Buzz Lightyear talked about it here:
buzz_lightyear said:
hi willem,
hmm... I know, it's a problem...
wm5 compression signature is 'SRPX' (as far as I remember coz i'm 1 month away from it). it's XPRS other way around. XPRS is some standard compression. I guess it is also included in cecompress.dll from CEPB5.
...just a thought... maybe a bit of help...
is it also used in smartphones with wm5?
thanx
buzz
Click to expand...
Click to collapse
After that no one else has talked about this kind of segments or SRPX signature.
If you want to take a look at the unknown segments/subpartitions of the MSFLSH50 WM5 image then you can download a dump of Part00 and Part01 from here.
I need to extract and insert files into this segments, can you help me with any related information about it please?
Thanks a lot,
Oki

Hi Oki,
where did yo dig that post about SRPX out, please )))
Anyway, i still have no info about that, but i'm wondering, what would you like to put inside...
Oki said:
Microsoft Initial Program Loader (also called SPL over these forums, isn't it)
Click to expand...
Click to collapse
))) it actually is SPL
buzz

It is nice receiving a quick answer here. I have already posted this in your site.
It seems that Microsoft calls the SPL as MS IPL. It does not matter, in the MiTAC world bootloader is known as UBoot and has a nice menu for selecting the part that you want to flash so we only need to create a customized MSFLSH50 image and that's all, the OS is upgraded.
I want to create a customized image for my device so I need to apply the certmod.dll patch described by mamaich. Any other solution?
The kernel file, some critical DLLs and boot.rgu among other important files are in those two segments, so in order to create a customized OS I will need to access these files and replace them.
Let me ask you where did you found the SRPX signature? Is there any other device with this image format?
Thanks,
Oki

Oki said:
It is nice receiving a quick answer here. I have already posted this in your site.
Click to expand...
Click to collapse
)))) maybe because i was on this site, when i've got notification...
But i first answered at buzzdev.net ))))) LOL
"Hi Oki,
so SRPX... )) i saw that very long time ago in some Himalaya WM5 ROM. i really can't remember, where exactly.
all i know is, that XPRS is a kind of compression, so i thought that time, that XPRS is actually SRPX other way around.
Then, as other things poped up, i somehow forgot about that totally ))
CU
buzz"

For Oki: SRPX signature found on ATOM LIFE
Hello Oki,
The XDA Atom Life has MSFLASH50 format as well as SRPX signature for the kernel part. I was wondering what is the start of the segment for the MSFLASH50...? I couldn't seem to get msflshtool.exe to work with this ROM. It keeps on saying not a MSFLASH50 format.
BTW, your Scoter Kitchen tools worked on XDA ATOM, we are trying to port the files from XDA ATOM LIFE into our ROM... Fortunately you have covered this format so we can extract its contents...
Jiggs

request for other srpx-tool
Hello, and sorry for digging in this old thread.
I have a XDA Comet aka Atom Life and the XIP is SRPX compressed like Jiggs described.
I'm trying to update the Kernel.
I use the SRPX tools from Scoter kitchen. With MSFLSHTOOL i get 2 XIP and 1 imgfs part.
I use SRPX2XIP for the second part and the XIP is 1728 KB.
If I change back with XIP2SRPX the new part is only 1442 KB.
So I write back this part to my ROM image and the image doesn't boot.
Is this an error from SPRX tools or did I miss something ?
I can't find an other tool for that job. Google gives only a hint to "sushi-repeat-containing protein" but i guess that's not the information i realy need.
May be someone can enlighten me.
Attached a link to Atom Life XIP (If someone is interested)
http://rapidshare.com/files/79622471/LifeXIP.rar.html

scorpio16v said:
Hello, and sorry for digging in this old thread.
I have a XDA Comet aka Atom Life and the XIP is SRPX compressed like Jiggs described.
I'm trying to update the Kernel.
I use the SRPX tools from Scoter kitchen. With MSFLSHTOOL i get 2 XIP and 1 imgfs part.
I use SRPX2XIP for the second part and the XIP is 1728 KB.
If I change back with XIP2SRPX the new part is only 1442 KB.
So I write back this part to my ROM image and the image doesn't boot.
Is this an error from SPRX tools or did I miss something ?
I can't find an other tool for that job. Google gives only a hint to "sushi-repeat-containing protein" but i guess that's not the information i realy need.
May be someone can enlighten me.
Attached a link to Atom Life XIP (If someone is interested)
http://rapidshare.com/files/79622471/LifeXIP.rar.html
Click to expand...
Click to collapse
Did you do a hex comparison between old and new XIP? you could try dumping and rebuilding first without modifications, and see the difference. vivi was able to sort this thing with his asus p525.

tjlabais said:
vivi was able to sort this thing with his asus p525.
Click to expand...
Click to collapse
Thank you for the hint.
After comparing the Comet-, the Atom Life- and the rebuilded file, I'll try to hexedit the beginning and fill the end of the rebuilded file to match the right filesize.
Will report later.
edit:
after simply cosmetical changes with a hexeditor the files are identical.

The ExtRom Research thread (Trinity/Hermes, maybe others)

While cooking my german GPS rom I noticed that there is very little information about the ExtROM nb format. Right now we can't extract it, we can't rebuild it, we can't resize the partition.
So I figured it was time to put some research into the matter. I made a package that contains the following:
- 04_ExtROM.nb (from RUU_Trinity_HTC_GER_1.23.407.2_103_6275_1.38.00.11_108)
- extrom_dump.raw (a dump of the extrom area after flashing it)
- Content (content of the extrom, copied from device after unhiding)
The idea is to analyse how files are written from NB to flash and how they are stored inside the NB. The format should be identical with Hermes and maybe other devices.
The goals of this research are:
1) understanding the Extrom NB format
2) making an extraction tool for getting files out of extrom.nb files
3) making a rebuild tool that allows us to make custom extrom.nb files
4) Resizing the Extrom partition
Please post your findings in this thread, you can also contact me on IRC (#xda-devs on irc.freenode.net
Here's the file:
http://rapidshare.com/files/24740192/ExtromResearch.rar.html

Here's what I found out so far (only worked on it for a few minutes):
R1:
The Extrom nb seems to hold 7 versions of each file, probably for 7 different languages. Search for PP_AKv33-DefaultPage_ and you'll find:
PP_AKv33-DefaultPage_FIN-040b.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_RUS-0419.CAB
PP_AKv33-DefaultPage_FRA-040c.CAB
PP_AKv33-DefaultPage_GER-0407.CAB
PP_AKv33-DefaultPage_FIN-040b.CAB
Those occur in the 7 different config.txt files. Maybe those cabs are not all really in the NB, at the very least they must be very similar. Otherwise it wouldn't be so easy to compress. I found 7 occurences of several cab files in the NB by searching for the first few bytes of them.
R2:
The raw dump does not contain the config.txt files (at least I couldn't find them). Maybe config.txt gets stored elsewhere. I also didn't find the cabs in the dump so far, maybe a different format or a bad dump.
I had used
pdocread.exe -w -d EXT_FLA -p Part00 0 0xa00000 extrom.raw
R3: Only one of the 7 files in NB actually is actually in the ExtROM content.
My conclusion from R1 and R3:
The extrom.nb holds information for different languages or OS versions. Depending on some information only one of those actually gets flashed.

I'm finding it strange that the extracted ext_rom and the dumped ext_rom haven't the same structure.
I own a wizard (Qtek9100) and using Typho5 to extract it from the RUU and using podcread to dump it from the phone i always get a FAT16 image file. I can then use a program like Winimage to browse and edit it as i like.
Are you sure the extracted ext_rom is correct?

I believe I did everything correctly, yes.
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.

ZakMcRofl said:
I believe I did everything correctly, yes.
Click to expand...
Click to collapse
If you remove the first 0x1040 bytes from the nb file you get something looking like a FAT16 image, but still not working correctly. I wonder if the nbh decoder by itsme as a bug that produces a corrupted extension_rom?
ZakMcRofl said:
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
Click to expand...
Click to collapse
I did I downloaded your dump and used Winimage to check the raw file and it showed an empty confused FAT16 image
ZakMcRofl said:
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.
Click to expand...
Click to collapse
Winimage allows it. There's a tutorial by Faria on how to cook ext_roms and flash it back to wizards and winimage is advised
cheers

This post says otherwise (regarding TFAT16, not FAT16)
The simpliest method.
1. Take MS_.NBA (a decrypted version of MS_.NBF). Open it in any hex editor, and search for bytes "EB FE 90 4D 53 57 49 4E 34 2E 31 00" ("ыРMSWIN4.1", there would be "FAT16" string a bit lower). The string should be found near offset 0x70000. Extract everything starting from the place you've found and up to the end of file to a file named "extrom.img"
2. Open "extrom.img" in WinImage, edit it as you like, save the file
3. Open the hex aditor and place modified "extrom.img" to the same place in MS.NBA file where it was before extraction.
that's all. Convert NBF to NBA and flash your ROM.
The same method cannot be used on Universal. It has TFAT16 instead of FAT16, WinImage knows nothing about TFAT and destroys FAT table. But there is a simple workaround.
Click to expand...
Click to collapse
Source: http://forum.xda-developers.com/showpost.php?p=847312&postcount=10

Well, winimage works perfectly with wizard nb files (decrypted nbf files)

Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.

ZakMcRofl said:
Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.
Click to expand...
Click to collapse
Maybe that's why Wizard's extended roms get corrupted when users try to delete files in it. Perhaps WM5 or WM6 use TFAT16 upon rebooting and it
screws up the reading

Filelist
I took the content files and searched for their occurrences in extrom.nb.
Here is the filelist with hex positions:
Code:
0x0000A280 BT_Table.CAB
0x0001F3B0 Config.txt (FIN)
0x00020A08 HTC_WM5DST_signed.cab
0x000485D0 MP_CVSDcpl_20060920.cab
0x000685B0 PP_AKv30-DefaultPage_ALL.CAB
0x0007DCF8 PP_AKv33-DefaultPage_???.CAB
0x00093850 PP_ExtVersion.xml
0x000956C8 PP_FixITS2654_SMD.CAB
0x000A2800 BT_Table.CAB
0x000B7930 Config.txt (WWE)
0x000B8F88 HTC_WM5DST_signed.cab
0x000E0B50 MP_CVSDcpl_20060920.cab
0x00100B30 PP_AKv30-DefaultPage_ALL.CAB
0x0012B7B8 PP_ExtVersion.xml
0x0012D630 PP_FixITS2654_SMD.CAB
0x0013A768 BT_Table.CAB
0x0014F898 Config.txt (WWE)
0x00150EF0 HTC_WM5DST_signed.cab
0x00178AB8 MP_CVSDcpl_20060920.cab
0x00198A98 PP_AKv30-DefaultPage_ALL.CAB
0x001C3720 PP_ExtVersion.xml
0x001C5598 PP_FixITS2654_SMD.CAB
0x001D26D0 BT_Table.CAB
0x001E7800 Config.txt (RUS)
0x001E8E58 HTC_WM5DST_signed.cab
0x00210A20 MP_CVSDcpl_20060920.cab
0x00230A00 PP_AKv30-DefaultPage_ALL.CAB
0x00246148 PP_AKv33-DefaultPage_???.CAB
0x0025BCA0 PP_ExtVersion.xml
0x0025DB18 PP_FixITS2654_SMD.CAB
0x0026AC50 BT_Table.CAB
0x0027FD80 Config.txt (FRA)
0x002813D8 HTC_WM5DST_signed.cab
0x002A8FA0 MP_CVSDcpl_20060920.cab
0x002C8F80 PP_AKv30-DefaultPage_ALL.CAB
0x002DE6C8 PP_AKv33-DefaultPage_???.CAB
0x002F4220 PP_ExtVersion.xml
0x002F6098 PP_FixITS2654_SMD.CAB
0x003031D0 BT_Table.CAB
0x00318300 Config.txt (GER)
0x00319958 HTC_WM5DST_signed.cab
0x00341520 MP_CVSDcpl_20060920.cab
0x00361500 PP_AKv30-DefaultPage_ALL.CAB
0x00376C48 PP_AKv33-DefaultPage_GER-0407.CAB
0x0038C7A0 PP_ExtVersion.xml
0x0038E618 PP_FixITS2654_SMD.CAB
0x0050DE80 MP_CVSDcpl_20060920.cab
0x00527EE8 Config.txt (FIN)
0x005282F8 HTC_WM5DST_signed.cab
0x005C9298 PP_AKv30-DefaultPage_ALL.CAB
0x005DE9E0 PP_AKv33-DefaultPage_???CAB
0x005F4538 PP_ExtVersion.xml
0x005F63B0 PP_FixITS2654_SMD.CAB
R5: Files are stored sequentially for each language.
I haven't found where the offsets and how the offsets are stored, maybe relative to the beginning of a language section. I haven't found the absolute offsets anywhere yet.

HTC Extended ROM image editor. This release adds support for Artemis.

TFAT Image Editor 1.2.0.14
==================================================
A utility to editing Extended_ROM.NBs files.
May be especially useful for use with (T)FAT filesytems image files.
==================================================
Operating systems supported:
- Windows 2000/XP/Vista
Features:
- Create an Extended_ROM image file. Support: Artemis, Athena, Elf, Gene, Herald, Hermes, Titan, Trinity.
- Extract file(s) from the image.
- Write file(s) into an existing image file.
- AutoConfig function.
- Support TFAT 12, TFAT 16 filesytems. 512, 1024, 2048, 4096 sector size.