After banging my head with the update utility and a bootsplash stuck universal for like hours, I did decrypt the bootloader 1.0... Will do some reverse engineering and post what I find... :lol:
Update: decrypted Bootloader 1.0 is attached...
ady,
if this is true... congratulations!!!
you may want to share your knowledge with buzz and the other specialists ;-)
have a good success
peter
hi ady,
GREAT!
could you please tell me how you did it?
thanx
buzz
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
very interesting approach... )))
buzz
Thanx buzz.
something which I observed earlier while looking at the string table:
It has multilevel password protection and the password for each level i.e update, erase, dump, debug is calculated at runtime.
Moreover the access level resets to lowest after a certain time which makes it almost unhackable
There are strings related to CID meaning there might be a method to change CID
updated first post to attach the decrypted bootloader 1.0 for those who are interested.
Also I succesfully flashed the 1.0 bootloader on a device which was previously updated with 1.01...
Of course if was after hacking the RUU.dll. By default it doesn't let you update to an older bootloader
ady I have been looking at the bootloader of the prophet and the interaction between the romupdate utility and the phone with a software logic analyzer which has revealed a lot of information including the commands that romupdate runs while upgrading the rom.
I am in the process of compiling a list of bootloader commands which may be usefull.
Did you dump the commands while downgrading the bootloader.
Pete
you can find a list of commands very easily. just look at the string table. however not all commands are allowed and that is the callenge
Some commands do not appear to be secured correctly.
For example the rbmc command.
If I run it without a password it says no pemission enter any password and then it will run fine.
The password issued by the romupdate tool seem to be based partly upon the results of the info 2 command as far as I can tell.
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Rymez2K said:
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Click to expand...
Click to collapse
hi,
did you mean d2s command?
buzz
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
hdubli said:
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
Click to expand...
Click to collapse
;o))) I thought, this is about Universal 1.00 bootloader...
buzz
According to some source of information there are 2 types of Universal. One with G3 and another with G4 chips. G3 bootroms have string "HW Version : 1.40h" in bootloader and its version is 1.xx, G4: "1.40j" and version numbers are 2.xx. Your ROM is for G3.
And bootrom can be decoded from nk.nbf with alpinenbfdecode.pl script
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
If this is correct , i hope, ...the nk.nbf of JASJAR bootloader can be decoded from bal66 tool and one can get.nba file.But I was not able to decode further with imgfs tools...it simply fails to do that....
@hdubli
bootloader image - nk.nba - is not an imgfs. you cannot use mamaich's imgfs_tools on it.
bal66's tool cannot decode bootloader nk.nbf to nk.nba either.
buzz
Attached is the file...pls check
hdubli said:
Attached is the file...pls check
Click to expand...
Click to collapse
yes, that file looks to be OK...
buzz
another thing:
lnb command doesn't work on 1.0 or 1.01. Another command wdata is used instead to update.
the difference between the two commands is that lnb needs to have an nb image i.e. lnb lnbtemp.nb whereas wdata transfers the image directly from host computer memory (more hack safe)
Related
Which is latest version of bootloader in JAM??. Is there any version higher than 1.0??. Please submit...
i have 1.02
Due to some issues happened during big storage mod I have restore my phone from other old JAM backup. I think before that my boot loader is also 1.02 But now it is 1.0 . I did the d2s with 80000 0400000 full backup. Will it overwrite bootloader??. Can I upgrade my bootloader in anyway? Please help....
Do we have any advantages with latest version boot loader?? What difference we will have with the each versions??
SD Flashing can change your bootloader .. if you really want to change back your bootloader .. just use your old SD backup (the first/original SD backup that you made) then flash it to your device.. if you dont have it already you can change your bootloader using
itsme's PNEWBOOTLOADER.exe , the tool can upgrade bootloader of WALLABY, HIMALAYA and MAGICIAN .. tnx itsme for creating this tool ..
the only difference i see with different bootloader is during flashing .. some bootloader have some problem in flashing .. like in HIMALAYA .. 0.23 cant flash radio ROM using SD backup , 0.26b cant flash Extended_ROM in nbf, all version below 1.03 .. have this problem that sometimes it cant flash using a nbf(himaupgradeut.exe) and need to make a sd flashing..
Anyway my point is if u didnt find any problem using your current bootloader, i suggest to stay with that but if you do then thats the time that i can only suggest to change your bootloader .. anyway changing your bootloader can fry your device ..
-toe
To use pnewbootloader tool where can I get the rom file of the new bootloader version??
heres bootloader 1.02
15:03:32 Jan 24 2005
1.02 version: 1.38
3d1b0f86b5f1774c32982611b813abbb <- m not sure with md5 (pls itsme correct me if m wrong .. )
i dont have a magician so i didnt try it and i cannot guarantee that this is a correct bootloader
PS. This bootloader is for Magician and not for anyother device, i will not take responsibility for any thing that will cause for a brick device due for using of this bootloader .. please be very careful .. i already once killed my device due to bootloader ..
-toe
SD Flashing
Hi toenailed,
What's SD Flashing?
thanks
Toenailed:
could u be so kind to tell me what i'm doing wrong, i'm trying to upgrade / or maybe should i say fix my bootloader, when I do a pmemdump 80000000 00040000 I get little stuff, mostly it's blank.. (*uh oh*) I'm sure this is not the way it should be. I tried using it'sme pnewbootloader, and got an error
"Unable to find flash info offset, cannot disable bootloader writeprotect"
this is what i typed:
Code:
C:\exp\1\build>pnewbootloader.exe -f -o 80000000 -l 00040000 c:\flashboot.bin\BL1.02-1.38.nb0
Unable to find flash info offset, cannot disable bootloader writeprotect
also tried the simple
Code:
pnewbootloader.exe BL1.02-1.3.28.nb0
I'll post my setup in a bit, i'm trying to re-flash my devices SHIPPED roms, hopefully that will restore things.. (crosses his fingers) anyways what I think I did is erased the GSM bootloader, thus I cannot use my phone at all, the close i get to using my phone is getting to WinMobile.. anyways this is really not a problem thus I called my carrier and they are going to ship me a new one.. I just wanted to known for sake of knowledge and if someone else has the same problem.. also just incase i do it again with my new phone, doubt my carrier will fall for the "I pulled out my battery, and now my device is dead" lol heck i even think I erased my ESN and PRL out of my device, since I get N/A when i'm in Mobile..
[/b]
it means that i did not add code for your specific rom version to pnewbootloader.
what is the OS version you are using?
willem
Oh sorry about that: it'sme, (btw thanks for ur great tools, and website, full of resources). currently I just upgraded to the PDA2k_WWE one, that was just posted recently here is the info...
ROM VERSION: 1.40.00 WWE
ROM Date: 03/10/05
Radio Version: [blank]
Protocol Version: [blank]
ExtROM version: 1.40.176 WWE
but the ORIGINAL one that came with this device is:
I'm not sure if the info below is correct so I also provided the actual full filename of my update..
HA_VZW_13500_115_01140_WOC.exe
MODEL ID: PH20A3
ROM VERSION: 1.35.00
ROM DATE: not sure, since i don't have it installed atm
Radio Version: DM FAIL
Protocol Version: DM FAIL
ExtROM Version: 1.15
also do u happen to know how to bypass the NOT ALLOW UPDATE when using a SD card? I tried to do a radio dump first. but i get Radio stack fail (tm). also i think i messed aroud with some of the rroute rrouter settings, could u possibly tell me what the default/correct settings might be?
thanks lots..
oh yea, and also using xdatools, when I try to use them, It either says that my image is to big, or it says it's to small, or it says cannot connect to USB using Programme a
thanks again..
itsme said:
it means that i did not add code for your specific rom version to pnewbootloader.
what is the OS version you are using?
willem
Click to expand...
Click to collapse
Hello "itsme"... I have a little question to you...
It's posible to use 'pnewbootloader.exe' to flash any OS ROM offset using the '-o' and '-l' parameters?
Thanks :wink:
Hello toenailed / itsme..
Before I'm trying to change my bootloader to the 1.02 (and it can be a disaster some times) what are my advantages with a newer bootloader like 1.02 from 1.00. Now I'm sure before the SD flash restore from another JAM mine was 1.02. Do I have (with 1.02) a higher performance or bugfree or more support to hardware device? I have also notice one thing after this change to 1.00. Some time after soft-reset I will a "Unidentified USB device error" and it will prompt for correct USB driver and bluetooth will not work for sometime. But after 5 mins it will start working. This problem will not occur if I'm removing the main battery for a soft-reset.
Is this issue could be with bootloader version? Other than the OS booting and loading what else bootloader doooo??
zxvf: i don't think you are talking about a magician rom.
the 'not allow update' means that you restore a backup made with a different bootloader version. .... or that the sdcard contains an invalid signature.
MKS: in theory, yes, but for several locations in the ROM, the protection needs to be removed.
the protection is a list of values which specify where the non-flashable area of rom starts and ends.
pnewbootloader temporarily changes these non-flashable area's to something not in the ROM.
nishadks: there is no real need to upgrade your bootloader, it is more useful, to downgrade, since older bootloaders, usually have less protections built in.
Thanks a lot itsme for your help....
Itsme:
You are correct, I didn't pay attention to it being a bootloader for the magician, (eventhough it's bolded lol) anyways, I tried it ones again, with a rom that I KNOW is the same that I had, because before messing around with it, I made a backup with two different tools osupdate.exe and bootblaster.exe (the one from handhelds.org for unix flashing). So i have this files both as .bin files, but can't seem to use the l command AT ALL eventhough I have both of the passwords, (actually don't really know how to use mtty.exe) I can't get the concept on how u send the files.. because it timesout and says something like "the second computer timed out.." or something like that, it seems that I need to start some type of send transfer something similar like (tx, and rx) in unix.. but not really sure how to do this with mtty.exe, or do i actually need to have a serial cable, is it not possible with the cradle that came with the device? I was actually thinking on creating a cable since, I got a USB to Serial converter... so maybe that will work.. but havn't had much time to mess around with that...
I also tried every possible version that u said is supported in ur .cpp file and none will actually work with my device, they all just make my device screan white and it starts fading out to black, (or sometimes it starts with a diff color.)
so what should I do/try to get pnewbootloader.exe to work? or is there any software that I can use in Win mobile (on the pda) to just run it locally?
Cheers, and thanks again...
how to use pnewbootloader
hi mate would u plz like to to tell me how can i install b0otloader 1.02 on my magician. i hav tried to use pnewbootloader but cant find any help abt it how to use it. i hav 2 magicians 1 hav bootloader 1.02 and other 1.0.
the problem is i cant read my high speed sd card on magician with bootloader 1.0. but it works on magician with bootloader 1.02 both hav same versions of roms. i hav extracted my bootloader from newer one but dont know how to copy it on old 1.
if possible than email me on
[email protected]
thanks
bl*.nb
Please someone where I can download any version of the bootloader. I can not download on the link in post number 7
thanks, and sorry for my google translate.
same for me, page goes blank, and download never starts
All right... GOOD NEWS story for today!!!
There is no doubt, that our gods are helping us...
Here's what happened to me yesterday.
Yesterday I was dreaming about editing the ROM of Universal/Exec but as you may know, 'd2s' command doesn't work. It just quits with "Not allow operation".
But suddenly, my china god of wisdom whispered to me:
GOD: "hey buzz, you wanna dump the thing? why do you use that old fashioned 'd2s' command to dump it?"
me: "well, that always worked... so what else should i use?"
GOD: "OK, here's a little present for you ) just try 'task 32' )) "
Code:
USB>task 32
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=1DC00
d.block_size=200
d.RCA=EC7E
d.drv_type=40000000
d.busWidth=1
Total card size=3B80000
So here it is !!!!
... and LET THE FUN BEGIN!!!
The above story is 100% true, i've made up maybe two words myself...
BTW, this might also work on other "password protected" devices.
THANX
buzz
Buzz, that's great, where the heck did you find that command?
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Can you restore back to the device from the SD card?
Going by the way of the SD card to dump, extract, modify, write back, then flash may be safer than the Upgrade Utility that keeps my device stuck in Bootloader mode until I go through the whole NK/MS, then Radio upgrade.
So, what's the opposite of 'task 32?'
Thanks!
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
buzz_lightyear said:
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
Click to expand...
Click to collapse
Buzz, it is really good news. At this moment some of Universal (e.g. T-mobile) providers have not released an update yet. So if people can dump their roms on a SD, we at least have a fall back. In case of repairs the Universal will need to be updated again with a rom from the provider.
That is really a fantastic news!
If the restore test is successful, please just let all of us know.
Oh, and look forward to a complete dump backup/restore guide. :wink:
BeyondtheTech said:
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Click to expand...
Click to collapse
From what I've seen his tool incorrectly decrypts NBF, some blocks are mixed.
hmmm.....
i think that the "task 32' commande needs a little bit more tweaking...
Till now it was just saying OK... ready.. etc., but actually did not the dump... (
Code:
USB>task 32
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=F1F00
d.block_size=200
d.RCA=80CA
d.drv_type=40000000
d.busWidth=1
Total card size=1E3E0000
Level = FF
USB>
Well, "Level = FF" sounds like an error to me....
hmmm....
buzz
Another very interesting command and it's output:
Code:
USB>info 2
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD:Detected one card
SD:ready for transfer OK
d.total_lba=F1F00
d.block_size=200
d.RCA=80CA
d.drv_type=40000000
d.busWidth=1
Total card size=1E3E0000
HTCSDOPOD601 «Jú½HTCE
USB>
Code:
USB>info 7
HTC Integrated Re-Flash Utility for bootloader Version : 1.40h, UNIVERSAL HW Version : 1.00
Built at: Sep 2 2005 15:14:29
Copyright (c) 1998-2005 High Tech Computer Corporation
Turbo=312, Run=208
Memory Frequency = 208 MHz
SDRAM Frequency = 104 MHz
Board ID is: 5
USB>
buzz
buzz_lightyear said:
Code:
Board ID is: 5
Click to expand...
Click to collapse
Hi Buzz,
is it possible to make memory dumps
in the bootloader without entering a password ?
cr2 said:
buzz_lightyear said:
Code:
Board ID is: 5
Click to expand...
Click to collapse
Hi Buzz,
is it possible to make memory dumps
in the bootloader without entering a password ?
Click to expand...
Click to collapse
not in bootloader...
but i'm able to dump DOC and memory using RapiEnabler and itsutils.
buzz
buzz_lightyear said:
but i'm able to dump DOC and memory using RapiEnabler and itsutils.
Click to expand...
Click to collapse
Hmm. What part of the DoC ? All 128 MB ?
There is also OTP and other stuff.
As you can guess, i'd like to dump the whole 64MB RAM (or as much as possible) while the bootloader is running, not
in wince.
Maybe you should try 'r2sd' ?
mamaich said:
BeyondtheTech said:
But now that bal666 has that decrypt/encrypt utility of the original NBK files, what would be the benefit of dumping the ROM to the SD card?
Click to expand...
Click to collapse
From what I've seen his tool incorrectly decrypts NBF, some blocks are mixed.
Click to expand...
Click to collapse
He stated that as long as you don't change the header information, it will encrypt and decrypt properly.
As a precaution, I took the NK.NBF, decrypted it to NK.FAT, then reencrypted it and did a successful byte-comparison.
I did the same with my modified NK.FAT file with my injected custom splash image and it encrypted and decrypted properly.
The biggest test was flashing it, and man, I was sweating buckets during the process. But, the flash came through successful for me and now I have the first custom splash screen on the Universal.
It's fun to break news or be the first guinea pig to try it out, just as long as it comes out successful! :lol:
The password doesn't seem do do anything.
The level of access is determined by your CID.
If your CID is 11111111 you have a SuperCID, which enables all the operations. I'm trying to track down where the CID is stored.
Bye,
Ricardo
go beyoundthetech !!!!
now only if you could post a step by step for all us goofs out here...
also im wondering with your genius if you could use the recently posted tools here to make custom universal rom (minus the ie explorer, file explorer etc) and teach us how to do that aswell!!!!
buzz_lightyear said:
i'm dumping at the moment, but i would say, that it would be enough to insert the SD card back into the slot and reboot into bootloader mode.
Then you have to wait few seconds till "press power to flash" message appears.
But so far i didn't test it, yet...
Testing right now...
))
buzz
Click to expand...
Click to collapse
My 9000 has a SuperCID. I managed to dump and flash the rom using these techniques.
Bye,
Ricardo
BeyondtheTech said:
He stated that as long as you don't change the header information, it will encrypt and decrypt properly.
As a precaution, I took the NK.NBF, decrypted it to NK.FAT, then reencrypted it and did a successful byte-comparison.
I did the same with my modified NK.FAT file with my injected custom splash image and it encrypted and decrypted properly.
Click to expand...
Click to collapse
I decrypted nk.nbf to nba with his tool, and decrypted the same file with alpinenbfdecode.pl script. Files are different after some offset. So there should be a bug in his util, because alpinenbfdecode.pl is known to produce working files. I had no time for more tests.
buzz_lightyear said:
Another very interesting command and it's output:
Click to expand...
Click to collapse
Hi buzz,
i can run "rbmc", but don't get where is this c:\test\mem.nb located.
Is it used by the mtty download protocol ?
I can't test it because mtty is not working
for me in windowz
cr2 said:
buzz_lightyear said:
Another very interesting command and it's output:
Click to expand...
Click to collapse
Hi buzz,
i can run "rbmc", but don't get where is this c:\test\mem.nb located.
Is it used by the mtty download protocol ?
I can't test it because mtty is not working
for me in windowz
Click to expand...
Click to collapse
looks like rbmc is running up to the point, where it should start saving the dump (
same as task 32
(
buzz
OK, so here is, how it should be:
Dump Bootloader:
Code:
USB>task 32
USB>d2s 70000000 80000
OS ROM + splash:
Code:
USB>d2s 70100000 3FA0000
XtendedROM:
Code:
USB>d2s 74100000 A00000
Radio ROM:
Code:
USB>d2s 60000000 a24200
If you want to have them all on single SD card, you must add "sd a" at the end of each command except the first one.
Example to dump/backup OS + XtendedROM + Radio:
Code:
USB>d2s 70100000 3FA0000
USB>d2s 74100000 A00000 sd a
USB>d2s 60000000 a24200 sd a
buzz
Hey Folks,
After a long weekend of reversing I am about 95% done in reversing IMEI-CHECK's unlocker for the Wizard.
The application is protected by Themida which is in my view the leading protector on the market currently (yes better than execryptor).
The unlocker has Ring0 protection, Emulated API's, Resource Encryption + Lots more fun and games.
Now onto what I have found so far.
The GUI stuff:
Code:
set 1 0
set 5 ffffffff
set 2 0
set 6 000000
set 4 000000
progressbar 0 239 0 255 ffffff 100 0
shmsg 0 0 " . : | Wizard Unlock | : ."
info 1
shmsg 3 0 " ..detecting device.."
set 32 2
info 0
shmsg 4 0 " >>> Wizard found"
Is plain to see, but the evil work is well tucked away in a procedure which is pushed onto the VirtualMachine.
So I still need to fish that out (loooonnnng task)...
However the very most interesting part (I find) is the existance of a ROM inside the unlocker.
Now I am not sure if this is the bootloader/gsm rom however it certainly seems VERY interesting that it is included.
Download:
http://rapidshare.com/files/12763879/_00CC0000.mem
For those who wish to analyse it and let me know which it is and if anything has been altered.
It might well just be standard, who knows :S
The following tools are also 'picked up':
Filenames:
Code:
PORTMON.exe
SnoopyPro.exe
Device Monitor.exe
Window Titles:
Code:
Portmon Class
SnoopyPro
USB Monitor
Device Monitor
Serious Serious Kudos to the developer, Very impressive work indeed!
By making this, he has almost made himself a license to print cash.
Since he has NO terms about his programs what so ever then there is no legal problems with what I am doing to his application.
He is probably too scared of HTC anyway, since he is decompiling their firmwares in order to make the product. (Which is outlawed in HTC's terms)
Anyway....
Watch this space
Very interesting, would information gathered from the Wizard unlocker lead to cracking the Treo 750 unlocker? Or any other phone that imei-check supports for that matter?
Whiterat said:
After a long weekend of reversing I am about 95% done in reversing IMEI-CHECK's unlocker for the Wizard.
Click to expand...
Click to collapse
Great, will you disclose your findings? there was an earlier post about the unlocker for G4 wizards, here (see comment #36):
http://forum.xda-developers.com/showthread.php?t=284312
Whiterat said:
However the very most interesting part (I find) is the existance of a ROM inside the unlocker.
Now I am not sure if this is the bootloader/gsm rom however it certainly seems VERY interesting that it is included.
Click to expand...
Click to collapse
It seems that this is the patched SPL that is flashed on the first unlocking step, it is modified so that when it is told to flash an splash screen, it flashes the security area, overwriting the CID.
Whiterat said:
For those who wish to analyse it and let me know which it is and if anything has been altered.
It might well just be standard, who knows :S
Click to expand...
Click to collapse
I will load it at IDA and compare with a normal wizard SPL...
Whiterat said:
Serious Serious Kudos to the developer, Very impressive work indeed!
By making this, he has almost made himself a license to print cash.
Click to expand...
Click to collapse
Yes, the imei-check guys are doing great job with their unlockers... similar method is used in artemis unlocker too. They load a modified SPL in RAM and jump to its physical address from WinCE, this modified SPL shows the DOC ID in help of "set" command and allows flashing unsigned code, then they use obtained DOC ID info to patch the security area by sending a "fake" splash screen, same as in wizard unlocker.
Whiterat said:
Watch this space
Click to expand...
Click to collapse
I will
phoa not much point in me continuing!
You've got the whole lot there!
I'm a lover not a coder, I simply reverse in order to help others succeed.
Since you have all important info anyway, Not really going to be of much help here
P.S do you have any sigs for IDA or any scripts?
I dont like having to sift through manually as binary file......
Whiterat said:
phoa not much point in me continuing!
You've got the whole lot there!
Click to expand...
Click to collapse
Well I didn't want to discourage you on continuing the reversing process, I just pointed you to the thread where we discussed about the unlocking method a while ago...
I admire the fact that you reached that far only disassembling / debugging the binary, what we actually did to have the full process was capturing it with USB monitor; the unlocker can be tricked if you run the usb monitor process as one user, ant the unlocker as a different user, but imei-check seem to have corrected this 'bug' in newer unlockers.
Whiterat said:
Since you have all important info anyway, Not really going to be of much help here
Click to expand...
Click to collapse
We don't have _all_ the important info, we have the commands that the unlocker sends to the bootloader, but the data sent to flash the security area is actually different in every phone, so flashing what is sent in one phone to another phone will actually brick it.
I think it can be helpful if you manage to reverse the algorithm that the unlocker uses to generate the code which is flashed on the security area, this can't be done capturing usb traffic, this has to be reversed from the binary, and Themida is not easy to break as you sure have noticed
Whiterat said:
P.S do you have any sigs for IDA or any scripts?
I dont like having to sift through manually as binary file......
Click to expand...
Click to collapse
No sorry, i don't have any... I am not very used to IDA, started using it few months ago and still learning new things about it everytime I start it
Ah cool I will look into it a bit further
(Need to get a friend to code a tool to remove the junk code)
e.g
PUSH EAX
PUSH EDX
MOV EAX,2282
INC EAX
DEC EDX
POP EDX
POP EAX
Since it is popping those registers off the stack, its actually altered nothing
Themida is a cow, Because my friend didnt manage to make a start on the junk code remover (and I didnt realise there was a virtualised function) I just did each Import by hand (approx 4 hours lol)
Also rebuilt the OEP by hand too, not too hard since it was VC++6.
I have a G4 which I have unlocked with Imei-Calc (thus I have the key file, which I *think* might decrypt parts of the program, or possibly is part of an encrypted rom.)
3 Last things:
1. Can the G3/G4 chip be worked out by IMEI, i.e IMEI represents a date and the chips were only used after a certain date? or is this tool generic for G3/G4 ?
2. Do you have an SPL for 2.08.10
3. How can I dump my SPL (bearing in mind my only minisd has a full backup of my rom, Just in case crossbow gets a little ugly for my liking)
Ohh one last thing, kbdus.dll on Crossbow.....Is there a kbduk.dll as far as you know?
My Wizard has british keyboard and all the chars are shifted +1.....
Thats my next major task I think before continuing on this thing
Btw, To use the usb logger on newer versions of IMEI-CALC, just rename the exe and change the class name
Hi..Answer on the "Last Three Things"
1.) No one cannot identify G3/G4 with imei.If u lok carefully the place below yr battery u will find a"G4" written besides yr imei no.In G3, nothing is written.The most commeon way is to check IPL/SPL .001 in the end is G4.
2) Take a ROM which has 2.08 SPL. and use typho5.exe to dismantle the ROM parts.If ROM is release recently then you will find IPL/SPL for G3/G4 both.Chek the threads here..
3) As such crossbow ROM has no IPL/SPL..if u know what ROM u were using prior to that, u can apply above to dump yr ipl SPL..secondly you can do this with awizard1.3 beta.
I hope this helps
-> IPL : Initial Program Loader
initial hardware bootup. just like a BIOS
-> SPL : Secondary Program Loader
it is the bootloader. jumps in the OS after Access the DOC and also starts the radio module.
Hi, a quick question regarding SPL.
I understood that it contains the s-on / s-off feature. If so, can the SPL be rewritten / patched? What programs could be used for this?
-> IPL : Initial Program Loader
initial hardware bootup. just like a BIOS
-> SPL : Secondary Program Loader
it is the bootloader. jumps in the OS after Access the DOC and also starts the radio module.
Hi! What programs could be used for rewritten the SPL
iuly_vn said:
Hi! What programs could be used for rewritten the SPL
Click to expand...
Click to collapse
on HTC you have to write a signed .nbh file. search on the forums for a how to
Technical data
could someone post more technical data on IPL/SPL such as generalised internal structure. hex header. etc. how exactly it works?
it looks more like a glossary of sorts rather than encyclopedia article as it it just giving a one sentence explanation.
And Whats HSPL? ...is it mean hacked SPL?
And Whats HSPL? ...is it mean hacked SPL?
Click to expand...
Click to collapse
No, it means Hard SPL
Sent from my Desire HD using xda premium
So whats the difference between SPL and Hard SPL?
Some more questions:
- Is the IPL useful in some way (except for being mandatory for booting up the device) i.e. for unbricking or something?
- Whats the common boot procedure? Being a little familiar with the kind of embedded processors used in phones I know that after a reset they normally execute some bootrom code which in turn loads code from flash (if configured this way) and would this be the IPL or SPL?
- Is there some standard interface for the SPLs? I am espcially interested to get a console via usb to perfrom some low-level functions like dumping the rom, executing code, etc.
I think I have more questions but I will ask them later.
symn4 said:
So whats the difference between SPL and Hard SPL?
Some more questions:
- Is the IPL useful in some way (except for being mandatory for booting up the device) i.e. for unbricking or something?
- Whats the common boot procedure? Being a little familiar with the kind of embedded processors used in phones I know that after a reset they normally execute some bootrom code which in turn loads code from flash (if configured this way) and would this be the IPL or SPL?
- Is there some standard interface for the SPLs? I am espcially interested to get a console via usb to perfrom some low-level functions like dumping the rom, executing code, etc.
I think I have more questions but I will ask them later.
Click to expand...
Click to collapse
1. The IPL is just good for all the hardware components afaik
2.The Boot procedure is: both system programm loaders are on at boot procedure
3. Similar...
4. What do you mean ?
Sent from my HTC Sensation XE with Beats Audio Z715e using XDA
tessut said:
on HTC you have to write a signed .nbh file. search on the forums for a how to
Click to expand...
Click to collapse
Kindly point me to any internal link on writing .nbh file... I have issues with my RIL (Baseband) and I'm thinking the SPL is corrupt or something. Flashing the signed one from the RUU might help but I don't know how to.
ayulatins said:
Kindly point me to any internal link on writing .nbh file... I have issues with my RIL (Baseband) and I'm thinking the SPL is corrupt or something. Flashing the signed one from the RUU might help but I don't know how to.
Click to expand...
Click to collapse
You can just extra it ^^
Sent from my HTC Sensation XE with Beats Audio Z715e using xda app-developers app
Hi Universal cracks,
i got a Qtek device which seems totally bricked.
The history of the device is unknown, so my investigation is getting deeper and deeper.
On gathering all information together it seems that the IPL and maybe also the SPL is damaged and cannot be easily revovered, because the bootmenu is not reachable in any way (believe me, i read everything about recovering intensely ).
That's why i'm looking for a general way to recover bricked devices using JTAG.
The idea is the following:
1. Access the device via jtag
2. Setup ram according to the setting used in wince or linux kernel
3. Rewrite IPL (it is yet unknown how to do it!)
4. Load SPL as executable binary into RAM using JTAG
5. Start the SPL from RAM
6. With SPL running from RAM Re-format the DOC reinstall SPL into DOC
Restart
That's it!
To resume my efforts so far i may report:
1. JTAG connection established (using OpenOCD or OCD Commander)
2. Init SDRAM (using intel PXA270 development kit setup)
3. Write a file to SDRAM and start it
4. Made a dump of IPL and SPL (using haret)
What did not work???
1. Access mDOC G3 in normal mode via JTAG (seems to stick in reset mode)...
2. Rewrite IPL using JTAG...
3. Start the SPL successful from SDRAM base address....
What do you think specialists!
Anyone willing to help?
Cheers,
scholbert
Hello Scholbert,
Sorry I couldn't help you out on this matter. But When I read your post I thought that you gone deeper than me in this technically.
So can Please go though my problem http://forum.xda-developers.com/showthread.php?t=353063 & help me out to solve WHITE SCREEN Problem?
Thanks in Advance.
bootloader
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Please could you post the patched version of openwince jtag?
Hi roglio,
roglio said:
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Click to expand...
Click to collapse
Maybe you're right , restoring the uni via JTAG could be mission impossible (at least the way described in my starting post).
As far as i got to know from various postings, the bootloader itself does some security checks during runtime (password checking, CRC checking ...).
It could require some real awful hacks, to start the SPL from RAM with an external debugger.
Please could you post the patched version of openwince jtag?
Click to expand...
Click to collapse
I made a lot experiments on other platforms using the openwince jtag.
In this case i used the famous OpenOCD:
http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD
There's PXA270 support out of the box!
You have to download the sources from their SVN-repository .
Anyway i'll have a look on my workstation in a few days, what could be of interest for the geeks out there.
Regards,
scholbert
Geek inside
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update. If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
I'll post any further step ahead.
Thanks.
roglio
Hi again,
roglio said:
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update.
Click to expand...
Click to collapse
this seemed to be happened to my device too. With single stepping starting at address 0x0 there's an error after some instructions. So it seems there's wrong assembler code in the IPL section already.
If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Click to expand...
Click to collapse
That's the theory .
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
Click to expand...
Click to collapse
Good luck for this action! I did compile it on a debian linux system.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
Click to expand...
Click to collapse
Let's assume we got a working device .
As far as i know, this is what happens after coldboot (comments welcome):
1. DOC is in reset mode, processor jumps to address 0x0 and excutes IPL
2. IPL initializes RAM, switches DOC to normal mode and copies SPL to RAM
3. further details of IPL functions unknown
4. leaving IPL, jump to physical address 0xa0000000
5. execute SPL ....
The problem is, that at this point various system checks are following.
If something goes wrong before we good USB serial connection or bootloader screen. The processor simply could stop at any instruction and we won't know why .
I'll post any further step ahead.
Thanks.
roglio
Click to expand...
Click to collapse
Good luck for your next steps!!!
Maybe, we may draw some attention with this little discussion. It would be nice to get things rollin' and someday there'll be hope for all those bricked devices around .
P.S.:
I already made bootloader dumps. See attachments!
IPL and IPL2 got the same content but they were dumped on different physical addresses. SPL was dumped from RAM. Of course these files were taken from a working device.
scholbert
Hi, after your description of the boot process I'm not so optimist anymore...
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Just a doubt: which configuration file are you using?
Does you have already configured also the flash banks?
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
This give me at least a hope...
Hi roglio,
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Click to expand...
Click to collapse
Great!!!
Just a doubt: which configuration file are you using?
Click to expand...
Click to collapse
I will post the configuration file as soon as possible (it's on my linux machine at work ).
Does you have already configured also the flash banks?
Click to expand...
Click to collapse
No, only the PXA270 chip select for the DOC device was set up. These NAND flashes need special initialisation to switch form reset mode to normal mode to be programmed or to read the filesystem.
This process was not yet successful using JTAG .
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Click to expand...
Click to collapse
If we are able to access the DOC device in a proper way, this may work.
At least there are professionel programmers on the market, that are able to reprogram these devices using the JTAG interface. But these are very, very expensive .
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
Click to expand...
Click to collapse
Yes basically this also possible for the uni, but this damn#?=% DOC device is very hard to handle. There's also no linux device driver for these devices yet.
Great work anyway!!!
This give me at least a hope...
Click to expand...
Click to collapse
Our hope should never die .
Best regards,
scholbert
Googling
Hi, scholbert! Today I was googling around and I've found some interesting informations about mDOCs... These special flashrom are internally handled as NAND flash but with the cpu (when used to eXecute In Place XIP) are handled as NOR flash chips. I haven't still found useful information to understand how this could be useful for our goal.
Another interesting information about mDOCs is that exists some pc software that permit to flash them via jtag but are part of very expensive development packages!
Anyway mDOCs are handled by linux! Basically it is possible to patch the linux kernel to handle them via trueffs. I'll be more detailed tomorrow, but my first impression is that these information about linux drivers for mDOC family aren't useful for our project...
Does you have retrieved the conf file for openocd?
Hi roglio,
that's nice information. I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Unfortunately, there's no source code of the low level routines to access this device. If someone would share m-systems BDK for the G3, you're welcome!
Does you have retrieved the conf file for openocd?
Click to expand...
Click to collapse
Yes, but i realized that i used a slightly modified one of the standard package (no SDRAM init, nothing but access PXA270).
You will find it attached!
My efforts with the uni using OpenOCD get stuck at a point, because i only got a very simple JTAG hardware. To use it as a debugger you also need to have influence on the systems reset.
That's why i decided to used some Macraigor stuff to get nice hardware debugger for accessing the universal hardware with OCD Commander.
Obviously both systems are very similar.
OpenOCD is completely GPL, so this should be first choice in the end!!!
You will also find the OCD Commander config file (htc-uni.zip) attached.
This could be the base for an OpenOCD script (very similar stuff).
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
I nearly forgot to mention, that you'll need to update the description for the stepping of PXA270 in the OpenOCD source code. If i remember correctly, the C5 is missing. Without it the PXA is not recognized correctly. I will post the updated file tomorrow.
Stay tuned!!!
scholbert
scholbert said:
I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Click to expand...
Click to collapse
Yes! Post it! Thank you! (or send them to rapidshare or similar).
scholbert said:
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
Click to expand...
Click to collapse
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Which tools are you using to decompile IPL?
Hi,
Yes! Post it! Thank you! (or send them to rapidshare or similar).
Click to expand...
Click to collapse
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Click to expand...
Click to collapse
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Relocate and compile would be nice too, but more work .
Which tools are you using to decompile IPL?
Click to expand...
Click to collapse
Someone in the forum pointed out to use radare. This was the starting point for further investigation.
At least radare uses objdump for disassembly.
So i decided to use the tools itself.
Here's a short howto:
How to convert raw arm binaries to elf and disassemble the code:
Although not every ARM code is compiled with the famous GCC (e.g. wince binaries) you may use some tools
of the GCC to convert raw binary code that is executable on ARM platforms.
Make sure that you made a real memdump or read out pure flash files from a known offset (reset entry points, direct jumps into code, etc).
In other words use pure binaries!!!
Otherwise this method won't work. It is nice to disassemble bootloader code for example.
Image files with filesystem information won't work, either!!
You'll need a working ARM cross compiler in this example the arm-none-eabi gcc version 4.2 from codesourcery was used.
1. first you have to build an elf-binary for ARM without offset (assumed 0x0) from the raw binary.
arm-none-eabi-objcopy -I binary -B arm -O elf32-littlearm ipl_0x0-0x800.bin ipl_0x0-0x800.elf
2. second simply disassemble the elf-binary!
arm-none-eabi-objdump -D ipl_0x0-0x800.elf > ipl_0x0-0x800.asm
That's it!
scholbert
Click to expand...
Click to collapse
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Regards,
scholbert
scholbert said:
Hi,
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
Click to expand...
Click to collapse
Ok... I'll look forward for these documents! Thanks!
scholbert said:
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Click to expand...
Click to collapse
Great!
After my jtag will be fully functional, I'll try to do some experiments running IPL from memory...
scholbert said:
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Click to expand...
Click to collapse
I'm a little rusty... but I'll try!
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Cheers,
roglio
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Click to expand...
Click to collapse
Yeah i know. I once worked with the eval version.
Very nice piece of software, but no freeware.
Good luck for your experiments!!!
scholbert
IPL disassembled
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Hi,
roglio said:
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Click to expand...
Click to collapse
Great work!
Here's mine. As you will see it's very equal (at least it should be ).
I made some comments already, but it's not finished yet.
The structure can be seen already. It is soon possible to reconstruct the whole asm code and compile it .
scholbert
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
@scholbert: wow you're always at least a step ahead!!!
Great!
@mo3ulla: hi! yes it is worth the effort because the chance to have skills to build a jtag connector is greater than have skills (and tools) to reball a bga chip (and program it!).
With jtag interface and a relocated IPL we can resurrect bricked uni simply loading it in ram and running. Then reflash the pda with a simple usb cable
Hi,
roglio thanks for the credits .
But at least this no competition, it's really great that someone took a look at this posting and started to discuss.
This goes out to you roglio .
mo3ulla said:
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
Click to expand...
Click to collapse
When i started this topic, i thought about a way to de-brick some uni's without touching the hardware. So roglio is absolutely right!
Once tried reballing at home???
At least the major point is:
Why touch the hardware, when it's a software problem?
Obviously no one got a programmer for mDOC devices!
If the universal would have NOR flash all things would be less complicated.
So what we are doing here, is to replace a 10.000$ programmer.
These professional devices do the same in the end, they use software algorithm to programm these NAND flashes.
The SPL uses the same software parts to reprogram G3 NAND flashes, but to start SPL (get into bootloader menu), IPL is needed. On a heavily bricked device these parts are damaged.
If we setup the device like IPL does or recompile IPL to run from RAM using JTAG, it could be possible to start SPL and get into bootloader menu.
The rest is already described here ....
Regards,
scholbert
O.K., here's dump from the bricked uni.
The screenshot shows the IPL section. It seems to be IPL version 2.36 which is for devices with a G4 NAND.
Mine is a G3, so this is the reason why it got bricked.
Someone updated the bootloader with a wrong version .
I enhanced the config file for the JTAG debugger with the settings i found out by disassembling IPL version 0.36 (G3 devices).
But unfortunately no success. The SDRAM is not accessible .
Without SDRAM initialised, i am not able do download SPL to the platform.
grumbl....
I'll have to check all settings again.
Especially the SDRAM setup...........
No time for that at the moment.
Anyone who'd like to join our experiments????
Cheers,
scholbert