Database Users

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.

DIY your ROM

Hi,
I write some code that can modify the ROMs, it can save your time to add and delete files by hand.
RomMaster V2.0 Beta
Usage: RomMaster [options] imagefile
-d[m] <dfile> - delete file
replace file/module together with -a option
'm' delete module, deleting module isn't suggested
-a[c] <afile> - add file into the rom
'c' means use compress(need CECompressv4.dll)
-o <ofile> - output imagefile name
-v <0~9> - print info, 0 detail, 9 only show errors, default is 5
-w <5> - 5 is 2005, default is 2003&SE
-x - only save XIP(OS) data
-s <0x...> - Fix XIP start address(Hex)
-e <0x...> - Fix XIP end address(Hex)
In replace mode, 'c'&'m' is useless
It is now 2.0 Bata Release.
You can delete file/modules you don’t like from the ROM.
RomMaster –d “filename” –o “newROMname” “ROMname”
You can add files into the ROM.
RomMaster –a “newfilename” –o “newROMname” “ROMname”
You can replace file in the ROM
RomMaster –d “filename” –a “newfilename” –o “newROMname” “ROMname”
“newfile”’s size should be the same or small than the file you want to replace, new file will occupy the same space as the old one.
I test some ROM in my SP; include SDA, Dopod 575 & 585. I only tested one 2005 ROM. Replace module may don’t work, I am still working on it.
Before you burn the image generated by the tool, make sure you finish follow step:
1. RomMaster –o “TestROM” “SrcROM”
2. Do binary compare “SrcROM” with “TestROM”
a) If they are 100% same, I think you can safely use this tool.
b) If they are 99% same, you should be careful, make sure you only burn the OS part. Because some ROM are modified by someone before, there are maybe some useless data in the ROM, only burn the OS part won’t damage your SP.
c) Else, the “SrcROM” may contain some unknown structure or data, the “TestROM” may won’t work, don’t try burning it into you SP. If you want to modify it, tell me where I can find the ROM, if I am free, I can give some help.
3. I only tested one 2005 ROM, its structure isn’t very correct, and I think that ROM is extracted form emulation ROM. So if 2005 ROM isn’t 100% same, don’t try and be careful even they are 100% same.

This is great!!!
Going to try it!

ncruz,
I'll wait for your experience, cause if this is working we can all save space by directly burning upgraded cameras etc into the rom. will save me at least 1MB ram or storage.
The tools sounds great gmap.

There already exists MKROM tool - http://www.xs4all.nl/~itsme/projects/xda/romtools.html
it is 100% working with WM2003/2003SE devices. But it is rather inconvenient.
I'll test your "-w 5" option on a real device. Real WM5 device has one XIP kernel section with only few modules and about 1Mb free space. All other data is kept in IMGFS partition, I'm currently working on a tool that would work with it.
And one question. When you add new files to ROM, do you add them to a new XIP or extend the existing XIP? And when you delete modules, do you reuse the freed space after adding new ones?

mamaich said:
There already exists MKROM tool - http://www.xs4all.nl/~itsme/projects/xda/romtools.html
it is 100% working with WM2003/2003SE devices. But it is rather inconvenient.
I'll test your "-w 5" option on a real device. Real WM5 device has one XIP kernel section with only few modules and about 1Mb free space. All other data is kept in IMGFS partition, I'm currently working on a tool that would work with it.
And one question. When you add new files to ROM, do you add them to a new XIP or extend the existing XIP? And when you delete modules, do you reuse the freed space after adding new ones?
Click to expand...
Click to collapse
That's great if we can modify IMGFS partition I am waiting for it.
I know that tool and i don't know how it works. I made this tool only for interesting.
You can find XIP chain in 2003 ROM, by XIP chain, you can know the address and length of each XIP section. I will scan the hole XIP region before inserting the new file to reduce memory fragment. When a module is deleted, its space will be freed and reused when adding files. I freed about 6M space in my own ROM by deleteing the useless files, and add about 5M files into it, it works OK.
It seems 2005 don't have XIP chain information in the ROM, i only test one 2005 ROM, and i didn't find the XIP chain info. If your 2005 ROM don't have XIP chain info too, you should modify ROMHDR.physlast to a correct value by hand. Because if i can't find the XIP chian info, I use ROMHDR.physlast to decide the end address of XIP. Or, there are almost no space for you to add new file. My 2005 ROM physlast=0x8c253278, and only about 78732 bytes free before 0x8c253278.
I update the the tool V2.2 , fixed a bug when deeling with MDA(818) ROM.

