Related
Hi,
I would like to extract 2 dll from GERMAN Rom.
I am intersted to msimda.dll and msimde.192.dll and i ma interested to learn how to work with universal rom.
But it drive me crazy...
I have read all the day this forum but i can't go on.
This is my last experiment
nkge.nba is qtek german rom (decoded)
mkdir files1 files2
dump nkge.nba -o 00000400 -e 001d2100 xip1.nb <-Offset From Universal Wiki
dump nkge.nba -o 00310000 -e 002d0000 xip2.nb <-Offset From Universal Wiki
dumprom -5 -d files1 xip1.nb <-Give me an error (after 27Files) :
error decompressing 90702000L0001f68d
fwrite: Invalid argument
error writing uncompressed data
dumprom -5 -d files2 xip2.nb <-OK
I have 59 files but there are no msimge.dll and msimge.192.dll probably they are in first xip block that give me an error.
Can you help me please?
Wat i am doing wrong?
byte.
plese somebody could help me?
Just a litle information or a link to read and study. i have searched all over the forum... but i am still blocked.
Hi,
try to read this and then search on the forum for imgfs tools.
I've extracted files sucessfully with those tools but not directly from the device instead from a nbf file.
Hope this will be useful.
Sergio.
tripledes said:
Hi,
try to read this and then search on the forum for imgfs tools.
I've extracted files sucessfully with those tools but not directly from the device instead from a nbf file.
Hope this will be useful.
Sergio.
Click to expand...
Click to collapse
Yes...thankyou very much for your reply.
I have just readed these posts but i can't go on.
I have nk.nba that is my Rom image decoded with HTC64 "Extended ROM Tool.exe" .
So i am trying with dumprom.exe and with viewimgfs.exe with the procedure described by mamaich in http://forum.xda-developers.com/showthread.php?t=249836
I can't extract file.
ViewImgFs (after a lot of " Unknown header type, FS_DATA_TABLE??") stop with message:
"C:\Documents and Settings\stefano\Desktop\HTC\imgfstools>Error! ProcessFixups: cannot map dump\dhcp.dll\s15627"
And i have a "dump" directory with this structure
dhcp.dll <DIR>
eapchap.dll <DIR>
iexplore.exe <DIR>
jscript.dll <DIR>
urlmon.dll <DIR>
ws2instl.dll <DIR>
Only file with same name of directory listed before.
Can you help me with step by step indication please?
1) To extract from rom upgrade (nk.nbf):
Code:
alpinenbfdecode.pl -r nk.nbf nk.nb
mkdir files ; rdmsflsh.pl -d files nk.nb
2) To extract from device, follow instructions here, but replace "FLASHDR" for "TrueFFS" in Universal (instructions are for Hermes).
Then you get "File02.raw" which contains dumped imgfs, files can be extracted either with mamaich viewimgfs.exe or itsme rdmsflsh.pl.
3) If none of the above works, try to dump the files from the device using mamaich TestWM5.exe or Buzz's grab_it!.
Good luck
pof said:
1) To extract from rom upgrade (nk.nbf):
Code:
alpinenbfdecode.pl -r nk.nbf nk.nb
mkdir files ; rdmsflsh.pl -d files nk.nb
2) To extract from device, follow instructions here, but replace "FLASHDR" for "TrueFFS" in Universal (instructions are for Hermes).
Then you get "File02.raw" which contains dumped imgfs, files can be extracted either with mamaich viewimgfs.exe or itsme rdmsflsh.pl.
3) If none of the above works, try to dump the files from the device using mamaich TestWM5.exe or Buzz's grab_it!.
Good luck
Click to expand...
Click to collapse
Thankyou... just another info..please.
I would like to extract file fro a complete German rom.
I am trying with nk.nbf extracted from UNI_QTEK_13096_185_10900_GER_Ship.exe .
Why did you suggest to me to use "alpinenbfdecode" i have an Universal.
I decode my nbf files with
http://buzzdev.net/index.php?option=com_content&task=view&id=65&Itemid=1
is this wrong?
Sorry for my questions but i have not Perl on my pc and i would like to know if is realy necessary to install it.
So just for learning... can you tell me why is wrong the operations that i am doing?
Thankyou very much!
Bye
slevin said:
Why did you suggest to me to use "alpinenbfdecode" i have an Universal.
Click to expand...
Click to collapse
alpine, magican, universal... they use the same NBF format version, so the script is also valid to decode universal NBF files.
slevin said:
I decode my nbf files with
http://buzzdev.net/index.php?option=com_content&task=view&id=65&Itemid=1
is this wrong?
Click to expand...
Click to collapse
This produces a decoded file (.nb), same as if you would run "alpinenbfdecode.pl" with -d parameter (decode), but I suggested you to use it with -r which outputs a RAW file, because rdmsflsh.pl expects a raw file and not a decoded file.
AFAIK the decoded file contains a header while the raw file doesn't, in the German Qtek ROM you said, the header looks like this:
Code:
00000010 51 54 45 4b 5f 31 30 32 20 20 20 20 20 20 20 20 |QTEK_102 |
00000020 47 45 52 20 20 20 20 20 31 2e 33 30 2e 39 36 20 |GER 1.30.96 |
00000030 20 20 20 20 20 20 20 20 55 6e 69 76 65 72 73 61 | Universa|
00000040 6c 20 20 20 20 20 20 20 30 20 20 20 20 20 20 20 |l 0 |
00000050 37 30 30 30 30 30 30 30 31 30 30 30 30 30 20 20 |70000000100000 |
00000060 30 20 20 20 20 20 20 20 31 36 31 31 31 31 31 30 |0 16111110|
00000070 30 30 30 30 30 30 20 20 61 39 62 33 61 64 39 35 |000000 a9b3ad95|
Probably someone more experienced with the formats can tell you the exact differences, otherwise if you know a bit of programming you can look at the program's source and try to figure out yourself
slevin said:
Sorry for my questions but i have not Perl on my pc and i would like to know if is realy necessary to install it.
Click to expand...
Click to collapse
Try the other methods which do not involve using perl, if you don't success doing what you want then install perl, it's just 5 minutes to do it and you'll benefit from many .pl applications from itsme... the process to install it and all the needed modules is explained on the wiki page I pointed you before
slevin said:
So just for learning... can you tell me why is wrong the operations that i am doing?
Click to expand...
Click to collapse
Sorry I don't know for sure, probably you are using an encoded file and the program you use to extract the files from it expects a raw file, I guess you can use prepare_imgfs.exe to fix this, but I'm not sure... you should better experiment with the tools until you accomplish your goal
ThankYou
Sorry for my delay ad thankyou very much for your help.
It works fine!
Now i am going to try to replace the two dll files and then i would like to build a custom cab to put in the extended rom.
Thankyou.
Hi!
I need your help!
I have an Airis T620 PPC, the official patch from the manufacturer's site for WM5 bricked my PPC.
The AirisT620 is a MIO P550 clone, and I've downloaded the WM5 ROM for Mio P550 (MioP550 - Osc260A R05_P09.nb0) and I've intalled it succesfully on my AIRIS.
BUT, I'd like to dump the WM5 of my friend's AIRIS to a *.nb0 file to upload to my PPC. I've downloaded itsutilsbin-20070705.zip and created a RAW image.
Here's the list of the Parts:
C:\itsutils>pdocread -l
127.00M (0x7f00000) SMFLASH
| 1.12M (0x11fc00) Part00
| 1.88M (0x1e0000) Part01
| 26.63M (0x1aa0000) Part02
| 97.38M (0x6160000) Part03
976.50M (0x3d080000) DSK1:
| 976.38M (0x3d061600) Part00
STRG handles:
handle 63d1c926976.38M (0x3d061600)
handle a3f5081e 97.38M (0x6160000)
handle a3f5012a 26.63M (0x1aa0000)
handle 23f50106 1.88M (0x1e0000)
handle c3f74f2a 1.12M (0x11fc00)
disk 63d1c926
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk a3f5081e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk a3f5012a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 23f50106
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk c3f74f2a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I used this to create the RAW image:
Pdocread -w -d SMFLASH -p Part02 0x0 0x1aa0000 Part02.raw
If I try to make an *.nb0 directly I get the following error message:
C:\itsutils>pdocread 0 0x1aa0000 asd.nb0
CopyTFFSToFile(0x0, 0x1aa0000, asd.nb0)
ERROR: ITReadDisk : read 00000000 bytes - A device attached to the system is not
functioning.
How can I convert the raw to nb0, or how can I dump the ROM directly to nb0?
Thank you for your help!
Hi again!
I tried several methods during the weekend. All failed somewhere.
First I tried to dump the OS to hex.
C:\itsutils>pdocread -h 0xc3f0518e 0x0 0x1aa0000 OS.nb
The error message was:
CopyTFFSToFile(0x0, 0x1aa0000, OS.nb)
ERROR: ITReadDisk : read 00000000 bytes - A device attached to the system is not functioning.
the itsutils.log said:
ERROR: DeviceIoControl(FL_IOCTL_READ_SECTORS) - A device attached to the system is not functioning.
than I tried:
C:\itsutils>pdocread.exe -n 2 0x0 0x1aa0000 OS.nba
error:
ERROR: ITTFFSGetInfo - A device attached to the system is not functioning.
WARNING: using default 512 bytes for sectorsize
CopyTFFSToFile(0x0, 0x1aa0000, OS.nba)
ERROR: ITReadDisk: outbuf==NULL
- A device attached to the system is not functioning.
after that I tried using bkondisk, and bksamsungflash:
C:\itsutils>prun bkondisk -i
in the bkondisk.log:
ERROR: kioctl(FLASH, init1) - The network request is not supported.
error initializing flash
bksamsungflash gives the same error in its log
And my last try was:
C:\itsutils>Pdocwrite -w -d SMFLASH -p Part02 Part02.raw 0x0 0x1aa0000
CopyFileToTFFS(Part02.raw:0, 0, 01aa0000)
and the last error message was:
ERROR: ITWriteDisk - The media is write protected.
How can I acquire the D-O-C password for my PDA?
Anyone has any ideas how to step further?
P.S.
The policies in HKLM\Security\Policies\Policies\00001001 is set to dword '1'
And I think my PPC is missing the IOCTL Api, how can I install it on my PPC?
Is it more simple using SPB backup.. say backup a good version of the system (without PIM) and flash over?
Hi myc!
Yes, I am using SPB backup to backup my personal files, but in this case I need to acquire the operating system of my PDA, witch can't be done with SPB backup.
Hi! (For borisbme Szia!)
Here I summarize my experiences with T620.
NOTE: with flashing you can easily have an expensive paperweight. I'm not an experienced rom cooker, with the below things you will risk that you make your device a brick. Try this at your own risk!
First take a look at the MioP550 - Osc260A R05_P09.nb0 file. The header structure seems to be rather straightforward.
0x00: "Pocket_PC_2005" \x00 \x00 \x00
0x10: 4 bytes : offset of the 1st section
4 bytes : length of the 1st section
4 bytes : checksum
4*'\x00'
0x20: "MS_IPL" som '\x00's
0x30: 4 bytes : offset of the 2nd section
4 bytes : length of the 2nd section
4 bytes : checksum
4*'\x00'
0x40: "OS_IMAGE" some '\x00's
0x50: 4 bytes : offset of the 3nd section
4 bytes : length of the 3nd section
4 bytes : checksum
4*'\x00'
0x60: "UBOOT" some '\x00's
I believe the 1st secion is the update loader , the 2nd is the actual update in MSFLSH50 format (-acer type) and the 3rd is UBOOT update.
Let's not touch the IPL and UBOOT section for a while ;-)
Based on the above information you can split the image into 3 parts and change the OS_IMAGE part.
I noticed that the checksum is for verification purpose but it does not prevent the flashing of an image with wrong checksum. I learned that because I changed the checksum to FFFFFFF to see how flashing reacts, but after a few "Bad checksum, press any key" messages I accidentally flashed my T620 with the above P550 ROM :-(
Let's look at the OS_IMAGE part.
If you want quick dump, you can try prepare_imgfs "saved OS_IMAGE file" -n -acer and view_imgfs , but you can further decompose the file.
I wrote it's "-acer" type, because it has 512 bytes sectors padded with 8 extra bytes. If you remove the padding then you have a clean MSFLSH50 file you can manipute with msflshtool.
Here I can see some difference between the P550 and T620. The 1st sector is the MBR and the partition sizes are different for the 2 device. The 2nd sector is still MSFLSH50 header, I don't know the structure, so would not change that. My assumption was, that it the file sizes are the same, it would not hurt to replace parts ;-)
One can go further with the P550 partition sizes and change T620 dumps to fit into it.
With the following little python script you can split the OS_IMAGE into parts. Do not comment the code , I not a skillful coder;-)
Code:
from binascii import hexlify
from struct import unpack
parts = (("part00",0x8FE),("part01",0xF00),("filler",0x200),("part02",0xD500))
infile = open("OS_IMAGE.dat","rb")
## MBR
mbr=open("mbr.dat","wb")
data = infile.read(520)
mbr.write(data)
mbr.close()
## HDR
hdr=open("hdr.dat","wb")
data = infile.read(520)
hdr.write(data)
hdr.close()
for (part,size) in parts:
print "Extract part ",part
ofile = open(part+".dat","wb")
for i in range(0,size):
data = infile.read(512)
marker = infile.read(8)
ofile.write(data)
ofile.close()
print "Extract rest"
ofile = open("rest.dat","wb")
while True:
data = infile.read(512)
if len(data) == 0:
break
marker = infile.read(8)
ofile.write(data)
ofile.close()
part00 corresponds to the "pdocread" dumped part00 ( I guess it's the bootloder)
part01 corresponds to the "pdocread" dumped part01 ( I guess it's the kernel partition)
part02 corresponds to the "pdocread" dumped part02 ( It is the IMGFS OS image )
With the following little python script you can combine back the parts into a "new" OS_IMAGE you can use to replace the corresponding part in the ".nb0"
Code:
from binascii import hexlify
from binascii import unhexlify
from struct import unpack
from struct import pack
parts = (("part00",0x2,0x8FE,"fdfffbff"),("part01",0x900,0xF00,"fdfffbff"),("filler",0x0,0x200,"fffffbff"),("part02",0x1800,0xD500,"fffffbff"))
outfile = open("NEW.dat","wb")
## MBR
mbr=open("mbr.dat","rb")
data = mbr.read(520)
outfile.write(data)
mbr.close()
## HDR
hdr=open("hdr.dat","rb")
data = hdr.read(520)
outfile.write(data)
hdr.close()
for (part,start,size,mark) in parts:
print "Combine part ",part,start,size
ifile = open(part+".dat","rb")
for i in range(0,size):
data = ifile.read(512)
if data == '':
print "Less data"
data = '\xff'*512
if(data == '\xff'*512):
marker = unhexlify('ffffffffffffffff')
else:
marker = pack("<L",start+i)+unhexlify(mark)
outfile.write(data)
outfile.write(marker)
ifile.close()
print "Combine rest"
ifile = open("rest.dat","rb")
while True:
data = ifile.read(512)
if len(data) == 0:
break
marker = unhexlify("ffffffffffffffff")
outfile.write(data)
outfile.write(marker)
ifile.close()
outfile.close()
The part00 and part01 is smaller in case of T620 with 0x100*512 bytes compared to P550. Add some '\FF\s to have the same size.
The part02 is bigger in case of T620, but the end of it is full of zeroes. Remove some zeroes to have the same size.
If you bring T620 dumped files to same size, you can replace those parts, combine back to OS_IMAGE and replace that part in the .nb0
The part02 can be fully edited with imgfs tools.
The part00 and part01 has SRPX signature, so you can use SRPX2XIP and then xipport or dumprom to check the content.
The .nb0 got this way can be flashed using DNW.
The next step would be the cooking ;-)
With imgfs tools you can easily remove/add packages. The unfortunate thing is that if you change AKU level then you might have to modify the 2 XIP parts as well. I have no experience with that (so far).
Also for porting WM6 it would be really good the have the pdocread dump of the P560 partitions ;-)
Hope this helps a little bit for proceeding with T620/P550 cooking/porting.
NOTE: with flashing you can easily have an expensive paperweight. I'm not an experienced rom cooker, with the above things you risk that you make your device a brick. Try this at your own risk!
Wowww!!
This post is really Interresant !
I have a mio p550, and i have an mio p560 dump !
Anyone can help me how to port the mio p560 rom to my p550 rom ??
great thanks !!!
Airis T620 Raw files
Hi,
I've dumped my ROM, and now I have the raw files. Can anyone tell me how to convert them back into a usable ROM? Thanks in advance.
Hi there,
I've done some reverse engineering on the LG DZ files, and here is the layout of these files.
DZ File Format
Code:
Offset Length (bytes) Description
0x0 0x8 Magic code "MSTXMETX"
0x8 0x2 Unknown, same value in all files (value 0x01)
0xA 0x2 Separator ? (value 0x0)
0xC 0x2 Unknown, same value in all files (value 0x0B)
0xE 0x2 Separator ? (value 0x0)
0x10 0x6 Unknow, value differs from file to file
0x16 0x2 Unknown, same value in all files (value0x01C8)
0x18 0x8 String, phone model ? (value "KS20")
0x20 0x50 String, file title ?
0x70 0x1C Two null terminated string concatened ("[chipmodel]\0[osname]\0")
0x8C 0x80 String, DZ filename
0x10C 0x20 Separator (filled with 0xFF)
0x12C 0x10 Header MD5 hash
0x13C Variable Concatened subfiles (see Subfile format)
-- 0x78 Offset Table, unknown useage (see OffsetTable format)
-- -- Optionnal data, present in some DZ file (unknown)
Subfile format
Code:
Offset Length (bytes) Description
0x0 0x4 Magic code "SSTX"
0x4 0x2 Unknown, same value for all subheaders (value 0x01)
0x6 0x2 Separator ? (value 0x0)
0x8 0x2 File Type ?
0xA 0x6 Separator ? (filled with 0x0)
0x10 0x4 Data length
0x14 0x80 Filename, null terminated string
0x94 0x10 Separator (filled with 0xFF)
0xA4 0x10 Uncompressed data MD5 hash
0xB4 0x10 Subheader MD5 Hash
0xC4 Data length Gzip compressed data
File type (in subheader)
Code:
Type Filename Description
0x3 amss.mbn AMSS modem
0x8 partition.mbn Partition table
0xA qcsblhd_cfgdata.mbn QCSBL header
0xB qcsbl.mbn QCSBL
0xC oemsblhd.mbn OEM boot header
0xD oemsbl.mbn OEM boot
0xE amsshd.mbn AMSS modem header
0x13 appsboothd.mbn APPS boot loader header
0x14 appsboot.mbn APPS boot loader
0x15 FLASH.bin
0x16 apps.mbn APPS
It's not complete, but that's a start.
I also made a tool to extract the subfiles contained in the DZ file (see attached file).
Hope this helps,
JP.
Check also the tool to extract the content of the Flash.Bin file : LGFlashParser
Great news !
I tested your soft with different lg ks20 dz files downloaded on the web and files seem to be extracted as they should. I didn't try to flash though, as I'm at work and I don't have usb cable here.
Now we still need to find how to edit those files (*.mbn and especially flash.bin which contains windows file system). Anyway, it's a great step towards lg rom cooking. Thanks again!
I have updated the DZExtract tool...
It now checks all the known MD5 hash, so the extracted files can be considered valid.
Here are the command line options :
Code:
dzextract.exe [options] path [outputpath]
options : default -p
-p Print and check header information
-x extract subfiles
path : path to dz file
outputpath : path to output directory (must exists)
Hope this helps,
JP.
Wow, sounds great!
Thank you very much for this excellent work.
it's possible to extract also the files of .mbn or FLASH.bin ?
For mbn files you can try with this soft :
http://forum.modopo.com/diskussionen-rund-ums-modding/t-19197-qc-bqs-firmware-analyzer.html
Great.....a good start............
How does it work? Can it work in vista? Coz i double click the DZextract.exe, a dos window came out for 1 sec then closed and nothing happen.
raykisi said:
How does it work? Can it work in vista? Coz i double click the DZextract.exe, a dos window came out for 1 sec then closed and nothing happen.
Click to expand...
Click to collapse
This is a command line tool, so you need to open a command window and follow the instructions.
About the contained files :
The flash.bin seems to be the windows image (found old infos here : Rom file format)
The mbn files reflect the firmware structure :
- QCSBL = QC Secondary Boot Loader
- OEMSBL = OEM Secondary Boot Loader
- AMSS = Advanced Mobile Subscriber Software
...
(infos from the link posted by DomZ)
JP.
Great application !
Files identical (same CRC) from unbranded to branded roms:
apps.mbn
appsboothd.mbn
oemsbl.mbn
oemsblhd.mbn
partition.mbn
qcsbl.mbn
qcsblhd_cfgdata.mbn
All the remaining files are different, inclueding the flash but that is obvious.
(amss.mbn, amsshd.mbn, appsboot.mbn, Flash.bin)
I guess we have to compare the unidentical mbn files to find out what prevents the unbranded roms to work in phones with branded NVs.
Then if nothing is conclusive we will have to check the flash itself.
mbn files seem plain/uncompressed binaries.
In fact I believe the CID checks are performed by amss.mbn which seems to be somehow the true bootloader (It is a true ELF binary and likely the very first to be running)
This is just a guess based on my todays reading and disassembling: the msm7200 has two processor, and one is dedicated to the radio functions. This processor actually runs the AMSS file which is an arm elf executable (you can to disassemble this file with IDA).
Apparently, the AMSS part is based on an L4 microkernel, and running iguana embedded os (see here).
On the QC BQS analyzer page, the boot process is explained (it's for another phone, but I think it's the same). The QCSBL (Qualcomm secondary boot loader) load the OEMSBL (probably on the first processor) and then also load the AMSS Elf.
Both the oemsbl and the amss run in parrallel (i guess they communicate with some kind of IPC mechanism).
After that, the oemsbl start the windows kernel.
I think, we should concentrate on the flash.bin file, as i think the other files are either encrypted or at least signed.
My post is just a guess as it's very hard to find information on the msm7200 processor and as I do not have a KS20 phone (nor a qualcomm based phone) to check all these informations.
JP.
The other files are plain text. They may however indeed be signed although this is not sure, since they did not bother to add any kind of encryption (at least not that I could spot) , perhaps they did not bother adding a signature either. I think LG did not expect us to access these files/ressources from the phone, I do not expect them to be accessible through software (running on the phone that is) we can actually access it thanks to the leaked service tools from LG using their recovery mode.
I think you are right about LG as I found that the files contained in the DZ file were supposed to be crypted : when disassembling the LG sofware, I found that the fonction that extracts the subfiles could also decrypt the files, however none of the DZ files I have are encrypted.
But regarding the qcsbl file for example, I'm not so sure : this file is certainly built (or at least coded) by Qualcomm and is probably part of the SDK they send to their customers.
I've seen posts about similar phone using qualcomm chipset reporting that some of the bootloaders were signed.
JP.
Spend money...
Hi,
its cool what you have find out about the DZ Format. But the problem is that misterjp has no KS20. What do you think if we all spend a little money, so that misterjp can buy a KS20 because with this he can find more about the DZ Format? If we know a lot of the DZ format in the future someone will release new Windows Mobile Version.
Dear Dussel
in fact need to knew more about .mbn file format ... not .dz (that is simpliest pack method /container for multiple .mbn /)
on net i'm saw .mbn extractor ... but not .mbn creator ... that format more complicated than .dz - so better to spend money for that, who can work with .mbn - it's more perspectivelly, or anybosy, who can find alternate way to flash (without .mbn)
so firstly take a look to :
1. MBN-Resourcer = Qualcomm firmware resource viewer
2. QPST - Qualcomm Product Support Tools
3. QXDM - Qualcomm eXtensible Diagnostic Monitor
4. QC BS analizer - similar to mbn-resourcer, but other maintainers
5. BREW Resource editor - it's more for high level programming ...
that will be primarilly tools for decryting ... but crypting - possible need signing key for creating .mbn and that key must be trusted by device ...
@ DomZ
Thanx for info.
@ misterjp
Nice work.
@ all
Like DaLiV said. I think also. It is an good idea to collect more infos about Qualcomm. Many manufacturer use Qualcomm Hardware...
Samsung, LG, Motorola, Huawei... many more.
AMSS is ever used. If Qualcomm MSMxxxx works as heart of mobile.
Best Regards
Edit...
1. I have looked into QPST 2.7 Build 264 (good Description in Manual) See Screenshot...
2. It looks that RSA2048 Signature at End of AMSS is not used.
Check amssHD.mbn
First 2 adresses the same and means End of AMSS... And 0x1D is 00 instead 01
Why the other 2 adresses exceed AMSS? I don't know...
So in theory Manipulation of AMSS seems possible.
3. BREW is "obsolete". Not an part of AMSS. Because the WM OS is used as an "Layer"...
4. NVM folder I can see... So I think also NV items are used...
5. Funny GZIP is used also from BenQ for EF91... To hide AMSS...
I agree with you. Now that misterjp has partially reversed dz format, we need to concentrate on files contained inside it (as you may all know, lgmdp can actually flash firmware from a directory containing mbn+bin files, not only dz, so there is no point in trying to reassemble a dz from a list of mbn files (at least, it's not a priority).
On the other side, misterjp has proved to be a good reverser on a format for which he doesn't even own a phone. To be totaly honest, (and as I already said on a french forum), he did this on my demand because I was not really efficient in reversing lgmdp. I'm pretty sure he could go further (and with no doubt could cook an english firmware, for those of you waiting for this). I think the least thing would be for him to have a phone to test his development. So misterjp, if you're ok to continue your work and would like some donations, don't hesitate to update your first post with a paypal link, at least til you get a phone.
Hi there,
Thanks for the support ! I did not have many time this week end, so I do not have many informations today : the flash.bin is using a Windows flash format, very easy to extract :
Code:
Offset Length (bytes) Description
0x0 0x7 Magic code "B000FF\n"
0x7 0x4 Image start adresse
0xB 0x4 Image Length
0xF --- List of memory block
-- 0x4 Always zero
-- 0x4 Image entry point
-- 0x4 Always zero
Each memory block is composed of
Code:
Offset Length (bytes) Description
0x0 0x4 Memory destination of block
0x4 0x4 Block size
0x8 0x4 Block checksum (sum32)
0xC --- Data
JP.
So,
I have sucessfully extracted the imgfs from the flash file. So here is the tool to do it.
It's a bit late, so I'm not giving explanation now, but I will !
To use the tool, just run
Code:
LGFlashParser.exe FLASH.bin
It will generate 3 files (BOOT, RAW and IMGFS), then you can use ImgfsToDump to extract the content of the IMGFS file.
At the moment, ImgFsToDump crash at the end of the processing (but the content is extracted), this is probably due to an invalid char in my generated imgfs, but it's too late to investigate.
Apparently, some files extracted from the imgfs part have no data. It could be related to the problem exposed before. I am working on this problem.
I have also checked the part_2_RAWFS : for this file, you can use the dumprom utility to extract it's content :
Code:
dumprom.exe part_2_RAWFS.bin -5 -d dump-xip
Special Thanks
Abusalza (for the most initial start off guide)
Cmonex (for the “MOST” important finishing touches)
!Aman! (for all the testing and Hex edit helping)
Noonski (for being the inspiration to keep going )
Ervius (for developing the kitchen tool to perform all the operations)
In this forum there are many many tools from experts and likes for porting XIP, rebuilding dumped ROMs etc. This threads aims at showing or sharing what goes in the background of these automated tools and also aims at answering all the many unanswered questions about various factors of ROM cooking / editing I have come across in this forum
Suggestions / comments always welcome to make these tutorials even better
Index of Tutorials
Manual XIP Porting Guide: CLICK HERE
XIP Porting Updates from members: CLICK HERE
XIP Porting for Himalaya devices & others (Nokser): CLICK HERE
Misc XIP Updates: CLICK HERE
PagePool Changing Guide (for Diamond & Raphael): CLICK HERE
Gain More Storage Memory (Increase imgfs size) Guide: CLICK HERE
ULDR Partition Size Reduction Guide: CLICK HERE
MBR and MSFLSH50 Regions Screenshots: CLICK HERE
Gain More Storage Memory (compress imgfs) with LZX algorithm: CLICK HERE
Get High File System Index (!Aman!): CLICK HERE
Ervius's GUI kitchen thread to perform all operations, Noonski's amazing RunCC & AutoRun & SDAutorun tutorial thread
Ervius's post on patching nk.exe to change the EndRam address for more available RAM in device (original credits to cmonex )
Da_G's amazing new initiative to utilise the ULDR partition to upgrade ROM without re-flash
All the above guides and updates are compiled in pdf file also for offline reading, attached in this post as All Guides.zip
The imgfs Gain.zip is actually the 5th guide with pictorial seperatly put up for members who would want to refer only to that process
The Pictorial.zip is the 7th picture reference for offline reading
Donations for this hard work and research are much appreciated. Below are the links whom you may choose to provide those to
Donation to Abusalza, Donation to Cmonex, Donation to !Aman!, Donation to Ameet
Index of Threads (Manila related)
Ameet's Mode9 script editing ideas thread
l3v5y's tutorial thread for editing Manila files
NisseDILLIGAF's Manila Hash tool
Manual Full XIP Porting
Tools you need: (attached the tools in this thread for easy access)
HEX Calculator (recommended – HEX workshop (Not Free)), suggested Windows Calculator
XIPPort.exe
M’Reloc.exe
NBMerge.exe
Insert.exe
OS.nb.payload from 19965 build (shipped ROM)
Cup of nice strong Coffee (A Must)
Brief:
There are many different ways to port the XIP. Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers. As my friends, Noonski and !Aman! always say “Only numbers are just eye wash, core system is what matters the most” Based on this as inspiration, I am posting this guide for manual XIP porting. A few places you may find colors in this guide, these are to visually link the data for easy understanding
The only files removed from the ported XIP are (these are removed to keep the new XIP within the original size):
osaxst0.dll + osaxst0.dll.imageinfo.txt
hd.dll + hd.dll.imageinfo.txt
bmui.nb0 + bmui.nb0.imageinfo.txt
Process:
Prepare OEMXip base
Dump your original XIP.bin (from 19965 build) with XIPPort.exe, and click “write maps” to get MAP.txt in the OUT folder
Open the MAP.txt and go through what you will need to achieve for a full port. I advice to keep this MAP.txt as a backup, just in case
Click “make pkgs” to get “OEMXipKernel” and “MSXipKernel” folders inside \Files and \Modules
Delete MSXipKernel folders from \Files and \Modules both
Now our base OUT folder is ready with OEMXipKernel
Prepare MSXip donor
Dump your donor XIP.bin (from 20758 build) with XIPPort.exe, and click “make pkgs” to get “MSXipKernel” folder inside \Files and \Modules
Delete osaxst0.dll + osaxst0.dll.imageinfo.txt, hd.dll + hd.dll.imageinfo.txt and bmui.nb0 + bmui.nb0.imageinfo.txt to get the new XIP within the original RAM size. If you don’t wish to delete these files, then you will need to increase the “physlast” in ROMHDR.txt. Process of which is not covered under this guide
Copy the MSXipKernel folders from \Files and \Modules both to the \Files and \Modules in the base OUT folder
Now our OUT folder is ready to be ported with the OEMXipKernel and MSXipKernel
Now to proceed with the reallocing you need to re open the packages which have been created. Open XIPPort.exe and click "undo" then click “realloc P” to re calculate the reallocation addresses. Then click “write maps” to get the new MAP.txt file
Open this MAP.txt and look in the o32_realaddr and e32_vbase addresses. Busenum.dll must be the last entry in both tables. Here you may find overlaps of the modules in a few or most places (seen as !!!!!!!!!!!!!!!!!!)
These are the overlaps which need to be taken care of by reallocating the modules in Initialized Data and Virtual Base addresses
You need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
For example:
03f4c000 03fe3000 L00097000 Virtual base address of coredll.dll
03fe2000 03fe3000 L00001000 !!!!!!!!!!!!!!!!!!
03fe2000 03ff0000 L0000e000 Virtual base address of certmod.dll
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Meaning, e32_vbase address of cachefilt.dll is overlapping that of busenum.dll by 1000 (L00001000) Similarly e32_vbase address of coredll.dll is overlapping that of certmod.dll by 1000 (L00001000)
I recommend you use M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding imageinfo.txt files. Since the binaries (S000, S001...) must actually be relocated using M'Reloc, it is not enough to just adjust the values in the imageinfo.txt files
To calculate the revised addresses (in below example, the e32_vbase) of the overlapping module, open Hex Calculator. To do that you will need to know the e32_vsize of the overlapped module. To find that out open overlapped module (for e.g. cachefilt.dll) in M’Reloc.exe and see the e32_vsize (0000B000)
Now to correct the e32_vbase of cachefilt.dll, follow this calculation as a base (e32_vbase busenum.dll - e32_vsize cachefilt.dll = e32_vbase cachefilt.dll)
Meaning, (03FFA000 – B000 = 03FEF000) hence the correct e32_vbase address is 03FEF000
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Now since the cachefilt.dll is reallocated using the above calculation, the modules next in line above that will also have to be reallocated. Namely, certmod.dll (although not overlapping yet above the cachefilt.dll). To calculate the e32_vbase of certmod.dll you will need the revised e32_vbase address of cachefilt.dll which you got just now
I recommend writing down the e32_vbase, e32_vsize, o32_realaddr and o32_vsize of each module so it will be easier to calculate the correct addresses for reallocation)
Remember, you need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
To reallocate the addresses for o32_realaddr, follow the above calculation, only this time replace the e32_vbase busenum.dll with o32_realaddr and e32_vsize with o32_vsize
Now open the corresponding imageinfo.txt file for each module and change the e32_vbase and o32_realaddr address values in the txt file of the values mentioned with V= and D=, seen for e.g. like this
Module name: cachefilt.dll
e32_vbase: V=03FEF000
o32[1].o32_realaddr: D=01FFE000
You will notice that the FLASHDRV.DLL module has the realaddr at 2 regions. Although I have not found a way to calculate the difference between both regions but I change the values as per Abusalza’s MAP.txt
o32[1].o32_realaddr: D=01FCC000
o32[3].o32_realaddr: D=01FD4000
Since the OEMXipKernel modules never change, I only correct values of the ported MSXipKernel modules
This is helpful if the MSXipKernel modules ported from donor ROMs are similar in the sizes. If not then you will need to do the calculation and correction of values
Once through with the address reallocation, open XIPPort.exe and click “realloc P” to re calculate the addresses for writing maps. It will show you errors regarding some regions, ignore those and click “write maps”. Open the new MAP.txt and recheck for (!!!!!!!!!!!!!!!!!!) If none found that means the XIP has been ported well
Now click “build xip_out.bin” to create the resulting XIP to be inserted into the ROM .payload file. Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Build OS.nb for use in the ROM folder from the .payload you just updated with the new XIP. Please note these commands are for Diamond device. Please check with your device on the same before building
nbmerge.exe –kaiser OS.nb
Now put this OS.nb file in the ROM, put the boot.rgu from 19965 (shipped ROM) into the \ROM\XIP folder and do not include any of the OEMXipKernel or MSXipKernel folders in OEM & SYS folder while cooking. I observed for some reason, WinCeNls_WWE folder cannot be taken out of XIP and included in SYS. Device wont boot, so keep that in XIP (found a working solution by spocky12: Here (last quote)
Please note the insertion of xip_out.bin can also be done through XIPPort.exe directly
Before clicking “write xip_out.bin to:” replace the name “nk.nb” with “OS.nb.payload” and the address to “00320000” all without quotes
IMP: There may be chances that although the XIP is working fine, but the windows are seen as QVGA versions. The solution to that is either of the below
XIP & SYS of the same builds or
XIP and the OS\Gwes.exe from same build
Cook the new ROM with your favorite kitchen (whichever doesn’t do anything with the XIP) and use this OS.nb file as base template for the ROM with the new XIP
With this note, I hope this guide will serve many as a guiding light and answer many questions on manual full XIP porting. Happy porting
Members Porting Updates
This is where we showcase the updates on XIP porting provided by our kind forum members
Original quote - Cmonex
Code:
[COLOR=royalblue][B]Quote=ababrekar[/B] - Busenum.dll must be the last entry in both tables[/COLOR]
Actually the values are arbitary, even though Microsoft decided to place coredll.dll as the last entry, i.e. at the highest memory address, it doesn't really matter. So, the values are arbitrary, but of course only within limits: the addresses must be divisible by 0x1000 (pagesize of the platform), and they must be inside the memory range reserved for XIP. part of that is the dllfirst and dlllast values in ROMHDR.txt. The other part (the higher addresses, 0x03xxxxxx) are determined by the following way: IMGFS .VM tells you the limits for IMGFS memory range, and XIP is beyond that range. So, if your OS doesn't want to boot, you can check if IMGFS .VM is overlapping with XIP memory range as per your MAP.txt for xip and dump_memorymap.txt (or .VM folder, etc) for IMGFS.
For example if IMGFS ends at 0x03DE0000, then the higher part of your XIP must start later than 0x03DE0000. You can of course modify this to make more space for XIP
If xipport crashes on writing maps it means you definitely have some overlaps left in. So yes, best to work with the maps from the original XIPs and only use the final XIP map to verify you got everything right
[COLOR=red]Btw, XIPPort's insertion function was found buggy on one device once, but cannot remember the details. It wasn't my device, so just posting this as a possible warning[/COLOR]
Oh, same applies to ROMMaster.exe, it is buggy when you try to use that to extract the XIP some ROMs
[COLOR=royalblue][B]Quote=ababrekar[/B] - Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers[/COLOR]
Btw, coredll.dll replacement only works for that pre-WM6.1
And a last tip for [B]debugging [/B]if your OS doesn't want to boot: if you already checked that the maps are all ok and IMGFS doesn't overlap, etc., then if you have a new enough HTC device (for example HTC Athena and later is new enough), then go to SPL using mtty or putty or qmat and there the "task 37" command (without the quotes) will show KITL log, with lots of debug messages, that can be very helpful. (first you must issue "task 32", for "task 37" to work) - this doesn't appear to work on some Raphaels
Original quote - cruzzmz
Code:
If porting for [B][COLOR=teal]Zinc[/COLOR][/B]. After finish with all the MReloc, you need to Hex the S000 of nk.exe in the MODULES folder. The value can be found in MAP.TXT under the Modules
[COLOR=royalblue][B]Quote=ababrekar[/B] - 802FAA9C - 802faaf0 L00000054 rom_00 header: dlls=01f901fd-02000000 phys=80180000-803dc4fa, 24 modules, 10 files, 2 copyentries ext=8018265c ram=803dd000-83c00000 cputype=000001c2[/COLOR]
Open S000 in ur fav hex editor, then go to [B]Offset 1658[/B]
Change the original value i.e: [COLOR=red][B]802FAA9C [/B][/COLOR]and Hex edit it to [COLOR=blue][B]9CAA2F80[/B][/COLOR]
Original quote - DupinBJK
Code:
The addresses on the 80xxxxxx range should be on a [B]WORD [/B]boundary - Divisible by [B]4[/B]
Original quote - spocky12 (how to move wincenls to IMGF from XIP)
Code:
This is related to BootPhase key in boot.rgu. [URL="http://msdn.microsoft.com/en-us/library/ms885267.aspx"]According to Microsoft[/URL]
If this value is 0, then related filesystem is loaded prior to initialization of locale. But for this to work, the filesystem has to be loaded in Autoload key, like this :
[B][COLOR=red][HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\FLASHDRV][/COLOR][/B]
[B][COLOR=red] "DriverPath"="Drivers\\BuiltIn\\FLASHDRV"[/COLOR][/B]
[B][COLOR=red] "LoadFlags"=dword:1[/COLOR][/B]
[B][COLOR=red] "Order"=dword:0[/COLOR][/B]
[B][COLOR=red] "MountAsRoot"=dword:1[/COLOR][/B]
[B][COLOR=red] "MountAsBootable"=dword:1[/COLOR][/B]
[B][COLOR=red] "BootPhase"=dword:0[/COLOR][/B]
With this, autoload will regsiter access to the imgfs filesystem before wince.nls is loaded. Then, when it'll be required, if it's not present in xip, it should be found in imgfs
Here is where we showcase miscellanous updates on XIP porting / MBR / MSFLSH50 which doesnt fall under the above categories. These are the updates which are not harming the system in any ways if left as is. Yet just a know how or just in case
Removing modules from XIP: Original quote - Cmonex
Code:
You can always remove osaxst0.dll, osaxst1.dll, hd.dll, kd.dll, and also bmui.nb0 - the latter is just a SplashScreen saying your OS can't boot and reflash or something (I forget the exact text)
The other files are Kernel debuggers and similar, best to remove them, because it just takes up space and can also cause problems if you somehow manage to use the wrong versions of them. They are mapped directly to the Kernel memory space, and if your device uses a different range (i.e. you didn't keep your original debugger dlls), it will prevent the rom from booting
Also I found it's ok to remove (m)encfilt.dll and cachefilt (put them in IMGFS if you want them)
[I][B]Physlast [/B][/I]can be changed up to [I]ulramstart [/I]value without problems (of course not if you don't have enough space in the flash, but that's not really a real life possibility). Of course that also assumes we are not talking about some older devices that have the xip mapped to a different memory range than [I]ulramstart[/I]
You can move [I]ulramstart/ulramfree [/I]too if you relocate nk.exe data section (usually S002) with M'Reloc-nk. Also relocation is needed for any other modules (such as giisr.dll, on some non HTC devices) that have mappings similar to nk.exe (so they have a data section in the map that points into [I]ulramstart/ulramfree [/I]range). on HTC devices I didn't really see such modules so not a real problem usually
Increasing the free RAM (Part 1): Detailed explanation here by DupinBJK
Simple explaination for easy understanding: (the below values are from a sample MAP.txt and dump_memoryMaps.txt (View attachment Examples.zip)) for trying to explain what comes from where and the actual values may differ from your files
Code:
8019e9a4 - 8019e9f8 L00000054 rom_00 header: dlls=[COLOR=red]01f801fc[/COLOR]-[COLOR=black]02000000[/COLOR] phys=[COLOR=black]80000000[/COLOR]-[COLOR=blue]8030c7b3[/COLOR], 28 modules, 10 files, 1 copyentries ext=80002b4c ram=8030d000-83000000 cputype=000001c2
[COLOR=blue]8030c7b3 [/COLOR]- 8030c7b3 L00000000 End: highest physical address
The blue value that mentioned is the physlast value. In the dump_memoryMaps.txt, you will find:
Code:
01F7F000 - 01F7FFFF (4095 bytes): bthasplugin.dll
after which the dllfirst starts in MAP.txt with a difference of 1FD length and
Code:
03D66000 - 03D6FFFF (40959 bytes): bthasplugin.dll
after which the e32_vbase starts (03dcb000 - 03dd4000 L00009000 Virtual base address of wce_rex.DLL) in MAP.txt with a difference of 5B001 length
Increasing the free RAM (Part 2): by Ameet
Changed the size of ROM in G'Reloc from 83000000 to 83400000 and increased the ulRAMEnd to the same value (83400000) getting free RAM space of L0306C000 (I dont know how to translate this into the actual size in % or in bytes) but with the original of 83000000 the RAM space was L02C6C000
Having done this, I get about 62% free memory without TF3D and approx 54% free memory with TF3D at system start
Extracting the XIP from any ROM: Detailed explanation here by boggsie
More explaination about XIP processes & editing OS version on 1st splash screen: by FormerPalmOS
Code:
[B][COLOR=red]1) [/COLOR][/B]The Initial Program Loader copies the XIP partition from the FLASH to SRAM - in Diamond and Touch Pro there is a custom Samsung chip that includes both NAND FLASH and SRAM. The overall physical RAM space where this is loaded is also hard-coded - see below. The amount of RAM used is variable - this info comes from a header in the XIP section - basically how much RAM does the XIP need? What's left is what you get for program memory.
[B][COLOR=red]2) [/COLOR][/B]IPL executes a jump to a hard-coded address within the SRAM - this should be busenum.dll, which is why busenum.dll has to be at a specific physical and virtual memory location.
[COLOR=red][B]3) [/B][/COLOR]busenum.dll does its thing (not sure entirely what) but eventually calls nk.exe. nk.exe is the kernel. nk.exe loads the other modules, initializes the hardware (that's why nk.exe is device-specific), and initializes the filesystem and basic device drivers (again why those are device-specific).
[COLOR=red][B]4) [/B][/COLOR]Once this process has completed, the filesystem proceeds to load the imgfs filesystem and turn control over to the full OS.
The virtual memory map for WM consists of a number of slots. The memory management unit in the CPU translates virtual memory references into physical memory addresses. Every loaded dll or exe must occupy a portion of virtual memory for its code and will likely also use some of the available RAM for its data. The location within virtual memory where the code for a dll or exe is loaded is determined at load time unless the dll or exe is a module (everything in the XIP is a module) in which case the virtual memory location is specified during cooking. In the XIP, the location of the RAM used is also specified - the process of relocating a module in the XIP specifies the virtual memory location for the code and and data in the case of nk.exe, the physical RAM location.
There are four VM sections we care about (note - I'm taking some liberty here - these don't exactly correspond with what Microsoft refers to as a VM slot). Slot 0 runs from 0x00000000 to 0x01FC0000 (in the CDMA Touch Pro). The end of slot 0 is a function of the number of and size of the data regions for the DLL modules in the XIP. This number plus 0x1FC is stored in the ROM header (and can be examined in ROMHRD.txt) - it is referred to as dllfirst. This is also the slot 0 you see when you do G'Reloc.exe (the value in G'Reloc.exe is the last address of slot 0 plus one). These two must match!!! What the XIP uses must not overlap with what your ROM uses.
The next slot is the XIP DLL initialized data. This runs from dllfirst to dlllast. dlllast is fixed (in the Touch pro) at 0x02000000. The XIP DLL data sections are loaded starting at 0x02000000 and working backwards.
The next slot is again available for the OS and runs from dlllast to wherever the code in the XIP starts. You can see this in your XIP memory map - this again must match (the end of slot 1 in G'reloc.exe must match the first DLL virtual base address in your XIP - in mine this is 0x03DC0000). The XIP DLL and EXE code occupies from this virtual memory address to 0x03FFFFFF.
The OS will load DLLs and EXEs (other than XIP) into this slot starting at 0x03DC0000 and working backwards, then will move to the slot below 0x01FC0000. Recall, I'm using my numbers here. Any modules in the ROM will have their virtual memory slot and address pre-assigned. Any non-module DLL or EXE will be relocated to an available slot and VM address at load (this is why modules load quicker).
So in summary, my VM map looks like this:
0x00000000 - 0x01FC0000 - OS available (G'Reloc.exe slot 0)
0x01FC0000 - 0x01FFFFFF - XIP data
0x02000000 - 0x03DC0000 - OS available (G'Reloc.exe slot 1)
0x03DC0000 - 0x3FFFFFFF - XIP modules code
The actual physical XIP RAM address starts at 0x80000000 in the Touch Pro (this is physfirst in the ROMHDR.txt) and ends at 0x83400000 (in the Verizon Touch Pro - this is ulRAMEnd). The XIP is copied from the NAND flash starting here with the ROM header occupying 0x80000000 - 0x80001000. Then come the various XIP components, hopefully none of which overlap. The XIP should end at or before a ROMHDR.txt value called physlast. Thus physlast - physfirst is the size your XIP has to fit into.
Following physlast comes ulRAMStart - this is where the RAM required for nk.exe is located. This RAM ends at ulRAMFree. What remains after ulRAMFree until ulRAMEnd is available for your OS. Shrinking your XIP and relocating nk.exe will allow you to recover wasted space and give you more program memory, but it buys you nothing to move a module out of the XIP if it is required by the system. Only things that aren't required (like debuggers and hard drive drivers) should be removed.
Also, the least significant 16 bits must be zero (lower four hex digits) of the end of vm slot 0 and slot 1 in G'reloc.exe and in your ROMHDR.txt. The least significant 14 bits must be zero (the lower four digits can only be 0000, 4000, 8000 or C000) of the RAM address (ulRAMStart and ulRAMFree).
Code:
Hex edit the S000 file in the nk.exe module folder and search for the revision string. You can find it by doing a search for the unicode string "[B][COLOR=red]Kernel Built[/COLOR][/B]" (Hex String [B][COLOR=red]4B 00 65 00 72 00 6E 00 65 00 6C 00 20 00 42 00 75 00 69 00 6C 00 74 00[/COLOR][/B]). Shortly after that will be the revision that is displayed on the phase 1 boot screen (small red letters in the lower right corner of the device on CDMA Touch Pro). Change that (make sure to overwrite, not to insert, and limit it to 12 characters in unicode format.
When you rebuild your xip.bin and cook with it, you should see this value on the screen during phase 1 boot. The only other way would be to insert a marker into the boot registry
Change PagePool through Hex editing (for Diamond & Raphael)
I'm putting this up here so to answer one more unanswered question about this especially for Diamond & Raphael ROMs
To change PP of Diamond ROMs:
Open the OS.nb in Hex editing software
1. Go to offset 0x37AD68 to find 03 25 A0 E3 03 15 A0 E3 00 20 83 E5 hex string (If this string is not found at the 37AD68 offset, then search for this hex string)
Replace the string with 20 83 E5 with 00 A0 E1
This will make the string NOP (No Operation) meaning, the ROM wont set the PP to default 12MB but will allow the change in below offset
2. Now go to offset 0x3A7F94 to find E0 E2 04 80 00 00 60 00 hex string
again, if this hex string not found at the 3A7F94 offset, then search for the hex string. Just as a hint, this string is after the second NKKD8 (search for text string)
60 is the size of PP that you can now modify to suit your liking
e.g. I made mine 00 to get 0MB PP. Or change it to 80 to get 8MB PP, so forth and so on
With changing the first hex string and making the Kernel NOP, you can also use the tool to change PagePool and it does work
Also to make it a permanent change you can hex edit the first mentioned string in S000 of nk.exe module in XIP and then modify the PP with the program or by hex on OS.nb
To change PP of Raphael ROMs:
Search for hex string: 03 15 A0 03 02 15 A0 13 00 10 82 E5 and change the last 4 bytes to 03 15 A0 03 02 15 A0 13 00 00 A0 E1 then the normal PP Changer tool will work
This is the 2nd string, ignore the 1st one coz that's in ULDR
Gain more Storage Memory (increase imgfs size)
There are 4 partitions in Diamond ROMs
part00 – ULDR
part01 – XIP
part02 – IMGFS
part03 – FAT (This partition exists only on few devices)
We all port XIP from different devices to exclude few modules to gain space and to upgrade the kernel and make the XIP partition smaller in size. Although the new XIP is smaller in size but because of the insertion addresses of XIP & imgfs, there is a gap of wasted space filled with FF between end of XIP & start of imgfs. Although there is no way we can include this space into XIP as free RAM but make use of this space in imgfs and gain whatever storage space we can
Files used as example for this tutorial
xip_out.bin: My own ported XIP of size (30CA12 in Hex, 3195154 in bytes)
os.nb.payload: My own cooked payload (since I also wanted the final ROM to be a cleaner ROM)
imgfs start: in my payload at 0x7A0000 (unedited)
XIP start: in my payload at 0x320000 (unedited)
Before we move into hex editing, let me give an overall outlook of the MBR & MSFLSH regions of the ROM
MBR is the Master Boot Record of the ROM (512 bytes) from 0x0 to 0x1FF. The infomation of partitions types Flags in hex offsets are called from the registry entry mentioned in boot.rgu below
The starting block (LBA) and number of sectors for each partition are defined as shown below
part00. 1C6 – 1C9 (starting block) 1CA – 1CD (number of sectors)
part01. 1D6 – 1D9 (starting block) 1DA – 1DD (number of sectors)
part02. 1E6 – 1E9 (starting block) 1EA – 1ED (number of sectors)
part03. 1F6 – 1F9 (starting block) 1FA – 1FD (number of sectors)
[HKEY_LOCAL_MACHINE\System\StorageManager\PartitionTable]
"04"="FATFS" ; (hex: 1F2)
"20"="BOOT" ; (hex: 1C2)
"23"="RAWFS" ; (hex: 1D2)
"25"="IMGFS" ; (hex: 1E2)
MSFLSH50 is the Flash region of imgfs from 0x800 (see post #8 for screenshots, shown here is for Diamond) to 0xFFF. The starting block of imgfs is located in MSFLSH at 81C
e.g. if your device ROM's sector size is 200 then the MSFLSH50 region will starts at 0x200 and so on
Moving into the hex editing mode for making use of the wasted space between the actual XIP end & start of imgfs partitions
The new xip_out.bin is 30CA12 in total size (check your actual xip_out.bin size, shown here is just example) starting at 0x320000 (check you device XIP start, shown here is for Diamond) and ideally should end at 62CA12. But since the starting block of imgfs must be divisible by 20000 (see post #8 for screenshots, shown here is for Diamond) the imgfs needs to start at 640000. So the new XIP will have to be inserted into the payload at 0x320000 till 0x640000 with XIP size of 320000 and reduced wastage of 135EE bytes
The imgfs can also start at 630000 since this is directly after the XIP and also divisible by 20000, used here is 640000 as expansion for future xip_out.bin
Open the existing os.nb.payload in hex editor. Delete everything from 0x640000 till 0x79FFFF. This will move the imgfs from 0x7A0000 to 0x640000. Since we are now moving the imgfs partition next to new XIP, the number of sectors in new XIP and new LBA of imgfs needs to be edited to the revised value in the MBR region
To calculate the new starting block of imgfs partition we need the number of sectors in new XIP. To calculate that, use the following method
In Hex calc
Number of sectors = size of partition / sector size
e.g. (new XIP) 320000 (shown above) / 800 (see post #8 for screenshots, shown here is for Diamond) = 0640
since the coding is in little endian, we have to reverse these values to 40 06 00 00
Go to offset 0x1DA and change the values to 40 06 till 1DB and then 00 00
Now realloc the LBA of imgfs since we revised the number of sectors in XIP and to calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 = 0C80
since the coding is in little endian, we have to reverse these values to 80 0C 00 00
Go to offset 0x1E6 and change the values to 80 0C till 1E7 and then 00 00
Logical Block Address (LBA) should be equal to (Previous Partition LBA + Previous Partition number of sectors * Sector Size)
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 * 800 (see post #8 for screenshots, shown here is for Diamond) = 640000 (size of imgfs partition)
Similarly to imgfs calculate and change the LBA of FAT at 1F6 and 1F7 using the default imgfs no of sectors (use these since the cooking tools will change these as per actual size)
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 640000 (shown above) / 20000 = 32
Go to offset 0x81C and change the value to 32
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x00320000” (check your insert start address, shown here is for Diamond)
To calculate the size of XIP from MBR, use this method
In Hex calc
Size of XIP = Number of Sectors * Sector Size
e.g. (if the no of sectors in little endian) 0640 (shown above) * 800 (see post #8 for screenshots, shown here is for Diamond) = 320000 (sector size for diamonds)
This value shall be the "-s" while using insert.exe tool and to calculate the start of the XIP, use this method
In Hex calc
XIP Start = imgfs Start + "-s"
Reduce ULDR Partition Size
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files
Also known as part00 in the ROM, is something we all wish to get rid of and use the space as additional storage memory. This tutorial currently aims at reducing the size of this partition by 3.0 MB
Tools you need
NBSplit.exe
NBMerge.exe
Hex editor
Ervius's Payload Reducer
IMPORTANT NOTES
The template OS.nb used is the same OS.nb in which the XIP is inserted at 320000 and of size 320000
For best results use Ervius's Payload Reducer to reduce the size of payload from shipped ROM use nbmerge.exe to cook OS.nb as template for further cooking
This ROM is assumed to be from Diamond and check your device values as per the guide below
The hex offsets of (L)ogical (B)lock (A)ddress and number of sectors and imgfs block address are mentioned in tutorial above or in the post #8 below
Process
Extract OS.nb.payload from the OS.nb (nbsplit.exe –kaiser (check your device) OS.nb)
Run the OS.nb.payload through Ervius's Payload Reducer tool to remove all files from the imgfs and keep only the partition headers
Open this OS.nb.payload in your hex editor. We need to change LBA values of the partitions and number of sectors of ULDR partition since we are reducing the size
In the MBR region (partition Flag 20) LBA of ULDR partition remains same since we are not moving it anywhere. The existing number of sectors of ULDR is 3E 06 from little endian it will be 063E. We are removing 0600 sectors from this partition (0600 * 800 (size of sector, see post #8 for screenshots) = 300000) so, 063E – 0600 = 00 3E. Write it in little endian at hex offset 1CA and 1CB to 3E 00
To physically reduce the partition, remove all data between hex offsets 0x20000 till 0x31FFFF. This will make the XIP start from hex offset 0x20000 till 0x33FFFF and the imgfs partition start at 0x340000
Now since we have reduced the size of ULDR partition, the LBA values of XIP and imgfs partitions will have to be changed in the MBR region
Now change the LBA of XIP. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (ULDR LBA) 00 00 00 02 + (ULDR no of sectors) 00 00 00 3E = 00 00 00 40
since the coding is in little endian, we have to reverse these values to 40 00 00 00
Go to offset 0x1D6 and change the values to 40 00 00 00 till 1D9
Now change the LBA of imgfs. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 00 00 00 40 + (XIP no of sectors) 00 00 06 40 = 00 00 06 80
since the coding is in little endian, we have to reverse these values to 80 06 00 00
Go to offset 0x1E6 and change the values to 80 06 00 00 till 1E9
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 340000 (shown above) / 20000 = 1A
Go to offset 0x81C and change the value to 1A
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00020000 -s 0x00320000” (check your insert start address, shown here is for Diamond) (ignore this if the XIP is already inserted and shifted to this location with this size)
The value (02) seen at hex offset 0x1BF should not be changed or touched since that value tells the OS that first partition starts from the third Sector of the ROM (0x800 (sector size) + 0x800 = hex offset 0x1000) Currently the reduced ULDR partition starts from third sector
Now create the OS.nb from the edited OS.nb.payload to be used as template for cooking using this command
“nbmerge.exe –kaiser (check your device) OS.nb” (without -conservative switch)
NOTE
For best results directly use the OS.nb.payload as template for cooking without merging it into OS.nb. For this you will need to edit the CreateROM.bat
Note the change in red and delete the blue lines from this bat file
copy ROM\OS.nb.payload temp\OS.nb.payload
..\TOOLS\NBSplit -kaiser OS.nb
Rem rename os.nb.extra os-new.nb.extra
!Aman!'s awesome tutorial on removing ULDR partition from devices which don't have the FAT partition (part03) can be refered here: http://forum.xda-developers.com/showthread.php?t=446506
Screenshots of MBR and MSFLSH50 Regions
MBR Region
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
MSFLSH50 Region
Attached these images in Pictorial.zip with post #1 for offline reference
Gain more Storage Space with LZX compression
Thanks to:
spocky12 for cecompr_nt.dll (attached)
ivanmmj for cecompr.dll (attached) This module supports LZX compression as well as the default XPR algorithm
Replace the cecompr.dll found in the OEMXipKernel (or whichever folder you have your XIP modules) with the attached cecompr.dll module that supports LZX compression
The LZX compression takes a load of your RAM while cooking which makes the continuing IMGFSFromDump tool crash. To avoid that replace the attached cecompr_nt.dll file found in “Tools/IMGFS” folder of your kitchen
Pause your kitchen process right after it extracts the IMGFS.bin and before it inserts the files into it. (A simple “PAUSE” in the batch file will suffice). Then open up your IMGFS.bin in hex editor of your choice and search for the string "XPR". Replace the FIRST one, FIRST & ONLY ONE with "LZX". Close the hex editor, save the file and let your kitchen continue with the cooking
After flashing the ROM cooked with this module should give you approx. 10MB more space in the storage memory
Original Posts:
ivanmmj: http://forum.xda-developers.com/showpost.php?p=3678382&postcount=877
spocky12: http://forum.xda-developers.com/showpost.php?p=3690996&postcount=904
Space for Donors
High value real estate space for donors for all my work on XDA
Special Thanks
Piranha1 $5
Vippie $5
Steven Ellis $10
Guitarguy $5
Ckpv5 $5
Letama $10
!Aman! $5
LoriInWa $10
Noonski $15
Kevin $5
Dogmale $1
Nazaliyah $1
Miscellanous uploads related to XIP porting
Kitchen Files
I use "DiamondKitchen_v0.4" kitchen to cook Diamond ROMs. The XIPInsert file is something that I made to automate the insertion and nbmerge process (well, something automatic is better than complete manual )
If you select to use the XIPInsert batch file then you must have DiamondKitchen_v0.4\XIP\xip_out.bin and DiamondKitchen_v0.4\XIP\OS.nb.payload to use this option, else the existing OS.nb file in \ROM folder will get deleted
Note: The insert values used in the batch file is for Diamond ROMs. Please check and edit these as per your devices
Code:
[B][U][I]!COOK.cmd[/I][/U][/B]
Modified to provide options to include the below batch file or to continue without it
Also included necessary warning
Code:
[B][U][I]8a.XIPInsert.bat[/I][/U][/B]
@echo off
cd [COLOR=green]XIP[/COLOR]
..\TOOLS\insert.exe -i [COLOR=green]xip_out.bin[/COLOR] -o [COLOR=green]OS.nb.payload[/COLOR] -d 0x00320000 -s 0x004C0000
..\TOOLS\nbmerge -kaiser OS.nb
copy OS.nb ..\ROM\OS.nb
del OS.nb
del *.payload
del *out.bin
exit
Deprotecting ROMs: My friend, Ervius has made a small tool to "deprotect" a protected ROM , here: http://forum.xda-developers.com/showthread.php?t=465642
First to say THANKS
Cheers
and second to say this is real hard work...but u have done it bro..
congrats
another amazing work by the XIP Master
Thanks for sharing the info, ababrekar! I'm sure this will help out many people (myself included ).
Bite Down and Don't Give Up.
Sounds like someone i know from.... hey, it is you!
Good Job,
ababrekar said:
Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Click to expand...
Click to collapse
just to make it more clear, the value for "-s"= (starting offset of imgfs - starting offset of XIP)
PS: wonderful job writing this guide brother
Ouch - too much like work, but it is nice to know how to do it.
Thanks for your effort!
Best regards,
-boggsie
So, how does one get hooked into the flow of new releases?
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
jcespi2005 said:
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
Click to expand...
Click to collapse
That is a good idea but I'll do that for posting the unedited XIP.bin files from dumped ROMs since the xip_out.bin I build would be for my device. People wont want to ruin their ROMs with someone else's ported XIP, right?
Hello people,
Are there any tools for viewing and editing the amss.bin?
HEX Editor...
IDA...
Brain.
Best Regards
adfree said:
HEX Editor...
IDA...
Brain.
Best Regards
Click to expand...
Click to collapse
with revskill i got this with amss.bin
#define UNLOADED_FILE 1
#include <idc.idc>
static main() {
MakeName(0x00079B70, "Memcmp");
MakeName(0x00062160, "Memcpy");
MakeName(0x0022E924, "Memcpy");
MakeName(0x0006216B, "Memcpy_Generic");
MakeName(0x0022E92F, "Memcpy_Generic");
MakeName(0x000621D0, "__rt_udiv");
MakeName(0x00079F8C, "__rt_udiv");
MakeName(0x00062334, "strlen");
MakeName(0x0007A2C4, "strlen");
MakeName(0x00070DB2, "diag_sp");
MakeName(0x00062298, "strcmp");
MakeName(0x0007A1D8, "strcmp");
MakeName(0x0007A360, "strncpy");
MakeName(0x00072502, "diag_pkt");
MakeName(0x00062F00, "__rt_div0");
MakeName(0x0007D324, "__rt_div0");
MakeName(0x00062F10, "__32__rt_raise");
MakeName(0x0007F1F8, "__32__rt_raise");
MakeName(0x00ACC3A8, "rex_int_lock_32");
MakeName(0x00072330, "subsys_getid");
MakeName(0x0007A548, "vsprintf");
MakeName(0x00062004, "MemClr");
MakeName(0x0022E7C8, "MemClr");
MakeName(0x000725CC, "diag_subsystem");
MakeName(0x0006EC72, "diag_hdlr");
MakeName(0x000726D2, "diag_hdlr");
MakeName(0x00083D86, "diag_hdlr");
MakeName(0x00085432, "diag_hdlr");
}
What about it ?
@Tigrouzen, no segment found at 0x00079B70 etc
amss it's regular elf with a bunch of segments
Code:
Name : LOAD
Start : 0x001E7000
End : 0x001EE000
Length: 0x00007000
----------------------
Name : LOAD
Start : 0x001F0000
End : 0x001F1000
Length: 0x00001000
----------------------
Name : LOAD
Start : 0x001F2000
End : 0x005D8000
Length: 0x003E6000
----------------------
Name : LOAD
Start : 0x005D8000
End : 0x00CDB000
Length: 0x00703000
----------------------
Name : LOAD
Start : 0x00CDB000
End : 0x00D11000
Length: 0x00036000
----------------------
Name : LOAD
Start : 0x00D11000
End : 0x00DAF000
Length: 0x0009E000
----------------------
Name : LOAD
Start : 0x00DAF000
End : 0x00DB9000
Length: 0x0000A000
----------------------
Name : LOAD
Start : 0x00DB9000
End : 0x00E9B000
Length: 0x000E2000
----------------------
Name : LOAD
Start : 0x00E9C000
End : 0x01BF9000
Length: 0x00D5D000
----------------------
Name : LOAD
Start : 0x01BF9000
End : 0x01D05000
Length: 0x0010C000
----------------------
Name : LOAD
Start : 0x01FF0000
End : 0x01FF006C
Length: 0x0000006C
----------------------
Name : LOAD
Start : 0xB0000000
End : 0xB0010CE7
Length: 0x00010CE7
----------------------
Name : LOAD
Start : 0xB0040000
End : 0xB0057000
Length: 0x00017000
----------------------
Name : LOAD
Start : 0xB0100000
End : 0xB0107207
Length: 0x00007207
----------------------
Name : LOAD
Start : 0xB0140000
End : 0xB01401B8
Length: 0x000001B8
----------------------
Name : LOAD
Start : 0xB0200000
End : 0xB0208CF3
Length: 0x00008CF3
----------------------
Name : LOAD
Start : 0xB0240000
End : 0xB024028C
Length: 0x0000028C
----------------------
Name : LOAD
Start : 0xB0400000
End : 0xB040DBE8
Length: 0x0000DBE8
----------------------
Name : LOAD
Start : 0xB0600000
End : 0xB0602000
Length: 0x00002000
----------------------
Name : LOAD
Start : 0xB0602000
End : 0xB0604000
Length: 0x00002000
----------------------
Name : LOAD
Start : 0xF0000000
End : 0xF001F878
Length: 0x0001F878
----------------------
Name : LOAD
Start : 0xF0020000
End : 0xF0026000
Length: 0x00006000
load amss.bin with TriX, dump decoded stage (elf format) and analyze with disassembler (e.g. IDA)
Ok guys i extract certificate from Amss S8530 XEJL2, bootloader segments full info fsbl sbl...
Also i can dump complete NAND and find segment and algorith for RC1 too
This is appscompressed.bin algorythme
0x01ca7750 RIPEMD128+160+MD4
0x01ca7750 SEAL+MD4 key
appcomp hash :
SHA1 : EB55C6690ACAF40BB2F845313F58BFE9C3BC529D
SHA224 : AAC3E2B65CC9F33BB7EDDA3DEB541CA9E8919422CC179B4D2B49F39BAE008F00
SHA256 : 580D3DB21E41A9FE588AE544266040FABA8AF044E739971E77F2B1272323D0B6
SHA256-HTC : A44BC029D7F952750003D9695ED7B464E446D34EEF5BD9665487E4C2BF81F669
MD4 : B3BD8310FF2C4C05E2044FD491814792
MD5 : 7220779D1094C5F7789094DC75BA4E9E
CRC16 (0x1189) : F4EA
CRC30 (Block: 0x1000, Page: 0x200) : 0BD214AA
CRC30 (Block: 0x2000, Page: 0x400) : 0A28A17A
CRC32 (0xEDB88320) : 313F4EF2
CRC32 (0x04C11DB7) : 90B01704
CRC32 HTC (0xEDB88320) : B55B60A7
ECC Reed Solomon (parity 10) : 43702DA1FDAC4DB2023B
ECC BCH Micron 3 byte : 818144
ECC Hamming Toshiba (8 bit - 0x200 bytes) : C00FC3
ECC Hamming (8 bit - 0x200 bytes) : FF3CF3
ECC Hamming (16 bit - 0x200 bytes) : 3FCFFC
Amss algo :
0x0007fce0 CRC-16 norm
0x0007fee0 CRC-16 inv
0x0007f8e0 CRC-30
0x0007eb50 CRC30 Function
0x00b66194 CRC-32
0x00b66394 CRC32 Function
0x000800e0 CRC-32 Xilinx
0x0007eb58 CRC32 Xilinx Function
0x000800e4 CRC32 Xilinx Function
0x00c3c490 DES RAW Spbox
0x00c39381 RSA PKCS SHA1/RIPEND Digest
0x00c39390 MD2 S
0x00463548 SHA2 table
0x008fcc88 SHA2 table
0x00b6eb14 ZDeflate
0x0041a28c SHA1+MD4+MD5 init
0x008fcb08 SHA1+MD4+MD5 init
0x00c3d7f8 SHA1+MD4+MD5 init
0x0041a29c SHA1+MD4+MD5 key1
0x008fcb18 SHA1+MD4+MD5 key1
0x00c3d808 SHA1+MD4+MD5 key1
0x001a9844 SHA1+MD4+MD5 key2
0x0041ac1c SHA1+MD4+MD5 key2
0x008fcb1c SHA1+MD4+MD5 key2
0x001a9848 SHA1+MD4+MD5 key3
0x0041ac20 SHA1+MD4+MD5 key3
0x008fcb20 SHA1+MD4+MD5 key3
0x00463648 SHA2 init table
0x008fcd88 SHA2 init table
0x00c3d80c SHA2 init table
0x0046364c SHA2 init table
0x008fcd8c SHA2 init table
0x00c3d810 SHA2 init table
0x00419980 RIPEMD128+160+MD4
0x008fcaf8 RIPEMD128+160+MD4
0x00bdcca0 RIPEMD128+160+MD4
0x001a9844 MD5
0x0041ac1c MD5
0x008fcb1c MD5
0x00419980 SEAL+MD4 key
0x008fcaf8 SEAL+MD4 key
0x00bdcca0 SEAL+MD4 key
0x004fc7af HTC PUBLIC KEY
E9079DBB2452104990982132470BA20B7C795D1B4690B718B62FCD38D71D4E458FAF320374B89D5236C79BD57D2BA2D3508A4A605B0D48CB8CA5478BFE4D7D32AB0AE072BC367A9615F002D5023A617B422FEC1EF8DAD772D75E9C4F06EF624B864699A3F080D1B8E192B921D159852B2DC798F752B4F1FA529FF123D9963F73
0x00708134 Sober 128
0x00c3cd90 Sober 128 SBox
Possible algos little endian: 45
0x00315f6c AES te
Possible algos big endian: 1
Amss hash :
SHA1 : C59C5785E823E5E1CA9BE05DB6F55F8C8AC1BBA3
SHA224 : 5F50CED13C1204068E443919706B53D866271DAB1CFB5A9CB07A953CAE008F00
SHA256 : D86C7634FE07806D3B87701EC7F72F25DAAFAC7C40CA1D370C1ABA5840C091C0
SHA256-HTC : 120F70AECE78B8DCF69DCD79F020AB00AE17572123BA21274D6F6EE280774A09
MD4 : 7703DF5B1074392D4B91ECA23BAC9D92
MD5 : 22197F8AAD6A2CB4394E1B4E63EB843C
CRC16 (0x1189) : FAC5
CRC30 (Block: 0x1000, Page: 0x200) : 311AE4C7
CRC30 (Block: 0x2000, Page: 0x400) : 295DFC29
CRC32 (0xEDB88320) : 8DB21A34
CRC32 (0x04C11DB7) : 7B94B6A4
CRC32 HTC (0xEDB88320) : 08450BBC
ECC Reed Solomon (parity 10) : A04D69B134A126F3FD15
ECC BCH Micron 3 byte : 000000
ECC Hamming Toshiba (8 bit - 0x200 bytes) : FFFFFF
ECC Hamming (8 bit - 0x200 bytes) : FFFFFF
ECC Hamming (16 bit - 0x200 bytes) : FFFFFF
Amms certificat :
https://rapidshare.com/files/3061245812/1.cer
Well, the main idea was ..., to get some tools with which the amss.bin for bada v1.2 and v2 can be modified to work for the American/Australian version of the wave. Looks like there are some hardware differences and this file is containing information needed for the RF module.
Looks like there are some hardware differences and this file is containing information needed for the RF module
Click to expand...
Click to collapse
No idea if Hardware differences, but I'm pretty sure there are different Config/Calibration data...
Check out NV items... AMSS + NV items = Qualcomm related part...
http://www.samsunguniverse.com/forum/s8500-can-work-with-qualcomm-tools-t199.html
You could take an look on FCC documents for maybe Hardware check...
Best Regards
I think gambal refers to UMTS bands, Europe is different than in America.
UMTS bands in America are 850 - 1900
UMTS bands in Europe are 2100
bada 1.2 and above only works with Euro bands (these updates hasn't oficially released in America), so as we know the file "amss.bin" contains the parameters that define which bands to work, would be good to try to edit the information to compile a new "amss.bin" to work with American bands ..
Many Americans would be happy!
...would be good to try to edit the information to compile a new "amss.bin" to work with American bands ...
Click to expand...
Click to collapse
But you are really sure that not NV items differ?
Maybe easier to compare NV items...
Best Regards
You mean to compare amss NV items from a 1.0 American firmware and another 1.2 European firmware?
I was import to a .Qcn file a list of NV items of my mobile (bada 1.0 american), i will compare with another one of 1.2.
It's posible to create more NV items if is necesary?
sorry for double post.
i've compared NV items of my phone, first with a 1.0 american firmware then with a 1.2 European firmware..
EDIT: thought that there were no differences because the file size was identical, but looking more attentively i find some, i will continue researching,
You tried QPST or which Tool?
And are sure there are no differences?
I have 2x S8500... with QPST difference 10 NV items + one S8500 has 10 more
Content not checked... too lazy at this time.
Best Regards
Edit 1.
File Summary:
Phone Model: 19 [QSC6270/QSC6240], Configuration Name: default, Total NV Item Count: 305
Click to expand...
Click to collapse
File Summary:
Phone Model: 19 [QSC6270/QSC6240], Configuration Name: default, Total NV Item Count: 319
Click to expand...
Click to collapse
And these are only the "official" NV items... and not the hidden one...
Example...
Code:
NV item: [B]2608[/B] [NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I], index 0
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 0: 12 3d fc ff 9c 3c fc ff 26 3c fc ff b0 3b fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 1: 34 3b fc ff af 3a fc ff 2a 3a fc ff a6 39 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 2: 22 39 fc ff 9f 38 fc ff 0c 38 fc ff 65 37 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 3: be 36 fc ff 18 36 fc ff 73 35 fc ff ce 34 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 4: 2a 34 fc ff 87 33 fc ff e5 32 fc ff 43 32 fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 5: a2 31 fc ff 01 31 fc ff 61 30 fc ff c2 2f fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 6: 23 2f fc ff 85 2e fc ff 85 2e fc ff 85 2e fc ff
NV_GSM_850_AMPM_MASTER_TBL_SEG8_F1_I 7: 85 2e fc ff 85 2e fc ff 85 2e fc ff 85 2e fc ff
sorry for my english, I mean to say that i find some differences..
between 2 firmwares, I find 40 differents NV items using "RF NV items Manager" program.
Example:
European 1.2 Firm:
Code:
NV item: 5059 [NV_WCDMA_2100_TX_LIN_MASTER_0_ENH_I], index 0
NV item: 5061 [NV_WCDMA_900_TX_PDM_LIN_0_ENH_I], index 0
American 1.0 Firm:
Code:
NV item: 5064 [NV_WCDMA_1900_TX_PDM_LIN_0_ENH_I], index 0
NV item: 5060 [NV_WCDMA_800_TX_PDM_LIN_0_ENH_I], index 0
(it's look like these items manage the umts network)
This are 2 items of 40 that I find.. So, I imported all 40 1.0 American Firmware Nv Items to the 1.2 Euro Firmwared Phone, (using previous modified .QCN file) then, i restart the device, but nothing happen, still no find UMTS network... But i want believe that we are close to find the solution
If I use PSAS to Display the new added NV items, these appear as "inactive item" and those already on the phone appears lile "bad parameter"
not know what else I can try...
Even if NV items count is different. Dump of NV area will be always the same in size. Area in oneNAND reserved for NV data is constant, and in most it's just empty space, filled with zeros.
Is it possible to dump whole NV items list using QPST? Can you guys do that and send dumps to me?
If not please search for following NV items and send me values you get (if you get any)
Int id 556
Int id 5
Int id 7
Int id 1403
String id 254
String id 387
String id 388
String id 256
String id 197
I want to prove some theory just taken from Bada kernel and need few different values to compare. These should contain Timezone, Locale and SimBlock settings. (If these NV items are even available)
Please send me PMs with dumps if you get any. Thanks in advance.
Tell me when you are ready "amms.bin" to "bada 2.0" so I can put it on my phone. I'm from Argentina. Thank you very much!
Rebellos said:
Int id 556
Int id 5
Int id 7
Int id 1403
Click to expand...
Click to collapse
With "PSAS" display "Inactive Item", and with "RV NV item manager" i don't these id's..
@adfree
Hey, if I wrote in phone (with "RV NV item manager") some NV items, is not take any effect... does exist another step to "activate" these items or some? maybe in Stune have to add any parameter? or maybe the "QPST Service program" tool..
I have fear of breaking the handset really... I just wan't to calibrate the UMTS bands, need these:
WCDMA_II_PCS_1900
WCDMA_V_850
http://forum.xda-developers.com/showpost.php?p=12436452&postcount=1
Other way to access NV items.
Now you can backup with sTune for instance... folders:
Code:
[B]NV
nvm[/B]
EXTREME Caution!
Some IDs are protected... so you can maybe write/activate, but not easily remove change = brick...
Best Regards
a little question..
there is a firmware of S8530 which has bada 1.2 and 850/900/2100Mhz 3g bands capable... there are firmwares prepared for Brazil and Australia.
it's posible to flash that amss.bin in a S8500 with bada 1.2?
I tried this, but the bootloader says "error erase amms"
amss.bin in a S8500 with bada 1.2?
Click to expand...
Click to collapse
If I remember correct, then yes...
Maybe not all combinations...
BUT check Multiloader ... adresses are different...
So you have to edit...
Later more.
Maybe give Link to this S8530 Firmware, so I can take an look or try for you...
Best Regards