Develop Bugs

Help in HEX convert need

Hi.
i need a litle help in hex convert.
in Bepe threads i fond this.
- nb file: 0x000001F5: short value + 0x48 (e.g: 0xA7+0x48=0xEF)
- nb file: 0x000001FB: short value + 0x48
A7 00 + 0x48 = EF 00
DB 05 + 0x48 = 23 06
i dont know if that is correct or not but if yes wath the value for this?
A2 01 + 0x48 = ??????
Thx and regards

I think you are not adding the columns correctly here. See your examples below along with a base 10 (the way we normally count) example (notice the numbers are lined up just as you would if you were adding base 10 numbers, from the least significant column to the most significant column, right to left)
A7 00 DB 05 100 (base 10 example)
+ 48 + 48 + 10
-------- ------ ----
A7 48 DB 4D 110
A7 + 48 does add to EF, but that is leaving out 2 entire orders of significance at the end of the A7 00 number.
So, the answer to your next question then would be:
A2 01
+ 48
------
A2 49
Also, just FYI here, the Calculator program that comes w/ Windows based computers will do Hex arithmetic for you. To get it to hex mode, start the Calculator, click on the View menu and choose Scientific. The calculator will then change it's view so that you can do Hex, Decimal (base 10), Octal or Binary arithmetic.
Hope that makes sense. If not, ask and I'll try to do a better job explaining.

Help me dump the OS of my PPC

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.

Disable Process at Startup

Hello folks,
Does anyone know the correct way to disable a Windows Mobile process from starting when the Rhodium starts up? I notice a process called "JBlendDaemon.exe" starting up, but I do not use any Java applications (that I am aware of, at least).
How do I stop this process (or any other process) from starting at boot-up? This item is not in the Windows Startup directory (I am running stock Tmobile firmware).
Thanks!

overwrite the JBlendDaemon.exe
you will find it in the \windows\ folder
with a 0 Kbyte file(DummyFile,write protection)
JBlend works also when use this trick,
if you want it back, just delete the dummyfile and take a softreset
use TotalCommander or Resco....
you can also kill some StartUp BackgroundTasks via RegEditor
HKLM\init
Type REG_BINARY (Binary value)
Depend100 = 3C 00
Depend110 = 64 00
Depend120 = 64 00
Depend58 = 37 00
Type REG_SZ (String value)
Launch100 = uptimesqm.exe
Launch110 = tskschedule.exe
Launch120 = autoimeupdate.exe
Launch19 = initvmmap.exe
Launch4 = sdpready.exe
Launch58 = RunCC.exe
Launch98 = TimeWizard.exe
you can only delete this keys,
if you delete other keys you have a big problem ;-) Hardreset
greetz

Multiloader checksum check FFS

hi guys I'm doing some research on samsung's firmware files...
is there any good disassembler in here?
We need to know how is the checksum at the end of FFS // APP files calculated!
That's very important...
is there anyone who can help?

im sorry im not but maybe a frined of mine...
why is so important?
its hard to do?
if you give a link with a tutorial may be in some days i will be able to help...
i have programmed in c in the past...
cheers

I am a C programmer (university student) but we need disassemblers here, no programmers atm

Guys I don't know if you understand that the solution to this problem is CRUCIAL for the realization of custom firmwares!!
Trust me! Find some windows (desktop) disassembler as soon as possible!!
thanks

Type : Unofficial Version
Number : 41
Builder : HP05
Host : SCMHP05
Date : 2010/05/28
Time : 21:49:29
Size : 81790332 bytes
CheckSum : 0x259b3fc5
View
Click to expand...
Click to collapse
Hmmm. Whole file is smaller... 50.856.960...
apps_compressed.bin
Decrypted with PSAS... but I can't decompress...
Anyway.
CRC32 (32 bit) could be used...
The Question could be, where the content starts and ends correct to fit size to make crc32...
Best Regards

wait u're talking about the apps_compressed...
while I'm talking about the ffs/app files...which have a 16byte checksum in the footer!

Sorry. I'm thinking loud. As I thought they used for all files same CRC or Hash...
I compared for instance Rsrc2_S8500(Mid).rc2 and Rsrc2_S8500(Low).rc2.
As 1 Byte at Start leads to 16 Byte change at end of file... So maybe MD5 too used by Multiloader.
Again. I'm thinking loud.
Best Regards

