A lot of phones will only boot if the firmware has a valid signature. Does the Samsung Wave check the firmware's signature (if there is one)?
In case of Bootloader I can confirm Signature check.
Because bricked after changing text...
boot_loader.mbn ---> yes, sure
dbl.mbn ---> not tested, but I think yes, because Qualcomm part...
All other files have no valid/mandatory Signature check.
You can modify all files.
Accept MD5 Hash for Multiloader, but this you can disable.
Handset self not check.
Best Regards
Can you tell us what you want to do??
Well, what I really want to know is if the hardware performs signature verification. For example, the bootloader in most HTC phones checks the signature of the firmware and will proceed to boot if it is valid. Replace the bootloader with your own custom bootloader and know checks are performed and you can put anything you want on it because the hardware does not check the signature of the bootloader. I also might want to modify Bada firmware, too. It is a different operating system or platform or whatever you want to call it and it looks like it would be fun to play around with. I own a Motorola DROID 2 Global.
Does anyone understand what I'm talking about?
Read it
http://forum.xda-developers.com/showpost.php?p=12213290&postcount=21
I'm afraid that is not clear enough. Has anyone tried to flash an alternative bootloader. And please, read my terminology. When I say bootloader, I mean software not the etched boot rom.
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
In case of our Flash Tool Multiloader we have only 2 files:
boot_loader.mbn----> "Samsung part"
dbl.mbn------------> "Qualcomm part"
As we have 2 CPU inside, 1 from Qualcomm... Call Processor, the other from Samsung = Application Processor.
So in most cases dbl.mbn is complete untouched in my tests. But I've failed in:
---> changing to oldest "unprotected" Boot XXJB6
---> changing to S8530 Boot (dbl.mbn is 1:1 same)
---> changing to modified S8500 Boot = bricked, but reanimated with JTAG
You can see my attempts here:
http://forum.xda-developers.com/showthread.php?t=897468
Boot means boot_loader.mbn, but I was tooo lazy to write full.
Best Regards
Master Melab said:
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Rebellos said:
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
mijoma said:
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Click to expand...
Click to collapse
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Wave's bootloader use RSA, El Gamal, etc.?
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Sent from my DROID2 GLOBAL using XDA App
Master Melab said:
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
Click to expand...
Click to collapse
iROM is a chip that contains code to load the very first bootloader from NAND, it cannot be modified i believe.
Rebellos said:
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
Catching errors, maybe?
Master Melab said:
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Eave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Master Melab said:
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Click to expand...
Click to collapse
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
mijoma said:
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
Click to expand...
Click to collapse
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM. The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Master Melab said:
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM.
Click to expand...
Click to collapse
Sorry, but if the area is not programmable it does not mean it's not software.
When thinking about 'embedded' world, leave the PC world alone. The list of differences is longer than the list of similarities.
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion). The formal logic would require to show exploitable vulnerability first and there isn't a generic one.
Master Melab said:
The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Click to expand...
Click to collapse
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
What value does the strict lowest level protection policy have when higher level introduce (with increasing probability with each level) vulnerabilities easier to exploit?
Does the Wave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
mijoma said:
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion).
Click to expand...
Click to collapse
Please, explain.
mijoma said:
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
Click to expand...
Click to collapse
Things like a BIOS or true read only memory have instructions or data encoded into the layout of the circuitry itself. Usually, fuses are either broken or left intact and this may either mean a 1 or a 0, depending on the manufacturers device works.
adfree said:
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
Click to expand...
Click to collapse
adfree, when I say "etc." I mean "et cetera", which in Latin means "and other things" or "and so forth". El Gamal is another asymmetric cryptosystem that relies on the difficulty of factoring a large composite number, just like RSA.
And thank you for the file.
Related
Windows Phone 7 has standardized the bootloader requirements for OEMs. No longer will an OEM be allowed to implement it's own design for ROM deployment (such as HTC with the .nbh/RUU system, .dz/LGMDP with LG, etc.)
The image format will be B000FF/.bin, which receives only minor changes from CE5, and so our current tools should work fine with this. The major change is in the way the bootloader handles image deployment. For Samsung and a handful of other manufacturers, this won't change too much, as they already utilize the B000FF system for deployment. The filesystem inside will be IMGFS - no longer will BinFS be used for NK/XIP section (now IMGFS will all partitions on device, NK and OS just being split by package rather than a seperate FS)
The physical flash layout will look as follows:
Reserved Regions, updateable only through a special oem-written driver to allow access to this area (size varies)
Partition Table (1KB)
BLDR (1MB)
DBSP (Device Boot State Partition, 256KB)
DPP (Device Provisioning Partition, 256KB)
USP (Update State Partition, 2MB)
ULDR1 (>=6MB)
ULDR2 (>=6MB)
NK (IMGFS, >=4.5MB) - At least 1MB free space for updates
OS (IMGFS, >=181MB) - At least 20% free space for updates
User Store (TexFAT)
Only the User Store (Which uses new Transaction-Safe ExFAT filesystem) will be user-writeable, all other areas will only be writable during an update operation. The Partition Table, DBSP, DPP, USP, and User Store are all not updateable during an update operation, only during a full-flash scenario. B00FF images are signed and checksummed, and passed through to the bootloader via ethernet over usb. The connection will most likely be encrypted, using the same flashing utility as Zune HD. (This is currently used to deploy images to the DevKits)
.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.
Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed.
As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD.
Similar to CE5/WinMo 6.x, There is a BLDR (Base Boot Loader) which makes the initial determination to boot up to the ULDR or to the WP7 OS. The OEM implements alternate boot parameters to trigger this and/or a button press combination. If ULDR is triggered, it checks the battery and power source to ensure that there is enough life remaining to successfully complete the flash, then awaits the flash download. There are redundant ULDR partitions (ULDR1/ULDR2) to facilitate failsafe recovery in the event of a failed ULDR flash (ULDR provides a basic level of functionality to enable a recovery flash even in the event of power failure during a flash)
MSFT is pushing it's Phone Update service much harder this time - it is intended to be used as the primary method for distributing phone updates. These can be deployed both over-the-air and through a USB connection with the Zune software.
subscribe to this......need to learn before my next device.
Thanks. I didn't see these threads before. Any chance you could share or point to the docs this info came from? It seems tweakers.net acquired it and I wouldn't mind looking through.
saved for future use! Da_G is the master of the roms!
As Usual Da_G you are cool..
Will you make this thread a Sticky for us? Thanks again G.
da_g said:
bump for visibility
Click to expand...
Click to collapse
bump! Bump! Bump!
Da_G you always rock, now we got a huge info.
thanks for your infos
that is some good news eventually have custom ROMs on wp7
thanks!!!!!
So you are saying that we will be able to cook for WM7, but wont be able to get a HSPL to flash it?
Well done Da_G.
Da_G said:
...
.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.
Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed. As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD...
Click to expand...
Click to collapse
Hi Da_G,
How can I get my hands on these files: not wp7 os but the other partition (dpp/bldr/uldr/imgfs/etc) contents? What IS known about wp7-fs? spl?
Do you have ANY dumps - even ZuneHD equiv? maybe the source of your .ffu info and an actual .ffu? Thanks there- pm me if you get the time. Yeah... I am noob here but interested in moving into rom-dev; used to do xbox-1+live and do have jtag, logic analyzers+trace, etc here. How would I begin? Once again: thanks and well done!
Edit/Update:
Perhaps with Cotulla's partition layout over 4 seperate nand areas it would be an option to modify this and his wp7 spl because the activation thing happened AFTER (live activation hack around etc) he had finished leo70 release and then..........
-whilst jtag/usb or eth/debug happening- (obviously you'd though of this b4- im just theorizing- let me know if way off)- to take a HTC HD2 (LEO70) that HAS BEEN ACTIVATED ON LIVE and see where/how/when/with/which partitions, filesys, regkeys, etc, have pvk for live or the ffu and then insert a test cert like ur own xbmod/chevron. or whatever is in sdk for 7 or ce. and then utilize this to diff and comp. I dont see why not. Then .ffu then self signature.
Now THAT'S cool! Thanks, Da_G!
This would mean, that we basically could get custom Rom's on WP7. Can't wait to see the first ones
Interesting info. Subscribing to it now....
Thanks or the info Da_G!!!
eh?
Did you look at the post dates before you all started subscribing? Almost a year now, doubt you'd see anything new ... but this and more 'subscribed' and a possible 'sod off' post.
Is this the only discussion on the topic? I'm sure im not the only one looking forward to having an unlocked bootloader. Any updates?
surrender420 said:
Is this the only discussion on the topic? I'm sure im not the only one looking forward to having an unlocked bootloader. Any updates?
Click to expand...
Click to collapse
See the first thread in this sub-forum.
Hi everyone,
Many people have complained about the Wave bootloader being closed and that being major problem for the development of alternative OS.
I had a closer look at the booting process and would like to contribute my observations to the community. I shall have little time (next to none) to work on it further, so I'd like someone to take it from this point.
OK, that said I can introduce you to what I found:
The booting process starts with initialization of the hardware, interrupts, etc. and gets to the selection of the booting mode. This is the place that checks the key combination, JIG and possible problems. Basing on this the bootloader will run the phone in either normal boot mode, go to dowload or upload mode.
Normal boot shall start with checking the FOTA module. If you already tried flashing your phone you probably noticed that some versions of the FW include a file with *.fota extension. The file is unencrypted and not signed. It's about 2MB, but the bootloader reserves exactly 3MB for it. FOTA is intended to be used for firmware update over the air, but I know nothing about it being used for Wave. You may read something about the design and get a concept of that process here:
http://www.freepatentsonline.com/pdfb/documents/usapp/patent_pdf/2010/017/US20100175062/pdf/US20100175062.pdf
Basically, it is possible that boot would need to perform some actions that are a result of FOTA. Therefore, during the normal boot it reads the FOTA module from the NAND (0xC600000) and checks whether the module exists and is in the right version. That is done by checking a magic (text "FOTA_ENGINE_VER_INFO_2.0") under the 0xC600100. If it is found missing or incorrect you will end up with the message "FOTA Engine is not intalled" or "FOTA Engine version mismatch" on the screen and you will need to restart your phone in the download mode to load it.
After that, the code checks for additional magic values at 0xC880000. In case it is "BPDZ" it jumps to the code in the FOTA file. The contents of the file is loaded to RAM location 0x43800000 and executed from there.
I've made an experiment as a proof-of-concept and have a confirmed that the above is true and valid information. I crafted a FOTA file longer that the usual attached (to be bigger than 2,5 MB). In case you want to repeat that, remember that last 1024 bytes are not loaded and insert additional data before that. My file had two magic values:
"FOTA_ENGINE_VER_INFO_2.0" at 0x100 offset and "BPDZ" at 0x280000. At offset 0 I've placed my code that started with several NOPs (just in case) and code that called original bootloader functions to display text on the screen.
After loading the file with Multiloader, the message appeared on the screen as expected. Reloading of the original FOTA file made the phone boot normally.
The discovery opens wide area of possibilities starting with replacing bootloader without signing it or using JTAG, multiboot, etc.
As the original bootloader is in the memory as well, we can use it, but I would not recommend that approach as we would need additional version control and changing original routines and data addresses for each version.
OK. I hope I made it clear enough to understand, but I can clarify what I might have omitted in the description. The idea is that someone here would pick that up from where I finished and develop a decent loader leaving the original files (apart from FOTA) untouched.
Best Regards,
mijoma
-----------------------------------
Edit: Added proof-of-concept FOTA file (based on XXJL2 FOTA). Use wisely - remember you take full responsibility for what you load on your phone. Works ONLY with XXJL2 bootloader.
Very interesting ... great job
My little knowledge/experiments...
1.
Before I NEVER updated manually FOTA. I never seen any Errors like other user... with FOTA not installed or something similar.
Maybe reason is, because my testdevice has NO active SIM card, so no network...
2.
I've tested examples from mijoma. On XXJL2 Boot...
Simple only flash FOTA with Multiloader.
At your own risk. Not all sideeffects known.
I had NO problems.
3.
Results... I can't see any special after Flashing. But I can go through internal menu, see Pictures.
http://forum.xda-developers.com/showthread.php?t=906966
Normally I have more messages... but with modified FOTA Wave restarts. So the way is correct.
4.
Delta files are sometimes in Firmware also with Boot... I will add next Link to what I found about Delta files...
Delta Files are part of FOTA concept...
5.
Depend on Firmware... Software update... but sometimes is this point removed and I can't login, because no network...
In other words, I have to start FOTA over this internal menu to see that it is doing something.
Best Regards
@adfree
I think you are testing the previous version. Could you confirm you are using mod version 2?
Best Regards,
mijoma
bplib_S8500OpEuro_XXJL2_mijoma_mod2.zip
You are right, not tested yet. Only prior Version.
I will test today mod2 and report later.
I have to flash back to XXJL2... as I play actual on Orange JE7.
Thank you.
Best Regards
YT: watch?v=A35k3E1F1O4
It's working....
Best regards.
Amazing job dude. It seems like this could help us to change booting stuff
Nice work mijoma !!!
I can confirm it works.
Now I see the same like on this Video:
http://www.youtube.com/watch?v=A35k3E1F1O4
Thanx jedil1 for Link.
Sorry mijoma.
I have no idea where I made mistake...
This time my first Test was Full Flash (without Boot)...
Second only FOTA and it works too... Original, then yours...
If you flash "Full", then you interrupt the Index process at Start, where Blue Screen shows...
Best Regards
Great job!!!
And my opinion,this is a single way to starting full working android on s8500,
because we need to initialize the modem at bootloader stage for fuel gauge.
i temporary use modem from m130k without fuel gauge.
Few Firmware packages have Delta files:
Code:
delta.bin
delta_AP.bin
delta_CFS.bin
delta_CP.bin
delta_CRSRC.bin
delta_FS.bin
delta_LFS_01.bin
delta_LFS_02.bin
delta_RSRC2.bin
Around 16 MB...
If I use Google for "Delta Files FOTA"... then I can also find this:
http://www.faqs.org/patents/app/20100175062
Theory/ideas
What we also can do with this Security hole:
- maybe "move" folder System to SD or internal Memory, to have no more problems with RC1
- maybe someone is smart enough, to integrate Dump Function for Dump whole RAM or moviNAND... like JTAG
See Upload function...
Best Regards
adfree said:
- maybe someone is smart enough, to integrate Dump Function for Dump whole RAM or moviNAND... like JTAG
See Upload function...
Best Regards
Click to expand...
Click to collapse
I think that Samsung have thought of that already. I had not analysed that as so far, but there's UPLOAD option in the bootloader (handled by a bit separate code from DLOAD). I haven't got the wave, so I never tested it.
You can make a patch on my mod and place a direct jump to that code. I've made a quick patch so you can try it out. I don't know whether there's any software that can handle that mode. I've made a look and there are several funny commands that can be used:
"PrEaMbLe"
"AcKnOwLeDgMeNt"
"PoStAmBlE"
"PoWeRdOwN"
"DaTaXfEr"
Remember that this time we're dealing with some real functionality of the bootloader and that may have some consequences so use on your own risk.
Best Regards,
mijoma
----------------------
Edit: Sorry if anyone tried loading it. By mistake I've used addressing from XXJEE. I've changed the name to represent what it was and added a correct file for XXJL2 bootloader
Upload to PC is in combination with Debug Mode higher then Low...
After you see Bluescreen with very interesting infos you can press Button, then Upload to PC on Screen. But I don't know how to catch Data, as no COM Port is visible.
Btw...
Now I know where I made big mistake.
First tests I used XEKC2 Firmware with XXJL2 Bootloader, as I thought its only Bootloader related. Sorry.
My fault.
So there must be more then Bootloader from XXJL2 in handset, to run successfully FOTA Mod2.
About new Mod with Upload, I will investigate this time better, before I'll report.
Thank you.
Best Regards
We need to get this guy a wave to test stuff on! Who wants to donate theirs ha
sabianadmin said:
We need to get this guy a wave to test stuff on! Who wants to donate theirs ha
Click to expand...
Click to collapse
It may have sounded like a joke, but I second that....
He's seems trustworthy and very capable of being sucessful Just like adfree, oleg_k and other guys over there.
I have my paypal account limited but in 1 month I'll b able to donate maybe 20€
Thanks guys, but I don't think it's necessary.
I do it for fun - don't need any other gratification. Wave got me interested with the effort the manufacturer put trying to keep it closed. I don't need a handset to disassemble the bootloader.
The question is more would you like a wave for you're efforts as otherwise you really won't be able to benefit from you're own work when we have meego, android, webOS etc booting on the Wave. Theres no extra pressure, sure you have already done the trickiest part of the work.
No, I'm being completely honest here. I find this rather a weird form of relax than work.
Wave is a nice phone and I think I'm going to get myself one, but I don't expect a gift.
mijoma said:
Wave is a nice phone and I think I'm going to get myself one, but I don't expect a gift.
Click to expand...
Click to collapse
You are a champ, buddy
Good luck !
Sent from my GT-I9003 using XDA App
So I was reading that post about the guy who will fix bricked taps via JTAG, and thinking about how some it's necessary when the bootloader binaries don't flash properly.
This seemed to suggest to me that the download mode code is stored in memory, making it's method of interfacing with the memory controller and USB port subject to analysis through ARM disassembly.
I postulated that it would not only be academically entertaining to take a peek at such technomagic, but that it might be possible to produce a template bootloader that could serve as a basis for custom bootloaders across all devices, similar to the role CWM fills in recovery, and CM fills for the Android OS.
I reckoned a custom bootloader would not only complete the holy trinity of device operation, it would solve woes across all androids by enabling a common flashing protocol (no more ODIN, Heimdall, QPST, etc), and allowing focus on replacing locked bootloaders instead of exploiting them.
Of course, I wouldn't be able to verify my hypothesis without getting my hands dirty, so I whipped out the ol' IDA Pro and popped open the EA24 boot.bin and pressed 'c'.
God bless IDA Pro. I had beautiful ARM assembly just waiting to be learned (I'd previously only worked with Intel 8050 & PIC), but very quickly I realized that I wasn't going to get far in my analysis without information beyond the ARM instruction set reference.
Here's why:
Reason 1:
The registers are preloaded with data before the bootloader executes.
Code:
ROM:00000000 ANDEQ R0, R0, R0,LSL#16
ROM:00000004 ANDLE R0, R2, R0,LSR#11
ROM:00000008 ANDEQ R5, R2, R5,ASR LR
ROM:0000000C ANDEQ R0, R0, R0,ROR#4
ROM:00000010 B loc_30
Not only are the initial instructions skipped if the status flags are wrong, but registers 0, 2 & 5 are being compared and modified without the bootloader loading data into them. I initially suspected obfuscation, but the loader is tiny (only 1.5k of data is non-null) and the flow of code is pretty straightforward. It boots, checks some registers, and possibly takes action before waiting in a loop, (I assume in anticipation of a watchdog/shutdown interrupt firing).
So problem 1 is that I don't know how the registers look or what affects them before the bootloader is executed.
Reason 2:
The memory addressing seems to reference numbers that can't be direct memory addresses. Problem 2 is that without understanding how those addresses are interpreted, I can't understand the operation of the loader.
Code:
ROM:00000030 LDR R0, =0xD00374C0
ROM:00000034 LDR R1, [R0]
ROM:00000038 LDR R2, =0xE010A000
ROM:0000003C LDR R3, [R2]
ROM:00000040 LDR R2, =0xE010C034
ROM:00000044 LDR R4, [R2]
ROM:00000048 TST R3, #0x80000
ROM:0000004C MOVNE PC, R1
ROM:00000050 TST R3, #0x40000
ROM:00000054 BEQ loc_60
ROM:00000058 TST R4, #2
ROM:0000005C MOVNE PC, R1
So what's happening here (correct me if I'm wrong):
Code:
R1 = Memory Value [0xD00374C0] //Decimal Addr: 3,489,887,424
R3 = Memory Value [0xE010A000] //Decimal Addr: 3,759,185,920
R4 = Memory Value [0xE010C034] //Decimal Addr: 3,759,194,164
Followed by some potential jumps.
The thing is, a Sprint tab, for which this bootloader is designed, only has 2GB of internal memory, so all three address are completely out of range. This makes sense considering that ARM devices might have more than 4GB of memory. Some sort of register based memory context switching has to be in place.
Googling ARM memory mapping brings up info about mapping coprocessor registers and IO into the address space. The custom 8085 I previously worked with did something similar with its touchscreen sensors, so I'm not surprised.
With that in mind, the code would make sense if it is checking the external buttons before deciding whether to jump to the value in R1 (which has to be a real memory location to be put in PC). The tests are performed on the value in R3, so that could be the register that stores hardware button states, but R4 is also tested, so it could be only one or two of the buttons are in R3, or its some other state entirely (perhaps related to the mysterious coma semi-brick).
Regardless, it would be a fools errand to keep crawling through the assembly without better reference material on the initial state of the registers and how the memory is laid out. I was hoping that someone could can locate reference material or offer their insight, as it's been a difficult search on my own.
People like you boggle my mind. I didnt fully understand your entire writeup but if you get the the point where you are actually coding an open bootloader for android then may the force be with you. I would only assume that the android world would shower you with riches the like an xda geek has never seen.
Keep up the good fight.
Sent from my GT-P1000 using XDA Premium App
About 98% of everything in the OP was like reading japanese, to me
But whatever it was, I hope it's investigated and followed-up, cuz it sounds promising.
I think
The initial values of registers at boot should be in ARM manuals or sp5pc110/s5pv210 user, application or programmers manuals. Our ARM can even boot from serial port
See http://forum.xda-developers.com/showthread.php?t=1111866 especially download S5PC110_EVT1_UM10. With little hacking and discovering how to set up JIG resistors on Tab you should be able to boot your own code via serial.
I have made serial cable for myself and I use it to change bootloader parameters and with FIQ debugger, dmesg and serial console all the time.
very interested
i am just a beginner at this stuff but i am very interested in this stuff .i have a riffbox if this would help us at all for jtag.i am still learning about it and i am reading jeff Duntemanns assembly language step by step.i also have the free version of ida pro i think 5.5.i would love to pick ur brain for knowledge along these lines.
bootloader replacement is a very very bad idea on our SGT.
bootrom checks pbl, pbl checks sbl then sbl checks kernel.
now on our devices unless you have installed JMx leaked roms the bootchain is not sigchecked, bootrom does a small hashcheck on pbl before launching it, pbl does a signature and hash check on sbl (on GB bootloaders) and that is where it ends.
The problem is Download mode is implemented in SBL, so if you do not have a JTAG device like a riffbox there is no viable recovery method other than taking your device to samsung, but by far the biggest issue is pbl/sbl pairing, these 2 bootloaders are paired, and if they are mismatched the device is as good as a brick unless you have one of these devices.
There is one thing more important than a bootloader for all devices, and that is a viable recovery option for them. Most of the Tegra2 devices have this with APX mode, but it is still something that isn't all that common on android devices
If this can be done it would great. I suppose you could write a generic boot loader that could boot from sdcard or other linux os would be handy. All this stuff is a bit too low level hacking for me so good look in cracking this one.
Technomancer said:
The initial values of registers at boot should be in ARM manuals or sp5pc110/s5pv210 user, application or programmers manuals. Our ARM can even boot from serial port
See http://forum.xda-developers.com/show....php?t=1111866 especially download S5PC110_EVT1_UM10. With little hacking and discovering how to set up JIG resistors on Tab you should be able to boot your own code via serial.
I have made serial cable for myself and I use it to change bootloader parameters and with FIQ debugger, dmesg and serial console all the time.
Click to expand...
Click to collapse
Massive Samsung Techno Tomes! That's just the resource I need. Thanks a million. I had found a bunch of ARM memory controller references, but I couldn't find the processor specs to find out which one it uses.
reddog69 said:
very interested
i am just a beginner at this stuff but i am very interested in this stuff .i have a riffbox if this would help us at all for jtag.i am still learning about it and i am reading jeff Duntemanns assembly language step by step.i also have the free version of ida pro i think 5.5.i would love to pick ur brain for knowledge along these lines.
Click to expand...
Click to collapse
I hadn't even heard of a Riffbox till just now, but I am definitely getting one ASAP. $149 one stop shop for phone JTAG. That's way more practical than I would have imagined.
As for the brain picking, there's really only two things you need to know, at least about these snippets.
1) All processor types use different assembly mnemonic conventions, and most mobile/embedded stuff doesn't look like x86. eax, ebx, etc in x86 is generally R1, R1 in everything else. If you're starting out on an x86 book, be prepared to retrain your brain all over again when switching to anything else.
2) ARM has this thing were every opcode will be silently (no error state) skipped if the status register doesn't meet a certain condition, and every two register operation can have the second register translated before it is fed into the computation.
Code:
ROM:00000000 ANDEQ R0, R0, R0,LSL#16
ROM:00000004 ANDLE R0, R2, R0,LSR#11
The first line will only execute if the Equals flag is set. The second will only execute if the Less Than (signed) flag or the Equal flag is set. The flags are set by the previous operation, so whether these lines execute at all depends on what processor code ran before this, and whether or not its result was greater than.
Each operation also has the second operand logically shifted (LSL & LSR). The first line ANDs R0 and [R0 logically shifted left 16 bits] and stores the result in R0. The second line ANDs R2 and [R0 logically shifted right 11 bits] and stores the result in R0. There's a whole set of possible translations.
HTML:
lilstevie said:
bootloader replacement is a very very bad idea on our SGT.
bootrom checks pbl, pbl checks sbl then sbl checks kernel.
now on our devices unless you have installed JMx leaked roms the bootchain is not sigchecked, bootrom does a small hashcheck on pbl before launching it, pbl does a signature and hash check on sbl (on GB bootloaders) and that is where it ends.
The problem is Download mode is implemented in SBL, so if you do not have a JTAG device like a riffbox there is no viable recovery method other than taking your device to samsung, but by far the biggest issue is pbl/sbl pairing, these 2 bootloaders are paired, and if they are mismatched the device is as good as a brick unless you have one of these devices.
There is one thing more important than a bootloader for all devices, and that is a viable recovery option for them. Most of the Tegra2 devices have this with APX mode, but it is still something that isn't all that common on android devices
Click to expand...
Click to collapse
My thoughts:
1) Yes it's easy to do something stupid, but the worth of a plan is inversely proportional to the precision of it's execution.
2) If I'm reading this correctly, you're saying that the primary bootloader does the sig check on the secondary bootloader, the primary bootloader is hash or signature checked depending on the ROM version, and the primary bootloader does the check of the secondary.
I'm interpreting that as two things:
A) If some ROM's do sig checks and others hash, the bootrom is programmable, so the check is not only insecure on most roms, but it can be disabled or changed.
B) If I wanted to do custom download mode, I would have to make a primary bootloader that doesn't do an sbl verify, but is still accepted by the boot rom.
A tells me that shouldn't really be a problem.
3) You actually have three recovery options, two of which are pretty cool.
A) have samsung fix it (~$50-$100) - The lame route.
B) buy a riffbox and fix it yourself (~$150 + personal work) - A valuable investment in your personal skills and toolset.
C) send it to a guy (or girl) with a riffbox whose already done it (~$50). - support someone who has taken the initiative to be self sufficient.
4) Any decent phone (read basically all androids) can be unbricked using JTAG or better. It wouldn't behoove them to make a device they couldn't upgraded or that could accidentally permanently die during an upgrade. The issue then isn't whether or not you can fix it if you goof up, but how long you can wait for it to be fixed.
The fact that manufacturers like Motorola and HTC are now promising to retroactively unlock bootloaders shows that companies kept their bootloader checking processes mutable. This also makes sense since they wouldn't want to machine a million cellphones only to find out they accidentally locked them down with broken bootloaders.
Combined, this all says to me that the custom primary bootloader is a very good idea. Its impossible to kill most devices as long as you have a reasonably priced tool (or two), some brains, and some time, and as soon as a primary bootloader that skips the sbl validation is accepted, you're good to go.
-----------------
Thanks to everybody who contributed. I really wasn't expecting such quality responses, so you guys just made my night. I'm now proceeding to do stuff that isn't related to my android devices.
thanks
ya i got an arm book and i aee it is quite a bit different.i am going to start concentrating on.if anyone has a tab or any phone thars bricked and want to sell it let me know.i want to play around with my riffbox with them
What functions does the iROM perform in Samsung's Wave line of devices?
Sent from my DROID2 GLOBAL using XDA App
To be clearer, what roles does iROM fulfill?
Exactly the same as in SGS and Odroid with S5PC110, IROM code is exactly the same, it MAY differ between CPU revisions (there seems to exists 3 hw rev of this SoC CPU, evt0, evt1 and evt1-secure), however it has been not confirmed, and it seems that in all these phones are EVT1 revisions.
iROM functionality is pretty well described in S5PC110 datasheet, also on Xda SGS forum. In "lets save some bricks" you can find iROM dumps from I9000 and S8530 (exactly the same)
It CAN boot from oneNAND flash, MMC flash, UART and USB interface, depending on OM (operating mode) pins settings (there are 5 of such pins) in secure and non-secure boot mode (here iROM code is checking secboot key stored inside of S5PC110, which is set to non-zero in EVT1-SEC revision of CPU, so probably iROM code is the same in both, secure and nonsecure revisions). Altought it has been confirmed for 100% that they are physically pull-upped (2 of these) and pull-downed (3 of these) on S8500 (most likely for I9000 and S8530 also, because mainboard part under AP is basically the same project, slighty modified) with no way to change without soldering/cutting anything on mainboard. It is configuration 01001 if my memory isn't failing, which is forcing iROM to boot from oneNAND in 4k page mode (or something like that, I'm too lazy to look into my notes now, sorry. Again, it all has been described in "Let's save some bricks" thread)
Hope i cleared it for you a bit.
Is the iROM in Samsung Wave devices secure?
What do you mean by 'secure'? You can see the dumps yourself if looking for vulnerabilities.
When I say "secure" I'm talking about the boot ROM and whether or not it performs integrity checks (a.k.a. signature checks) on the first stage bootloader. You can't determine that by looking at the firmware. I know you don't consider that to be too important, but I do.
Sent from my DROID2 GLOBAL using XDA App
It has got code checking BL signature, but it is executed only when it find S5PC110 SECKEY bits nonzero. These seems to be always zero in EVT1 hw revision (EVT1-SEC revision does exists but probably doesn't appear in any Wave nor SGS).
Also it has got code for checking BL checksum stored at the beggining of bootsector (in case of flash memory corruption) but it is in somehow big cascade of ifs, and doesn't appear to be executed always (but may be in fact, haven't dived enough deep to check what are exactly conditions that affect it)
Boot sequence in waves (these have got OM pins hardware pulled down and up, not like Odroid, which has got jumpers to manipulate it) I assume is something like that:
- try to boot from oneNAND (with checksum)
- try to boot from MMC0 interface
- try to boot from UART2 interface
- try to boot from oneNAND (without checksum)
- infinite loop
Consider it as possible assumption only, much more info there: http://forum.xda-developers.com/showthread.php?t=1018862
Master Melab said:
When I say "secure" I'm talking about the boot ROM and whether or not it performs integrity checks (a.k.a. signature checks) on the first stage bootloader. You can't determine that by looking at the firmware.
Click to expand...
Click to collapse
How do you think we determine that? Exactly by looking at the iROM assembly. Why cannot you do that?
The iROM does use processor internal security subsystem, but I had little time to analyze how. Basically, it does have an option of to verify BL1. The BL1 and BL2 do hashing and signature verification before shadowing next bootloader stage if it's enabled in SFR responsible for security.
Rebellos said:
It has got code checking BL signature, but it is executed only when it find S5PC110 SECKEY bits nonzero. These seems to be always zero in EVT1 hw revision (EVT1-SEC revision does exists but probably doesn't appear in any Wave nor SGS).
Also it has got code for checking BL checksum stored at the beggining of bootsector (in case of flash memory corruption) but it is in somehow big cascade of ifs, and doesn't appear to be executed always (but may be in fact, haven't dived enough deep to check what are exactly conditions that affect it)
Boot sequence in waves (these have got OM pins hardware pulled down and up, not like Odroid, which has got jumpers to manipulate it) I assume is something like that:
- try to boot from oneNAND (with checksum)
- try to boot from MMC0 interface
- try to boot from UART2 interface
- try to boot from oneNAND (without checksum)
- infinite loop
Consider it as possible assumption only, much more info there: http://forum.xda-developers.com/showthread.php?t=101886
Click to expand...
Click to collapse
So, if I understand this correctly, the boot ROM/processor inside the Samsung Wave has the capability to perform signature checks, but it is not enabled.
We are not sure about what's on the market. We may speak about individual cases. Still, to load BL, it needs to go through JTAG or BL3 that verifies what is loaded. The vulnerable FOTA capability (still, requires valid firmware with FOTA enabled, all described in the 'FOTA thread') gives some perspectives, but everything low level requires some know-how, effort and patience. Especially the effort part seems unattractive to most of xda users.
So BL1 is very hidden from interaction with external tools and utilities?
What kind of utilities? You may find elf with symbols (yay!) for disassembly in the thread adfree started some time ago. Some stuff there would require SRAM and iRAM dumps (calling functions in iRAM) for the analysis, but dumps are empty on our units (I don't assume unreadable as generally we make dumps with the very same privileges as the calling code).
Never mind. What is AMSS? Is that the radio firmware?
Rebellos said:
It has got code checking BL signature, but it is executed only when it find S5PC110 SECKEY bits nonzero. These seems to be always zero in EVT1 hw revision (EVT1-SEC revision does exists but probably doesn't appear in any Wave nor SGS).
Also it has got code for checking BL checksum stored at the beggining of bootsector (in case of flash memory corruption) but it is in somehow big cascade of ifs, and doesn't appear to be executed always (but may be in fact, haven't dived enough deep to check what are exactly conditions that affect it)
Boot sequence in waves (these have got OM pins hardware pulled down and up, not like Odroid, which has got jumpers to manipulate it) I assume is something like that:
- try to boot from oneNAND (with checksum)
- try to boot from MMC0 interface
- try to boot from UART2 interface
- try to boot from oneNAND (without checksum)
- infinite loop
Consider it as possible assumption only, much more info there: http://forum.xda-developers.com/showthread.php?t=101886
Click to expand...
Click to collapse
I'm sorry Rebellos, but your link does not work. And correct me if I'm wrong, but is the public key in the Hummingbird processor (the S5PC110) the same across all devices that use it? Also, where can I find the documents on the S5PC110 that discuss things like SECKEY, if you have them?
Sent from my DROID2 GLOBAL using XDA App
Master Melab said:
I'm sorry Rebellos, but your link does not work. And correct me if I'm wrong, but is the public key in the Hummingbird processor (the S5PC110) the same across all devices that use it? Also, where can I find the documents on the S5PC110 that discuss things like SECKEY, if you have them?
Sent from my DROID2 GLOBAL using XDA App
Click to expand...
Click to collapse
Oh, sorry. Fixed it:
http://forum.xda-developers.com/showthread.php?t=1018862
And in general you can find much more about this iROM in various threads there
http://forum.xda-developers.com/forumdisplay.php?f=656
midas5 and TheBeano seems to be better informed.
Oh well, its only few KB of code. Just grab it and find answers by yourself.
http://code.google.com/p/badadroid/downloads/detail?name=0x0.0xFFFF.bin&can=2&q=
Does it cpu even have any hardware public key? Don't know about any.
Only very little amount of technical info about secure boot can be found in User Manual for S5PC110_EVT1. It is possible that deeper documentation about it may even not exist and additional info can be obtained only through samsung business tech support directly from their devs (It hasn't been proven that Samsung does use EVT1-SEC version of CPU, so who would...?)
AMSS is radio OS which is being loaded to shared mem by AP and started by DBL (modem bootloader) which is being sent in few parts to CP from AP through UART0 interface and then by oneDRAM share.
IOS (Iphone) on WAVE possible ... ???
I've pondered something similar: swapping out Apple's A4 processor with a Hummingbird processor to bypass SHSH signature checks. Although both being manufactured by the same company may not mean anything, they share the exact same ARM core, according to the teardown by Chipworks. I'm interested in bypassing the hardware aspects of the restrictions that are put on electronics.
But, running iOS on the Wave would be hard. First off, iOS uses an entirely different kernel, XNU. XNU uses Kexts (kernel extensions) as drivers, so you would have find out how to write kernel extensions compatible with ARM. Apple is very locked down about their x86 platform, even more so with iOS, so I don't think you'll get a tutorial on how to write a kernel extension for iOS without a little bribery. Second, there's a lot of other things that you would have to change. If you want to stay sane in getting to run iOS on the Wave you'll need the source code.
Can we collect different ways to dump iROM please.
I'll try to use JTAG (RIFF Box)... and maybe Commands to read this area...
Any usefull hints are welcome... for S8500 without installed Android...
Thanx in advance.
Best Regards
adfree said:
Can we collect different ways to dump iROM please.
I'll try to use JTAG (RIFF Box)... and maybe Commands to read this area...
Any usefull hints are welcome... for S8500 without installed Android...
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
You have to know that iROM has been already dumped from S8500 and S8530 using prepared FOTA code. :d Posted it somewhere I think...
...from S8500 and S8530 using prepared FOTA code. :d Posted it somewhere I think...
Click to expand...
Click to collapse
Dump from S8530 I've found.
But S8500 nor FOTA...
Maybe someone can give me please the Link to FOTA file... then I can try it at home.
Thanx.
No problem if all handsets have equal iROM dump. I will only do it for study self at home.
Best Regards
Hi All
I am one of the victim of Bricked A100 owner (http://forum.xda-developers.com/showpost.php?p=25230026&postcount=57), as detailed in the forum, I tried with EUU and stumbled in to wrong cpuid as others.
In search of the way out, I stumbled upon some of the details from nvidia.. (http://nv-tegra.nvidia.com/gitweb/?...in;h=4c92e4f2ac11913c4ba19d3ffc1be0f5ae8c4ca6). according to this
- fuses can be read/written via sysfs entries.
- fuse sysfs entries will be present under /sys/firmware/fuse
I also saw some details and tables about 128 bit crypt key generation here.
http://nv-tegra.nvidia.com/gitweb/?...d;hb=ac09952babed8e2ac6999127b7f95d7a2bbfd7af
http://nv-tegra.nvidia.com/gitweb/?...b;hb=ac09952babed8e2ac6999127b7f95d7a2bbfd7af
http://nv-tegra.nvidia.com/gitweb/?...1;hb=ac09952babed8e2ac6999127b7f95d7a2bbfd7af
I don't know if this will be useful in get some information about finding the SBK for A100. May be the gurus can comment on this.
Thought of sharing this to the community, I am sorry... If I posted in wrong place..
Thanks
JayArr
Checking device manager for cpuid doesn't help (check relevant part "alternative methods" in http://forum.xda-developers.com/showthread.php?t=1121543)?
Information to reflection
Look here.
ZeroNull did you try to enter in apx mode with unlocked bootloader after your replacement of the motherboard?
I'm asking because the assumption of ptesmoke that unlocked bootloader modify the serial # in some way and that's why you can't enter in apx.Despite the number is the same in /sys/firmware/fuse/ and in dmesg like the original one.But is diferent in adb devices. It's refuses to enter in apx mode with sbk generated from them no matter who.
SBK is an AES key that is burnt into unreadable fuse area.
It's being used to decrypt APX commands and the bootloader.
Even if you would be able to read it somehow out of hardware (which the designers of Tegra2 chip made sure you cannot) it's of not much use, as this is only the decryption key, and the designers of AES made sure it's very hard to generate second (encryption) matching key having only one of the pair.
The only feasible way of getting the encryption key is Acer "leaking" the key itself or the method of generating it from CPUID, to the community.
zleto said:
ZeroNull did you try to enter in apx mode with unlocked bootloader after your replacement of the motherboard?
Click to expand...
Click to collapse
Yes. Everything works.
I as tried this and this bootloaders. There were no problems.
smokku said:
SBK is an AES key that is burnt into unreadable fuse area.
It's being used to decrypt APX commands and the bootloader.
Even if you would be able to read it somehow out of hardware (which the designers of Tegra2 chip made sure you cannot) it's of not much use, as this is only the decryption key, and the designers of AES made sure it's very hard to generate second (encryption) matching key having only one of the pair.
The only feasible way of getting the encryption key is Acer "leaking" the key itself or the method of generating it from CPUID, to the community.
Click to expand...
Click to collapse
No, it's symmetric. And when you encrypt on asymmetric encryption, the private key is the one that decrypts
Skrilax_CZ said:
No, it's symmetric. And when you encrypt on asymmetric encryption, the private key is the one that decrypts
Click to expand...
Click to collapse
Oh. Thanks.
I was under impression that AES is asymmetric.
It actually makes sense now how one can generate the SBK from CPUID.
Anyway, it's still impossible to read out the burnt key from Tegra2 chip.
ZeroNull said:
Yes. Everything works.
I as tried this and this bootloaders. There were no problems.
Click to expand...
Click to collapse
care to elaborate? what bootloader are you running on your A100?
ptesmoke said:
care to elaborate? what bootloader are you running on your A100?
Click to expand...
Click to collapse
bump
zeronull please pm me...
Sent from my SGH-I897 using xda premium