Related
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.
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
Hello all, I have been a lurker for quite a while here. I own an Xperia M (Rooted, Unlocked BL running CM11). I was feeling adventurous and started messing with the partition table hoping to resize the system and data partitions using parted. I was unaware that the bootloader detects such modifications and ended up with a brick.
Just to clarify, this is a hard brick, since the Flashtool and fastboot modes do not work. I do not see the blue LED while trying to start the device in the fastboot mode using the volume rockers. My PC only detects a "QHSUSB_DLOAD" device for which I've installed the drivers and it is now "Qualcomm HS-UDB QDLoader 9008".
However, before I started to work with the partition table, I took a raw backup of the emmc i.e. mmcblk0. This should include the correct partition table and all the partitions (TA, userdata, system etc.). Theoretically (I believe so), if this is reflashed onto the device, an unbrick could be possible. However, so far, I haven't been able to figure out a way to push this image back to the device. I came across QPST and some linux bash scripts but haven't been able to use them successfully.
Has anyone come across such a scenario before? I looked for solutions in other threads but didn't find anything conclusive for Xperia devices. Can someone help me with this? thanks.
randallstevens said:
I was feeling adventurous and started messing with the partition table
Click to expand...
Click to collapse
Hi,
On other forum one user followed suggested by me same theory of remapping paritions as described here to shrink so large /system and increase /userdata
He gotta same brick because deleted 3 partitions and then they was cannot created by any commands, so seems this method not applicable to our phone.
Next he very early quited from recovery without restoring partition table from backup.
Surprisingly, in un-offical service center phone was quickly fixed, seems with JTAG-device.
QHSUSB_DLOAD – this is fall-back low-level mode of CPU that allow access to all partitions just like fastboot
Needed to repair / writing stock ROM at factory.
Can be enabled manually by connecting to PC with holding both volume buttons. How to exit – don't know.
QPST utility not useful because we not have dump in it's proper format. So only Linux our hope.
That user tried to manage with Ubuntu but phone was not recognized. Very likely he went into something wrong.
That's very great that you created backup of whole NAND.
Maybe will be enough restore GPT (partition table), I have one and own per-partitions dump too.
So plan very easy: connecting phone to PC with Ubuntu and restore dump via dd utility.
Partially follow this instruction with modifications because you have full dump.
Connect phone, find where it "attached" (whole nand, not partitions), restore file there.
Be careful with disk naming, you can damage data on HDD.
Bonoboo said:
So plan very easy: connecting phone to PC with Ubuntu and restore dump via dd utility.
Partially follow this instruction with modifications because you have full dump.
Connect phone, find where it "attached" (whole nand, not partitions), restore file there.
Be careful with disk naming, you can damage data on HDD.
Click to expand...
Click to collapse
Hi Bonoboo, thank you for replying.
Unfortunately, Ubuntu isn't able to detect the emmc and therefore, I'm unable to find the "/dev/sdX" node for the device. The phone is being detected only as "Qualcomm, Inc. Gobi Wireless Modem (QDL mode)".
I've seen some threads wherein QPST is first used to enable the partitions detection of emmc. However, as you mentioned, we do not have the necessary MSM8227 HEX file for this.
A windows app called "s1tool.exe" can be used to flash the bootloader files from the FTF, Link to thread. However, a testpoint combination is needed to access the emergency mode. I was unable to find a testpoint for Xperia M.
Is JTAG the only way forward here? Thanks again for the help.
EDIT: Looks like the s1tool I mentioned is device specific, may not work with XM.
randallstevens said:
I'm unable to find the "/dev/sdX" node for the device.
The phone is being detected only as "Qualcomm, Inc. Gobi Wireless Modem (QDL mode)".
Click to expand...
Click to collapse
Yeah, this is not good, same as was with that guy. 1, 2
But here under spoiler I found Perl-script that may open access to eMMC.
Here more info.
Maybe it device-specific too, but anyway try.
UPD: post
just connect your phone to PC (at this time your /var/log/kern.log should update and ttyUSB0 should be added), in terminal, cd to your download folder and run './qd.pl --check', or run 'perl ./qd.pl --check'.
Click to expand...
Click to collapse
Bonoboo said:
Yeah, this is not good, same as was with that guy. 1, 2
But here under spoiler I found Perl-script that may open access to eMMC.
Here more info.
Maybe it device-specific too, but anyway try.
UPD: post
Click to expand...
Click to collapse
Hello Bonoboo,
I've tried using the qd.pl script but I'm not sure which file needs to be sent to the device when using the "qd.pl --pfile X" and the other parameters. The script detects the Qualcomm modem. I've tried uploading the first 256 kilobytes of the dump which should include the partition table but this results in an "Invalid Response" error from the script. Tried uploading the TA and some other partitions, but received the same error. No eMMC access yet. What file do you think the script requires?
randallstevens said:
What file do you think the script requires?
Click to expand...
Click to collapse
Was mentioned some *.hex, that maybe relates with same from QPST.
In threads more info.
Very likely script just not compatible with M.
UPD: it's sounds weird, but try to connect phone in fastboot / flashmode with long holding volume key.
In some cases this really helpful due second "bootloader" (alt_s1sbl2 partition and other).
Bonoboo said:
UPD: it's sounds weird, but try to connect phone in fastboot / flashmode with long holding volume key.
In some cases this really helpful due second "bootloader" (alt_s1sbl2 partition and other).
Click to expand...
Click to collapse
Hi, I tried long-pressing the volume key, it does not seem to work. Thanks for the confirmation about the hex file. It looks like I'll need the right files for the handset, as using hex files of similar chipsets did not help. I'll keep working on it and write back with an update if I'm able to fix it.
I've got the same problem., but unfortunately I didn't make a dump of mmcblk0. There is a way I can get yours? Or a part of it with the interesting data with which I can try figuring out how the qdload.pl script works (maybe leave out userdata cause of its size and the private data).
fakier said:
I've got the same problem., but unfortunately I didn't make a dump of mmcblk0. There is a way I can get yours? Or a part of it with the interesting data with which I can try figuring out how the qdload.pl script works (maybe leave out userdata cause of its size and the private data).
Click to expand...
Click to collapse
Hi fakier, sorry to know you have the same problem. I've sent you a PM with a link to a compressed copy of the first 140 MBs of the raw eMMC dump I made earlier. This should contain all the important partitions besides system and userdata. Note that this also includes my TA partition which probably shouldn't be written to your device.
randallstevens said:
Hi fakier, sorry to know you have the same problem. I've sent you a PM with a link to a compressed copy of the first 140 MBs of the raw eMMC dump I made earlier. This should contain all the important partitions besides system and userdata. Note that this also includes my TA partition which probably shouldn't be written to your device.
Click to expand...
Click to collapse
Thanks, a backup of my TA partition I do have...
Update
Hello folks, after spending a lot of time trying to fix my device with qdloader and QPST, I gave up. Before getting it JTAGed, I wanted to try my luck (again) and approached Sony to claim warranty, since there was a month remaining before its expiry.
My warranty claim was accepted and they replaced the mainboard, though the bootloader was unlocked!! My Xperia is alive and kicking again! Will unlock it soon.
Trying to fix the phone was not a pleasant experience, but I think I learned much along the way. Hope nobody else screws-up the way I did.
Thanks XDA, see ya around! :good:
randallstevens said:
Hello folks, after spending a lot of time trying to fix my device with qdloader and QPST, I gave up. Before getting it JTAGed, I wanted to try my luck (again) and approached Sony to claim warranty, since there was a month remaining before its expiry.
My warranty claim was accepted and they replaced the mainboard, though the bootloader was unlocked!! My Xperia is alive and kicking again! Will unlock it soon.
Trying to fix the phone was not a pleasant experience, but I think I learned much along the way. Hope nobody else screws-up the way I did.
Thanks XDA, see ya around! :good:
Click to expand...
Click to collapse
Dude what was the point of this thread and when you tried to fix your phone did you re flash stock ROM?
Reply to Piravinthb's comment
Piravinthb said:
Dude what was the point of this thread..
Click to expand...
Click to collapse
The point of this thread, dude, was to see if the device could somehow be taken out of the "Qualcomm HS-USB QDLoader 9008" mode, a (very) low-level interface meant for vendors to flash bootloaders and system images on their devices.
..and when you tried to fix your phone did you re flash stock ROM?
Click to expand...
Click to collapse
Had you googled this, you'd know that this mode isn't the same as the Flashtool flash mode or fastboot. No rom, stock or CM, can be flashed before fixing the bootloader itself, which is needed to start the device.
Not much progress could be made here since the bootloader hex files for Qualcomm's OEM tools (QPST) would be needed to fix such a hard brick. Also, the QDloader scripts mentioned earlier were written for a different chipset from the one used in Xperia M.
Cheers, RS.
randallstevens said:
Hello all, I have been a lurker for quite a while here. I own an Xperia M (Rooted, Unlocked BL running CM11). I was feeling adventurous and started messing with the partition table hoping to resize the system and data partitions using parted. I was unaware that the bootloader detects such modifications and ended up with a brick.
Just to clarify, this is a hard brick, since the Flashtool and fastboot modes do not work. I do not see the blue LED while trying to start the device in the fastboot mode using the volume rockers. My PC only detects a "QHSUSB_DLOAD" device for which I've installed the drivers and it is now "Qualcomm HS-UDB QDLoader 9008".
However, before I started to work with the partition table, I took a raw backup of the emmc i.e. mmcblk0. This should include the correct partition table and all the partitions (TA, userdata, system etc.). Theoretically (I believe so), if this is reflashed onto the device, an unbrick could be possible. However, so far, I haven't been able to figure out a way to push this image back to the device. I came across QPST and some linux bash scripts but haven't been able to use them successfully.
Has anyone come across such a scenario before? I looked for solutions in other threads but didn't find anything conclusive for Xperia devices. Can someone help me with this? thanks.
Click to expand...
Click to collapse
hi i have same problem with same adventure , but i was using stock rom with customized kernel with cwm.
i think the solutions are 2
repair hard brick with JTAG or test point and s1tool what is not implemented for xperia m
see http://forum.xda-developers.com/showthread.php?t=2646405 for Z1
my handset will be in trash no free or paid solution or sony service . i'll buy another one
thx
rafik23 said:
my handset will be in trash no free or paid solution or sony service . i'll buy another one
thx
Click to expand...
Click to collapse
Buy a nexus 4 off amazon for 140€
It only takes 2 taps to thank somebody here.
Hello everyone! It's been six years since my last post and it is truly fantastic that this community is still going strong
A while back I installed LineageOS on a Motorola device. I am very impressed and very grateful to all the developers and the free software community for this amazing piece of software. I like to secure my devices as much as possible and I am wondering about the implications that an unlocked bootloader might present.
Some time ago I came across a post somewhere on the internet (unfortunately cannot find that link anymore) where someone claimed that if the bootloader of an Android device is unlocked, one could boot a TWRP recovery image, delete the encryption keyfiles and as a result the encryption keys would be reset to the default values and this would allow to bypass any screenlocks.
Unfortunately I don't have spare device to conduct tests, therefore I am hoping that someone could shed some light on this. Is it really possible to bypass FBE so easily with an unlocked bootloader?
From this answer on a different forum:
The main issue with LineageOS is that you will have an unlocked bootloader. That allows an attacker to load a custom recovery and brute force your encryption completely bypassing LineageOS all together.
Click to expand...
Click to collapse
An alternative would be conducting an Evil maid attack since Lineage is by default built in userdebug and allows flashing any (unsigned) packages from the ADB. Nothing is stopping anyone from flashing a keylogger or some kind of a remote access on your device using this method.
The questions remain how likely are such attacks and how likely will a potential thief invest his time and resources in getting access to your data. These are questions everyone has to answer depending on his own individual situation and risk factors.
Feel free to correct me
Thanks for the reply. You made some good points, I also think that if a device has been in the wrong hands even for a short period of time, it is compromised, even if the bootloader is locked down and USB debugging is disabled. Unlocked bootloader is a great gateway for bruteforce or dictionary attacks but a strong password can mitigate the risk and prevent even state actors from accessing the information, at least for couple of years
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Reacan said:
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Click to expand...
Click to collapse
No. Unless LineageOS's (or Android's) crypto is horribly broken, this shouldn't be possible. So far, the only way to bypass the drisk encryption is to brute force the passphrase. You are probably referring to erasing user data by removing encryption headers -- TWRP can do this, but then all your data is lost.
However, encryption only protects user data, not system. Hence, the latter can be backdoored without you knowing.
Reacan said:
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Click to expand...
Click to collapse
Afaik FBE works by generating a random key and encrypting the target parition(s) on the first boot. Then it uses your passphrase to encrypt that key.
From my understanding, deleting the key (stored in an encrypted form) would make the data encrypted with that key essentially unrecoverable. Unless someone had the resources to bruteforce the key. As of today that would require state level amount of resources.
Another theoretical possibility would be performing a Cold boot attack to get the encryption keys from RAM.
Feel free to correct me
Also remember if you are using a phone with a Qualcomm chipset, and you are really up against a state level actor, you also have to deal with EDL mode: you can dump the entire phone with it (no need to compromise or exploit the image on the phone itself), take it back to your seekret lair, and spend your gazillions on brute force hardware.
Bottom line, even if every senior hacker on this board told you "no, not that easy", they still could be wrong somehow. Zero days wouldn't be a thing if it worked that way. If you've got something truly worth protecting, put it in a [software] vault with solid, audited encryption.
If it isn't /that/ important, some phones will let you do the entire trusted boot thing if you want to compile LOS (or any AOSP based distro) from source, and futz around with the build scripts.
That said, remember there are social engineering attacks. If I were a l33t CIA agent, I'd probably wait till you were somewhere where I could watch you carefully (or had a 8 billion megapixel camera watching you carefully), send you a text message (marketing spam would work nicely), and then watch you type your password on the screen to read it... boom, pwn3d.
Many vectors of attack here.
If someone *GOT* your phone (to launch TWRP et al), you'd know about it, right? Consider a remote wipe package? Or try to keep them from getting it in the first place with physical security (vault, firearms, martial arts, etc)?