No progress. But few Screenshots for better understanding...
If we manipulate *.FFS we can't flash. (ALL other files protected too...)
Test 1.
I changed 1 useless Byte...
Somewhere blabla.jad in blabla.jam
Multiloader 5.64 accept to choose my file. But Error message if I press Download.
Test 2.
I add 1 Byte at the end of file. To check if some crap or if whole file is checked...
Result:
Multiloader 5.64 not allow to choose this file.
Both files tested also via Multiloader 5.62. And this Versions not allow both files to choose.
See Screenshots for Error messages.
Ideas...
Maybe disable CRC Check in Multiloader...
Or find other way to flash and check if Wave self checks Manipulation of files. Or only Multiloader is the bottleneck.
Maybe it is more complex... as I found via Internal menu the Info I've posted above... in Wave self. If Wave have selfcheck...
Best Regards

hi,
I'm not sure if you're hear about fmtBADA plugin for TriX - I wrote it few days ago (it is very simple but quite usefull). It parse any bada firmware file (*ffs, amss, ShpApp etc), so we can easly manipulate with it. After all program recalculate checksum, update all needed values so we can put file back to phone using multiuploader

b.kubica said:
hi,
I'm not sure if you're hear about fmtBADA plugin for TriX - I wrote it few days ago (it is very simple but quite usefull). It parse any bada firmware file (*ffs, amss, ShpApp etc), so we can easly manipulate with it. After all program recalculate checksum, update all needed values so we can put file back to phone using multiuploader
Click to expand...
Click to collapse
what u talking about?
let us know more...
I made lots of research on ffs and app files...

I put some files at NokiX site (check my homepage), so you can play with firmware files quite easily. GUI is qt based so you need to download Qt libraries for the first time. Two packages you will find in bada subdir - program and scripts.
Start program, at General tab select input and output file (e.g. FFS PFS ShpApp,amss). Go to the Scripts tab and load scripts you want to fire up.
For the first time I reccomend you to try fs_shell script - it is simly command line script to edit filesystem images (ffs,pfs,shpapp). You can list, dump delete rename files, adding is not supported yet (but can be easy implemented - scripts are written in pure C).
Before asking just play with it
br,
Bartek

ok then I don't need it already made more
thanks to a russian friend, I probably solved the checksum problem
good news will come the next days

Nice. I have extracted *.FFS and ShpApp.app files.
I'm blind to find the Button where Rename or Delete is stored to output file.
How to save my changes to file?
Best Regards
Edit:
Maybe my fault...
I have bada_scripts_20110104.zip.
Will look into bada_20110106.zip

kubica no reason to make a new script, I'll post something in the next days if it's ok to you, take care about the amss
if you want to do it for personal reason, no problem of course

nevermind, script was already done
you're working on some kind of file system tool, right? We're lucky guys FS images have very simply structure (as you know), only one md5 checksum on it, kewl
One of TriX most advantage is work on stages ( e.g. amss is parsed to elf, elf is parsed to memory segments, than we can edit them and TriX roll back to amss again).
adfree, yes I uploaded today latest version (can be found in repository also). As I said it is only text version (command line), more like programmer preview, and it was not designed as end user tool.
faenil, you asked about dissasembler - have you tried IDA? ( quite expensive though ). I tried in trix hack amss (resize memory segments, add own routines), all works fine, now it's time to investigate functions (some of them can be located with locate script).
Another question - ok, it's sad bootloader is crypted with RSA, but I guess is stored in flash decoded. What if we try to access nand directly using Flash_Read/Write? I can't find flash access routines in amss but i did't look
deeply...

b.kubica said:
nevermind, script was already done
you're working on some kind of file system tool, right? We're lucky guys FS images have very simply structure (as you know), only one md5 checksum on it, kewl
One of TriX most advantage is work on stages ( e.g. amss is parsed to elf, elf is parsed to memory segments, than we can edit them and TriX roll back to amss again).
adfree, yes I uploaded today latest version (can be found in repository also). As I said it is only text version (command line), more like programmer preview, and it was not designed as end user tool.
faenil, you asked about dissasembler - have you tried IDA? ( quite expensive though ). I tried in trix hack amss (resize memory segments, add own routines), all works fine, now it's time to investigate functions (some of them can be located with locate script).
Another question - ok, it's sad bootloader is crypted with RSA, but I guess is stored in flash decoded. What if we try to access nand directly using Flash_Read/Write? I can't find flash access routines in amss but i did't look
deeply...
Click to expand...
Click to collapse
I'm not that experienced unfortunately I needed a disassembler (person) not a disassembler (software)
btw I needed it to discover that it was md5 and on which bytes it was computed and I discovered this yesterday evening
So now we know everything about ffs and app
Still have to understand the new values in pfs header...if you already know that raise your hand
Btw, yes I'm working on something like that I won't have time now to do the GUI, so I'll probably leave it as an "experienced users only" for the moment...
I've got lots to study for university, and some programming projects to end (for uni too) so my spare time is almost finished and I still have to release a custom firmware for i8910 and a software for that firmware for Symbian...
damn I'm full of things to do xD
I'll send u a pm though, if you want to chat a lil