gmap said:
That's great if we can modify IMGFS partition I am waiting for it.
Click to expand...
Click to collapse
I've PMed you a test version. I'll make it available to public later.
... If your 2005 ROM don't have XIP chain info too, you should modify ROMHDR.physlast to a correct value by hand.
Click to expand...
Click to collapse
My ROM has all needed info, I had to extract everything from rom image after 1C0000 address to a separate file and gave it to your tool. It is working perfectly. I've managed to delete and add a new file to ROM. I have not tested "-dm" option. It seems that all modules/files in XIP section of WM5 are uncompressed. I'm using BlueAngel's WM5 ROM. Later I'll try to replace boot.hv file with my own version.
Can you add a switch to your program "-s bytes" so that it woud skip the given number of bytes from file start, so it would be possible to work directly on NBA files with header?

gmap, can you tell me what file i can use this with? Is it for nbk or nba files? Thanks

I'm not able to edit the xip sextion ...
i've tried your tool on 1.60c.07CHS rom for xdaII :
RomMaster.exe -w 5 -x -o test.bin nk.nba
result :
[Info] It is a common ROM.
[Error] File is damaged, end address small than start address.
[Error] File is damaged, end address small than start address.
RomMaster.exe -w 5 -x -o test.bin imgfs_raw_data.bin (created with mamaich's tool)
result :
[Info] It is a common ROM.
[Error] Load nb00 failed.
RomMaster.exe -w 5 -x -o test.bin img.bin (created by nba part 1C0000 to end)
result :
[Info] It is a common ROM.
[Error] File is damaged, end address small than start address.
[Error] File is damaged, end address small than start address.
How to save the XIP section ?

TofClock said:
RomMaster.exe -w 5 -x -o test.bin imgfs_raw_data.bin (created with mamaich's tool)
Click to expand...
Click to collapse
This would not work. My tool works with IMGFS and you need to edit XIP

and ... how to edit XIP ?

mamaich said:
My ROM has all needed info, I had to extract everything from rom image after 1C0000 address to a separate file and gave it to your tool. It is working perfectly. I've managed to delete and add a new file to ROM. I have not tested "-dm" option. It seems that all modules/files in XIP section of WM5 are uncompressed. I'm using BlueAngel's WM5 ROM. Later I'll try to replace boot.hv file with my own version.
Can you add a switch to your program "-s bytes" so that it woud skip the given number of bytes from file start, so it would be possible to work directly on NBA files with header?
Click to expand...
Click to collapse
mamaich, or anyone else, what did you use to extract after 1C0000?
splitrom?
any help would be greatly appreciated.
Russ

Wow , just an hex-editor like winhex or edithexa

i tried that w/xvi32, and it didn't seem to work. I guess I'll try again

Thx gmap for this great tool. 8)
Recently I want to replace the TureFFS.dll at the XIP area of Wizard OS ROM.
ftp://xda:[email protected]/Uploads/HTC_Wizard/Roms/Qtek/Qtek_9100_1_6_7_ENG__OS_ONLY.zip
I type the following command and it says that it cannot replace the file.
Code:
D:\>RomMaster.exe -d TrueFFS.dll -a TrueFFS.dll -w 5 -o new.nba os.nba
[Info] It is a common ROM.
[Warning] o32_rom(0x8c268ef8)'s o32_data at 0x00000000 is zero.
[Warning] Found dif-referenced region [OLD] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00008000
[Warning] Memory Block(0x8c101000,0x8c1510ac) overlap with Block(0x8c10288c,0x8c1028b8).
[Error] You want to get an object whose size is 108, but it is 112. RomOffset=0x8c268e00
[Error] Could not replace 'TrueFFS.dll' with 'TrueFFS.dll'.
However, I can successfully replace the boot.hv file. Do you know why?

ahlok_hk said:
Thx gmap for this great tool. 8)
Recently I want to replace the TureFFS.dll at the XIP area of Wizard OS ROM.
ftp://xda:[email protected]/Uploads/HTC_Wizard/Roms/Qtek/Qtek_9100_1_6_7_ENG__OS_ONLY.zip
I type the following command and it says that it cannot replace the file.
Code:
D:\>RomMaster.exe -d TrueFFS.dll -a TrueFFS.dll -w 5 -o new.nba os.nba
[Info] It is a common ROM.
[Warning] o32_rom(0x8c268ef8)'s o32_data at 0x00000000 is zero.
[Warning] Found dif-referenced region [OLD] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00008000
[Warning] Memory Block(0x8c101000,0x8c1510ac) overlap with Block(0x8c10288c,0x8c1028b8).
[Error] You want to get an object whose size is 108, but it is 112. RomOffset=0x8c268e00
[Error] Could not replace 'TrueFFS.dll' with 'TrueFFS.dll'.
However, I can successfully replace the boot.hv file. Do you know why?
Click to expand...
Click to collapse
In replace mode, new file should not biger than old file. So, you should delete old 'TrueFFS.dll' first, then add the new one(You can delete some file next to 'TrueFFS.dll' to get free space or move it to a big free space, then modify the file size and related infomation of 'TrueFFS.dll' by hand to make it bigger). Replacing module isn't stable, I confused by some of the module data. If you want to replace a module, it may not work. I haven't find a way that can be used to calculate all of the data.

