Hi all,
Has anyone managed to disassemble the ROM image files and possibly "see" actual source code? It would be interesting if someone could do this.
Cheers,
Zouga
patridaaaaa!
Geia sou!
Source code is not compiled. what you find in ROM is compiled, thus you cannot see the source code. YOu could disasseble a ROM image to see what files it has, but I do not know how that happens
What source code do you need? Microsoft provides partial source code of Windows CE in Platform Builder. Trial PB 4.20 was removed from MS site, you can only download PB 5.0.
Geia sou AdmiralAK!
Thank you guys for your replies. I have some parts of the radio ROM in which I am trying to identify interesting segments, like for example SIM lock I think I know what I am doing, I have managed to download from the PDA parts of the Radio ROM (which I suspect remains intact when flashing to a newer Radio version). Also, I have some commands which are being used with the XDA IIs bootloader, can anyone help me about their use?
r task a
rpass
x
rrbmc (that's probably to read from specific memory addresses)
rerase (to delete from specific memory addresses)
retuoR
rwdata (to write in specific memory addresses)
Also, does anyone have any information on the XDA II unlocking utility? I mean which memory addresses accesses, where it writes etc...
Thanks,
Zouga
hahahaha "I think I know what I'm doing" :lol:
then why do you need to know how and where to write information, dude?
"Also, does anyone have any information on the XDA II unlocking utility? I mean which memory addresses accesses, where it writes etc... "
Unfortunately for you, I don't believe Windows CE is written using QBASIC.
Yeh exactly, "I THINK" I know what I am doing, never said I know exactly what I'm doing. I am not a cracker or a software engineer, I am an electronic engineer and I try to use my understanding about embedded electronics to get through to some useful information. I know in which segments of the Radio rom the simlock lies, I just cannot crack the data. I can only see HEX format like
3A 46 3D 00 78 0D 20 08 3A 41 3D 00 00 00 00 00 :F=.x. .:A=.....
Anyone that can give a hand with this, I would appreciate your input.
Regards,
Zouganelis
You can decompile the radio ROM using IDA. It uses a variation of ARM cpu.
read http://www.xs4all.nl/~itsme/projects/xda/xdagsm-info.html for xda2
so, i got bored so why not post a new thread.
as the title says, here's how to fully and permanently disable sign/cert checking in WM5/WM6, so you can load unsigned files even during boot, just fine.
i've been asked several times on how to do it
sumup: you will need IDA Pro or some other disassembler and S000 from nk.exe module in the XIP. VerifyBinary is the function to be patched.
here's the code to be modified:
- first, some example ways to find it
1. locate nk.exe string in strings tab (the lower case one, "nk.exe"), go to the code that references it, below that, enter the second BL (it's the BL in next block), that function is LoadE32, now find the xrefs for it, should have about 3-4 references to it. one of them (InitModule) will look similar to example disassembly below, where 8002D0EC is LoadE32.
2. you might be able to search for LDREQ R0, =0x80090006 though in some nk.exe's ida won't resolve that too well (if the rom base is near the 0x80090006); you could still search for 06 00 09 80 in the nk binary - but that is referenced at other places too, still maybe this might make it easier to find the VerifyBinary function.
- anyway, next, example code
.text:80030CE4 7E 00 A0 03 MOVEQ R0, #0x7E ; '~'
.text:80030CE8 4E 00 00 0A BEQ loc_80030E28
.text:80030CEC 02 00 58 E3 CMP R8, #2
.text:80030CF0 00 80 A0 03 MOVEQ R8, #0
.text:80030CF4 02 00 19 E3 TST R9, #2
.text:80030CF8 01 E0 A0 13 MOVNE LR, #1
.text:80030CFC 00 E0 A0 03 MOVEQ LR, #0
.text:80030D00 0C 30 8D E2 ADD R3, SP, #0x44+var_38
.text:80030D04 04 20 8D E2 ADD R2, SP, #0x44+var_40
.text:80030D08 70 10 84 E2 ADD R1, R4, #0x70
.text:80030D0C 0A 00 A0 E1 MOV R0, R10
.text:80030D10 00 E0 8D E5 STR LR, [SP,#0x44+var_44]
.text:80030D14 F4 F0 FF EB BL sub_8002D0EC ---> LoadE32()
.text:80030D18 00 00 50 E3 CMP R0, #0
.text:80030D1C 41 00 00 1A BNE loc_80030E28
.text:80030D20 8C 30 94 E5 LDR R3, [R4,#0x8C]
.text:80030D24 CE 20 84 E2 ADD R2, R4, #0xCE
.text:80030D28 05 10 A0 E1 MOV R1, R5
.text:80030D2C 00 00 53 E3 CMP R3, #0
.text:80030D30 BC 3C D4 01 LDREQH R3, [R4,#0xCC]
.text:80030D34 0A 00 A0 E1 MOV R0, R10
.text:80030D38 03 90 83 03 ORREQ R9, R3, #3
.text:80030D3C 00 30 A0 E3 MOV R3, #0
.text:80030D40 BC 9C C4 01 STREQH R9, [R4,#0xCC]
.text:80030D44 3A E7 FF EB BL sub_8002AA34 ---> VerifyBinary()
in the example the BL after LoadE32, sub_8002AA34 is VerifyBinary. this is what you want to patch.
if you look you can see that if it doesn't return 0 it will exit the function that has this quoted code. so just go to VerifyBinary start and patch it to
MOV R0, #0 (00 00 A0 E3)
BX LR (1E FF 2F E1)
(why not just NOP the BL to it? because it is also called when an EXE is being loaded, so we need to cover that case too. the above code is DLL load code)
- IMPORTANT: to clean some things up when it checks whether a trusted process is loading an untrusted DLL... to avoid that we'll just put everything in full kernel trust mode which is neat anyway
so you should also patch the part after it returns.
example:
.text:80030D44 3A E7 FF EB BL sub_8002AA34
.text:80030D48 00 00 50 E3 CMP R0, #0
.text:80030D4C 35 00 00 1A BNE loc_80030E28
.text:80030D50 00 30 97 E5 LDR R3, [R7]
.text:80030D54 03 30 D3 E5 LDRB R3, [R3,#3]
.text:80030D58 02 00 53 E3 CMP R3, #2
.text:80030D5C CE 30 D4 05 LDREQB R3, [R4,#0xCE]
.text:80030D60 01 00 53 03 CMPEQ R3, #1
.text:80030D64 24 05 9F 05 LDREQ R0, =0x80090006
.text:80030D68 2E 00 00 0A BEQ loc_80030E28
.text:80030D6C 02 00 19 E3 TST R9, #2
1) nop the BEQ (or just put the following code in its place)
2) make sure that the byte at [R4,#0xCE] has #2 in it.
i.e patch it like this: insert two opcodes like this:
MOV R0, #2 (02 00 A0 E3)
STRB R0, [R4,#0xCE] (CE 00 C4 E5)
you can NOP the rest before the TST. do not touch the TST Rx, #2, or anything that comes after that line.
notes:
1. this will change KITL log in that it will not log module loads regarding cert checking. if you still want to log module (DLL and EXE too) loads in KITL i have another simple patch to do it if anyone wants nice KITL
2. you can also patch certmod.exe (or if you wish, filesys.exe) instead of nk.exe but this way is faster and cleaner, also nk.exe changes less often than certmod (or filesys). still, if someone's interested i can post that too.
+ bonus: old news maybe but afaik it was never made public so here's how to change a WM5 kernel to "upgrade" it to WM6 (i found that method last year to make WM6 porting possible / much easier).
i've mentioned LoadE32, well this is the function you want to patch.
example code:
LoadE32() (go to somewhere at the right in IDA if you are in graph view, to find it faster)
this is the CE major/minor version check in PE header of the EXE/DLL being loaded.
ROM:80032DEC STR R3, [R5,#4]
ROM:80032DF0 CMP R2, #5
ROM:80032DF4 BHI loc_80032E34
ROM:80032DF8 BNE loc_80032E08
ROM:80032DFC LDRB R3, [R5,#3]
ROM:80032E00 CMP R3, #1
ROM:80032E04 BHI loc_80032E34
CMP R2, #5 is comparing against CE major version i.e. CE 5.x
CMP R3, #1 is comparing against CE minor version i.e. x.1 for WM5 (CE 5.01), x.2 for WM6 (CE 5.02)
so you can just change the CMP R3, #1 to CMP R3, #2 (or do it in another way if you wish), encoding 02 00 53 E3
(of course R3 is only in this example)
that's it for now, maybe i'll post more tricks from now on.
cmonex said:
2. you can also patch certmod.exe (or if you wish, filesys.exe) instead of nk.exe but this way is faster and cleaner, also nk.exe changes less often than certmod (or filesys). still, if someone's interested i can post that too.
Click to expand...
Click to collapse
Please describe. I'm interested.
cmonex said:
+ bonus: [...]
that's it for now, maybe i'll post more tricks from now on.
Click to expand...
Click to collapse
Please. Don't stop. Please .... more
Many, many thanks.
cmonex said:
so, i got bored so why not post a new thread.
Click to expand...
Click to collapse
Please... be bored all the time
cmonex said:
2. you can also patch certmod.exe (or if you wish, filesys.exe)
Click to expand...
Click to collapse
It could be interesting, it could be used by some other apps maybe? Not just kernel...
cmonex said:
that's it for now, maybe i'll post more tricks from now on.
Click to expand...
Click to collapse
Keep'em going!
Cmonex, I was thinking.... I don't know smartphones really well, but does it mean, that if you patch SP's nk.exe, will they be able to run unpriviledged apps? Such as, for example RIL applications? I know, that they have to be signed with a priviledged certificate, not as in WM Pro...
I can confirm - disabling certificates works Ok.
cmonex - many, many thanks.
utak3r said:
Cmonex, I was thinking.... I don't know smartphones really well, but does it mean, that if you patch SP's nk.exe, will they be able to run unpriviledged apps? Such as, for example RIL applications? I know, that they have to be signed with a priviledged certificate, not as in WM Pro...
Click to expand...
Click to collapse
i think someone sent me an SP nk.exe and it looked the same loader code. so probably yes let me know if you tried that (i don't have a SP device)
utak3r said:
Please... be bored all the time
It could be interesting, it could be used by some other apps maybe? Not just kernel...
Keep'em going!
Click to expand...
Click to collapse
hehe, sure
as for certmod, OK, i'll post a guide on that soon. but basically you need to modify return value in CertVerify export. i prefer the NK.exe patch, because it is faster (no need to waste CPU time on dispatching the call from NK through filesys into certmod).
by the way it has some other interesting exports too, such as CabVerify (or similar), anyone ever seen that in use? we can patch all of them
cmonex said:
i think someone sent me an SP nk.exe and it looked the same loader code. so probably yes let me know if you tried that (i don't have a SP device)
Click to expand...
Click to collapse
Well, I don't have one, neither, but probably I will have some for a few weeks
cmonex said:
so, i got bored so why not post a new thread.
.......
.text:80030D14 F4 F0 FF EB BL sub_8002D0EC ---> LoadE32()
.text:80030D18 00 00 50 E3 CMP R0, #0
.text:80030D1C 41 00 00 1A BNE loc_80030E28
.text:80030D20 8C 30 94 E5 LDR R3, [R4,#0x8C]
.text:80030D24 CE 20 84 E2 ADD R2, R4, #0xCE
.text:80030D28 05 10 A0 E1 MOV R1, R5
.text:80030D2C 00 00 53 E3 CMP R3, #0
.text:80030D30 BC 3C D4 01 LDREQH R3, [R4,#0xCC]
.text:80030D34 0A 00 A0 E1 MOV R0, R10
.text:80030D38 03 90 83 03 ORREQ R9, R3, #3
.text:80030D3C 00 30 A0 E3 MOV R3, #0
.text:80030D40 BC 9C C4 01 STREQH R9, [R4,#0xCC]
.text:80030D44 3A E7 FF EB BL sub_8002AA34 ---> VerifyBinary()
in the example the BL after LoadE32, sub_8002AA34 is VerifyBinary. this is what you want to patch.
if you look you can see that if it doesn't return 0 it will exit the function that has this quoted code. so just go to VerifyBinary start and patch it to
MOV R0, #0 (00 00 A0 E3)
BX LR (1E FF 2F E1)
Click to expand...
Click to collapse
When trying to patch highlighted region with mov & bx lr , my pda locks at boot. Actually if i only make r0 = 0 then pda boots normally, but how can i check if certificates are disable ?
Or i have to patch directly VerifyBinary :
ROM:000353C4 ; =============== S U B R O U T I N E =======================================
ROM:000353C4
ROM:000353C4
ROM:000353C4 VerifyBinary ; CODE XREF: sub_3B584+150p
ROM:000353C4 00 00 A0 E3 MOV R0, #0 ; Rd = Op2
ROM:000353C8 1E FF 2F E1 BX LR ; Branch to/from Thumb mode
ROM:000353C8 ; End of function VerifyBinary
ROM:000353C8
I've already patch certmod.dll and i think that certs are disable ....
I've already patch nk.exe\s000 (full trust kernel mode) with success.
ThanX alot for your help .
p.s. Could you teach us how to patch any exe, dll or s*** with ida pro ?
of course you can't put a BX LR in the middle of InitModule(), it will totally **** up the loader.
the BX LR (with MOV R0, #0) must go inside of VerifyBinary().
to see if certs are really disabled... just take some driver dll that you know needs to load on boot, make sure it is not signed, and try to load it on boot.
or just take any dll or any exe, that is signed, then change some string inside, and do not re-sign and do not remove signing from it, and see if it still loads (on boot or at any other time).
if the answer is yes to these, then the patch works fine.
how do you mean your p.s.? the way to patch always depends on the goal. no general trick, just assembly, a logical enough mind and preferably some more high level programming knowledge is needed.
ThanX Alot !
Thank you very much from me, too. Nice work!
Could you write a little tutorial how to patch CertVerify (exported by certmod.dll) ?
Thank you again for your great work !
From what you post, looks like it'd be done the same way as the nk.exe way, but have it be
MOV R0, #2
BX LR
yes, CertVerify in certmod should return 2, but it is recommended to patch nk.exe instead of certmod for two reasons:
1) certmod is updated more often than nk
2) directly patching nk is better optimization.
+1: the second patch in nk.exe gives more advantages than just using the simple certmod patch.
cmonex, thank you for this beautiful patch, I wrote a small program for patching of nk.exe or full nb for rom developers.
ALEUT said:
cmonex, thank you for this beautiful patch, I wrote a small program for patching of nk.exe or full nb for rom developers.
Click to expand...
Click to collapse
thanx will try it . modified my os.nb and rom is booting so far ok . have to check the unsigned apps .
THNX
Confirmed booting.
ALEUT said:
cmonex, thank you for this beautiful patch, I wrote a small program for patching of nk.exe or full nb for rom developers.
Click to expand...
Click to collapse
thanks for helping with that, i never found the time to do this program
problems reported from users wont install some apps
I got no problem with version 2, all apps install very well, in version 4 i have problem installing garmin mobileXT after so many tries atlast sucessful, but card export after so many tries and 2 hardreset still wont install.
Click to expand...
Click to collapse
[Closed Thread]
..
sun75 said:
Ok, I searched other forums and I found some answers in the Mate 10 forum:
BEWARE-bla-l29c432b147-t3817241
I read all the thread, but I think our xloader is different, or maybe does not have the the version issue at this stage. But, yes, we have to look at it on every new Rom version... otherwise there is a brick or "can not return back" risk as they clearly discuss in their thread!
I extracted my xloader on my P Smart on TWRP:
Code:
dd if=/dev/block/mmcblk0boot0 of=/sdcard/xl1.img
dd if=/dev/block/mmcblk0boot1 of=/sdcard/xl2.img
The "good" file is only the first one, the second file is full of "zero".
I have on the phone v. FIG-LX1 8.0.0.152(C432): I have hex compared it with the one extracted from the Rom (update.app) and it matches perfectly. Ok.
So I downloaded other Rom zips randomly from .129 to the new .147SP1log
I hex compared all these XLOADER images one by one and all images are different in contents range hex 0x74c~0x873 and afer 0xF3B4 the entries of the compiling time (25 - 26 - 27 Dec 2017 and different hours) depending on firmware.
There is no 01/02 value at position 0x1a8 (that is 00 in every Rom).
Apparently -SP1log Rom has the "same" version xloader, so my question is the same: what is the meaning of SP1 and log suffixes in Rom versioning on Firmware Finder?
Click to expand...
Click to collapse
you can use this https://forum.xda-developers.com/mate-10/how-to/beware-bla-l29c432b147-t3817241 XLOADER Checking tool
..
..
sun75 said:
I've downloaded one of the Mate10 firmwares and I've compared the two xloader.img (mate10 and p smart), especially the first block, where is the "version" check. Apart the "xloader" string on top of the image, the first block is idenctical until hex 0x1cb, after that, they differ. They differ also in size: Mate10 (176Kb), and P Smart (69Kb).
Please see the attached jpeg.
Anyway, the "version" byte in Mate10 xloader.img is NOT only on offset 0x1a8, but also on hex offsets 0x474 and 0x740 ( @ante0 please take note of it: thank you for your thread which I started from! ) and in that hex addresses we have always "00"...
Click to expand...
Click to collapse
The tool was made for BLA and ALP, which both have either 01 or 02.
But!
Offset can't be 01 in 1a8 and 02 in 474, it needs to be either 01 in all or 02 in all.
Complete list:
0x1A8
0x474
0x740
0x231A8
0x23474
0x23740
https://forum.xda-developers.com/showpost.php?p=76538101&postcount=43
It's the same on Mate9, 00 in those offsets.
ante0 said:
The tool was made for BLA and ALP, which both have either 01 or 02.
But!
Offset can't be 01 in 1a8 and 02 in 474, it needs to be either 01 in all or 02 in all.
Complete list:
0x1A8
0x474
0x740
0x231A8
0x23474
0x23740
https://forum.xda-developers.com/showpost.php?p=76538101&postcount=43
It's the same on Mate9, 00 in those offsets.
Click to expand...
Click to collapse
So the tools is working for p smart or not?
..
..
sun75 said:
Ok, thank you for your reply...: I'm trying to figure out what are these firmwares -sp1 [log] out there because they are apparently indenctical to all the others (I compared the xloader images and are the same!) while in your threads, at least for Mate10, -sp1 firmwares are those with the "old" xloader...
So I'm a bit confused here...
Click to expand...
Click to collapse
Yeah, SP1 are 01 on Mate 10. At least some of them.
I belive they are tests of some sort, because B148 is certified so it passes safetynet while B148-SP1 is not.
sun75 said:
[Closed Thread]
Click to expand...
Click to collapse
Thread closed on request of OP