all file footer looks the same
typedef struct s_bada_footer // last 1024 bytes
{
unsigned int magic; // always 0xABCDABCD
unsigned int addr; // nand(?) address
unsigned int unk0; // SBZ (=Should Be Zero)
char name[32]; // e.g. S8500
char ext[8]; // e.g. mbn, ffs
unsigned int unk1[5]; // some flags, values, to be checked later
t_cert_info info; // crypto data ( zeroed if file is not crypted )
char md5sum[16]; // MD5 sum of image ( without footer )
char padd[424]; // padding bytes, SBZ
} t_bada_priv;
typedef struct t_cert_info // 512 bytes
{
unsigned int magic; // 0x79461379
char cert0[324]; // ...
unsigned int magic; // 0x79461379
unsigned int length; // crypted length ( without footer )
char cert1[16]; // exist in image also at ( length - 0x10 ) position
char publickey[64]; // ?
char name[64]; // e.g. S8500+XX+JEE
char tool[32]; // TkToolVer famous string
}
headers are different. boot_loader, Apps, Rsrc1, Rsrc2, fota and CSC don't have header.
dbl and Amss have 0x200 bytes header.
ShpApp, Factory FS, Partial FS have 0x60 bytes header
Code:
typedef struct s_bada_object
{
unsigned int offset;
unsigned int length;
char name[24];
} t_bada_object;
typedef struct s_bada_hdr200
{
unsigned int magic; // 0x12345678
unsigned int count; // count of objects below
char padd[24]; // padding bytes
t_bada_object[15]; // not used SBZ
} t_bada_hdr200;
typedef struct s_bada_hdr60
{
wchar_t name[16]; // UCS-2 name
unsigned int unk0[14]; // unknown
char padd[8]; // FF FF FF
} t_bada_hdr200;
from my observations, unk0 fields in FS system header are not *SO* important - I just preserve original values, removed files I want from factory FS, and put file back to phone

all file footer looks the same
Code:
typedef struct s_bada_footer // last 1024 bytes
{
unsigned int magic; // always 0xABCDABCD
unsigned int addr; // nand(?) address
unsigned int unk0; // SBZ (=Should Be Zero)
char name[32]; // e.g. S8500
char ext[8]; // e.g. mbn, ffs
unsigned int unk1[5]; // some flags, values, to be checked later
t_cert_info info; // crypto data ( zeroed if file is not crypted )
char md5sum[16]; // MD5 sum of image ( without footer )
char padd[424]; // padding bytes, SBZ
} t_bada_priv;
typedef struct t_cert_info // 512 bytes
{
unsigned int magic; // 0x79461379
char cert0[324]; // ...
unsigned int magic; // 0x79461379
unsigned int length; // crypted length ( without footer )
char cert1[16]; // exist in image also at ( length - 0x10 ) position
char publickey[64]; // ?
char name[64]; // e.g. S8500+XX+JEE
char tool[32]; // TkToolVer famous string ;)
}
headers are different. boot_loader, Apps, Rsrc1, Rsrc2, fota and CSC don't have header.
dbl and Amss have 0x200 bytes header.
ShpApp, Factory FS, Partial FS have 0x60 bytes header
Code:
typedef struct s_bada_object
{
unsigned int offset;
unsigned int length;
char name[24];
} t_bada_object;
typedef struct s_bada_hdr200
{
unsigned int magic; // 0x12345678
unsigned int count; // count of objects below
char padd[24]; // padding bytes
t_bada_object[15]; // not used SBZ
} t_bada_hdr200;
typedef struct s_bada_hdr60
{
wchar_t name[16]; // UCS-2 name
unsigned int unk0[14]; // unknown
char padd[8]; // FF FF FF
} t_bada_hdr200;
from my observations, unk0 fields in FS system header are not *SO* important - I just preserve original values, removed files I want from factory FS, and put file back to phone

CSC has got its header, it's just that there are more files into 1
after about half the file, we come back to the same plain structure

very simple ( 2KB ) partial file system in attachment, all values from header preserved
Code:
FileSystem Shell
---------------------------
<1.> List Files
<2.> Get File
<3.> Put File
<4.> Delete File
<5.> Rename File
<6.> Dump all files
<0.> Quit
Type Size Flags Name
DIR 0x00000000 0x00000000 /Arggh
FILE 0x00000000 0x00000000 /Arggh/it_works.txt

[Q] Question about amss.bin

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