gmap said:
In replace mode, new file should not biger than old file. So, you should delete old 'TrueFFS.dll' first, then add the new one(You can delete some file next to 'TrueFFS.dll' to get free space or move it to a big free space, then modify the file size and related infomation of 'TrueFFS.dll' by hand to make it bigger). Replacing module isn't stable, I confused by some of the module data. If you want to replace a module, it may not work. I haven't find a way that can be used to calculate all of the data.
Click to expand...
Click to collapse
Thx for your explanation. Actually the new file is smaller than the one being replaced. And I just found that I can only delete those non-module files while all modules could not be deleted.
Thx again. Hope to see new version if you have time to find out how to calculate the data. :wink:

How can i extract a kernel file (kbbdrv.dll)?
thanks

dherrero said:
How can i extract a kernel file (kbbdrv.dll)?
thanks
Click to expand...
Click to collapse
dumprom tool
But if you'll extract this or any other XIP DLL and then readd it to the same, or any other ROM it would not work.

Hello,
I have a Apache Rom,
I would like to delete nk.exe are replace it.
iv tryed:
rommaster -w 5 -d nk.exe nk.nba
also
rommaster -w 5 -d nk.exe -a nk.exe nk.nba
keeps telling me i can delete that file.
just to let you know: if i use dumprom i get the boot partition files (containing nk.exe) and if i use imgfs i get all the os files (not containing nk.exe)
Any help would be great thanks

you cannot delete nk.exe, and you should not even need to do that.

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.

HP Ipaq 6955....need Help

Hi,
I need help with my Ipaq 6955......i got a french verison and i need a english rom to flash, i have tried the tread that talks about the 6915 but does not work...
Please help need a english rom for it and if some has a wm6 rom for this model please let me know

Welcome to the club!
http://forum.xda-developers.com/showthread.php?t=325051
Might help.
Anyways you (and I) need a Rom or rom upgrade that is in English (F*ckin HP doesn't provide it!!) Anyways P.M. I can give you the dumps of an English rom (I dumped it with pdocread (see link above) but I haven't tried to pdocwrite it so more or less its a shoot in the dark (dawn?) If you want more info about my dilemma see my last post in the above discussion. http://forum.xda-developers.com/showthread.php?t=325051&page=3
Anyways PM if you want those dumps
I guess there is another option available e.g. modify the registry and add some MUI files (Havent researched that option yet)

To convert nb to nbf there is a solution, but some questions stays unanswered...
During an upgrade, RUU uses wdatas which seem to use signature (source: hermes forum...). We don't have information about wdata command availability in bootloader mode.
In fact, the english dump you made is a CEOS file with header and some imgfs_removed_data.bin informations.
I tried to use a dump to create a CEOS file which could be disassembled as any other ipaq69xx ROM, but RUU hangs and the upgrade fails.
If we could know why the upgrade fails (checksum test, signature...), we could try to find a way to bypass it.
After this step, it will be easy to cook some ROM.
One more problem is G3 and G4.... Is it supposed to be the same G3/G4 difference than for wizard?

to b0ris747
In another thread earlier you gave this link http://forum.xda-developers.com/showthread.php?p=1480853
Just went through the whole thing - relevant but not helpful. For short:
1) Extracting the osrom.nb using pdocwrite. To be frank I didnt like the usage of -d flag (device name) and -p (windows assigned) partition name. It makes things very confusing (If you try to actually follow the procedures not only re-type) because there are duplicates of device names TrueFFS and duplicates of partition names Part00 Part01 etc. If someone wants to understand the pdocread.exe flags and usage please read the following thread where itsme explains it all http://www.spv-developers.com/forum/showthread.php?t=2888
2) That thread describes a method to extract the directories of an OSrom image (using these tools http://forum.xda-developers.com/showthread.php?t=249836)
So this action helps to cook (modify the OSrom's files) and then put them back into .nb (.raw format that is not a flashable .nbf/nba)
3) Also describes how to extract various roms (Osrom, Extrom, RadioRom) from a different type of flashable rom .nbh Basically (not getting into depths, just to better describe it) .nbh is a .nbf/nba rom container used in flashable updates onto other HTC devices. This procedure is completely irrelevant to Sable/hw6915, but we can skip that.
4) This next thing is quite interesting - hexediting your .nb non-flashable rom file (in other words .raw) so that it's header would match the header of a manufacturer supplied .nb file (which is extracted from .nbh). This is done in order to trick the flashing utility/pda device into thinking that the new coocked rom is legit This might come in handy someday.
5) The next step is to make a .nbh file container using HTC ROM Tool by Dark Simpson. This is completely irrelevant because sable does not use .nbh
Anyways that is as far as I go with my backup which cannot be restored.

pdocwrite
Right now Im researching the possibility to just simply restore the osrom using pdocwrite utility form itsutils package. It seems the only simple, clear (and possible) option w/o cooking.
But I have some questions regarding that:
1) If my partitions are as follows :
63.94M (0x3ff0000) TrueFFS
| 3.06M (0x30fc00) Part00
| 3.19M (0x330000) Part01
| 56.75M (0x38c0000) Part02
51.22M (0x3337e00) TRUEFFS
| 3.06M (0x30fc00) Part00
| 3.19M (0x330000) Part01
| 56.75M (0x38c0000) Part02
STRG handles:
handle f3f54ee2 51.22M (0x3337e00)
handle 93f54212 56.75M (0x38c0000)
handle 13f54026 3.19M (0x330000)
handle 33f54002 3.06M (0x30fc00)
What to dump - just the 56.75megs form 93f54212 handle or all 64 megs I can access using this handle? As I understand that the little partitons (first little) are also part of osrom containing xip and spl, but I dont want to change the SPL nor other things, just flash the Spanish rom with a copy of an English hw6915 rom which also happens to have additional software like tomtom for example.
2) And the second is about CID. As b0ris also I'm botherd about the G3/G4 thing. My bootscreen shows
English iPAQ 1.00.00
1.21UK
Spanish iPAQ 1.00.00
1.50
So I guess that I have G3 CID lock, but which tool should I use to unlock?
3) Can I even pdocwrite the OsRom when it is used by windows mobile? Thou guys developing aWizard say yes (I studied their bat file which executes the same pdocwrite and pdocread utils)http://forum.xda-developers.com/showthread.php?t=252957&highlight=awizard

rx-8 said:
4) This next thing is quite interesting - hexediting your .nb non-flashable rom file (in other words .raw) so that it's header would match the header of a manufacturer supplied .nb file (which is extracted from .nbh). This is done in order to trick the flashing utility/pda device into thinking that the new coocked rom is legit This might come in handy someday.
Click to expand...
Click to collapse
I adapted tadzio tools and mamaich tools to fit ipaq hw69xx rom format. The problem in the upgrade. Some checksum/certificate verification made the upgrade fail. I don't know if this comes from the RUU or from the device.
Someone sent me a USB Monitor log, but I wasn't able to read it... It was a .dmslog... If you know more about this file format, tell me!
The question I would like to answer is: Does the RUU tool send the checksum data to be verified on the device (hard to fix) or checks it on the PC, then send to the device (simple crack!)...
A simple way to answer it would be to upgrade the device using an official ROM, tell me what ROM you used (Orange, Bouygues, German, Spanish) and we'll see if the additional datas are sent or not.
If you got the solution about this, I have some ROMs... ROM headers are OK, ROM can be decompiled as any official ipaq ROM (except the Orange one), but ROM cannot be upgraded...
Of course pdocwrite should write, but we have to find where the CID lock is

CID in hw6915
I think one developer may have the answer to our questions about he cid
wikidorg said:
Well, I tooked the french Orange sable_ruu, and works everytime when flashing my 6915... The only rom for that update utility is in french.. i looked on internet and i've found sp's from HP, downloaded all, but none in English... Just for fun, i've hexedit every one of these sp's CEOS.nbf with that working french header from original Orange sable update...Then i flashed using sable_ruu from Orange package and i changed 3 or 4 different languages... it worked everytime, all was ok... but still no English CEOS.nbf in order to change language to English using the same method... So now i am looking for HP 6915 original softpack from HP, and that should also work in the same manner... If someone have it, i can give a try... Meanwhile, that's no problem for German, Spanish, Italian and Dutch (i think) languages... These are the only softpacks i've found till now...
Click to expand...
Click to collapse
He explains some of his techniques in this thread http://forum.xda-developers.com/showthread.php?t=325051&page=3
b0ris747 said:
Of course pdocwrite should write, but we have to find where the CID lock is
Click to expand...
Click to collapse
It's a pitty though he didn't mention what he'd done with the CID lock thing.
I already PM him this morning but no response yet. Lets just give him a little bit of time and hope for the best
b0ris747 said:
I adapted tadzio tools and mamaich tools to fit ipaq hw69xx rom format
Click to expand...
Click to collapse
What did you change exactly? I used the latest mamaich tools from
http://forum.xda-developers.com/showthread.php?t=249836
And using the -nosplit flag my rom was successfully prepared and after that viewed (e.g extracted from the prepared.bin file) w/o any hassles. I checked the directory tree and it seemed ok (many files and the commandline output in txt file reached 3MB. I checked it too and there were no errors)
The making of the initial .nb file also seemed successfull. Anyways please post here what changes have you made to mamaich tools.
b0ris747 said:
Someone sent me a USB Monitor log, but I wasn't able to read it... It was a .dmslog... If you know more about this file format, tell me!
Click to expand...
Click to collapse
Well if I ever have a file w/o extension or with unknown extension or purpose I simply try viewing it with far manager. Usually there is some readable text like the program name and version number with which the file was made. So just download that program/util and try opening/editing/viewing the file
BTW my devices are original HP (One English and one Spanish) with no operator's contract bugging me So please upload your English rom to this forum, rapidshare or my FTP server.
You may want to open the below link in IE or some FTP client app.
ftp://xda:[email protected]:82
I would very much appreciate it because I only have my dumped .nb rom

rx-8 said:
What did you change exactly? I used the latest mamaich tools from
http://forum.xda-developers.com/showthread.php?t=249836
Click to expand...
Click to collapse
if (argv[argc][1] == 'i')
{ rate=0x10089; step=0x10000; skip=0x89; }
it's in the last page of the mamaich thread, and I created a specific thread on the hw69xx forum
rx-8 said:
And using the -nosplit flag my rom was successfully prepared and after that viewed (e.g extracted from the prepared.bin file) w/o any hassles. I checked the directory tree and it seemed ok (many files and the commandline output in txt file reached 3MB. I checked it too and there were no errors)
The making of the initial .nb file also seemed successfull. Anyways please post here what changes have you made to mamaich tools.
Click to expand...
Click to collapse
Yes, the ROM stored in DOC is un-encapsulated, unlike current upgradable ROMs. That's one of the points that makes official ROMs upgradable. The other point is "What's contained in the unknown data zones, is it sent to the device for checksum verification or can we bust this verification by cracking RUU?"
rx-8 said:
Well if I ever have a file w/o extension or with unknown extension or purpose I simply try viewing it with far manager. Usually there is some readable text like the program name and version number with which the file was made. So just download that program/util and try opening/editing/viewing the file
Click to expand...
Click to collapse
try to find some informations... I didn't find any and used the same software as he used...
rx-8 said:
I would very much appreciate it because I only have my dumped .nb rom
Click to expand...
Click to collapse
There is another ROM dump available here on the forums

I can dump my 6965 ROM for you if you like. This is the Australian (English) model.
http://h10010.www1.hp.com/wwpc/au/en/sm/WF05a/1090709-1113753-1113753-1113753-1117925-12573438.html

Please dump bootloader too if possible.
If you can dump the bootloader part, it would be great to have it.
I'm asking this because in sable_RUU I'm seeing weird things
-The updater seem to be made to all hw6xxx series
-Very easy to track!
-Seem to be made for wdata command and wdatas command.
So my new question (last one was: "are the extra data of the NBF sent to the device, or checked by sable_RUU?") is:
"In bootloader mode, do your have wdata command or wdatas command?"
And:
"Is it just for hw65xx devices (if confirmed to work) or is it because of some preproduction devices who have a special bootloader (like the HERMES)?"
And that's why having a backup of an unmodified bootloader would be great! Just in case we need it later!

domp using what?
Hi!
I know that it is impossible to dump IPl using pdocread, so I can dump only the SPL (To be frank I dont know the offset and size of the SPL) so if you can link me to a SPL dump manual that would be very nice. If not I can give you my whole Osrom partition dump (Including the xip and other stuff - the 6.25megs before real Osrom) (see my ftp rx-8_en_dump folder)
If you want me to dump bootloader using bootloder mode I must say that I wasnt able to access it (pressing action button+power+soft reset) any suggestions?

Similar post on Sable flasing!
http://forum.xda-developers.com/showthread.php?p=2577170#post2577170