Related
Hacking the Ipaq RW6100 CDMA PPC ROM?
I have an Ipaq RW6100 which is only avaiable in Korea.
http://www.ipaq.co.kr/product/rw6100/index.asp
It is awesome. pxa270 520 CPU, wifi, 260K LCD, Sharp 1.1 megapixel CCD Camera, 128 ROm, 64 RAM. Now running on wm2003se.
Surprisingly, the current ROM version of my Rw6100 does NOT support landscape function. u know, no landscape function certainly compromise the wifi internet browsing.
so i want 2 upgrade the rom. upgrade (the official way) is done on pc with ipaq is usb synced with desktop PC.
unfortunately, upgrade program needs to confirm the ipaq is correctly plugged with ac adapter. So it needs the orginal cradle, coz Rw6100 has no separate ac port. charging or usb sync is both done through the same port with different cable. Only the cradle can handle ac charging and usb sync at the same time.
I have only the usb sync cable and the ac adapter, but not the cradle. these two simply can not plug into the same port concurrently. usb sync and usb charging together can not fool the upgrade program.
Can anyone help? btw, i can not enter usb remote update mode with usual key pressing on HP PPCs. neither do i succeed running the enterbootloader.exe file and manually put the rw6100 into bootloader mode.
I have looked into the official rom. It is a 128M NBF file (coz this Ipaq has 128M ROM). If it is a usual NBF file, it is then 32 byte rom info+ROM. in theory, deleting the first 32 bytes will leave a .nb0 wince image. I have done this and leave the new nb0 file onto sd card. (I have found the sd card update method by myself)
the screen says the sd card has no rom image. Failed again. Is it because I have put no bootloader file on sd card too? Because I have no idea of where to get the bootloader file. No luck.
Email to HP Korea proves not much help.
Another reason. This PPC could not have a wince image as large as 128M. Now I have about 78m usable flash space on my current PPC. Is it because i have not successfully ripped off the right-sized wince rom?
Could anyone help rim the correct wince ROM from this 128M ROM update file? I need badly the native screen rotation function in wm2003se.
ROM update address:
http://h50177.www5.hp.com/support/FA294PA/more_info_local_19768.html
it is a 43m exe file download. running on host PC will get a 128M nbf file.
the upgrade proggie is the usual ruu.exe
btw, i have found the following bootloader info by hex editing the 128m nbf file.
enter your selection: R) View SD card
D) Download Image to SD card
L) Launch existing flash resident image now
P) Power Test
C) CPLD GPIO Set Test
W) WLAN Test
K) Flash Lock Status
F) Flash Write Test
E) Flash Erase Test
A) AC97 Test
V) View Memory
I) Download FLASH or SDRAM image through USB
8) LCD Test
USB Boot Loader Configuration:
If i can find out the way of entering it, there will be much hope of successful rom upgrading
I have a Roadfinder 143 or more well known Binatone carrera x430 Pna specs i know so far:
Display Touch Screen 4.3" TFT LCD Resolution 480 x 272 pixels
SD/MMC Card Memory Up To 2GB
GPS chipset Sirf Atlas III
Processor Centrality Atlas III 372MHz High Speed ARM926J
Operating system Microsoft Wince 5.0 Core Version (Macallan)
Speaker 1w I Have Changed it with a internal very powerful speaker!
USB USB 1.1 and 2.0
TMC output
Headphone output
Memory on Board ROM/RAM up to 2GB / 64MB
Battery/Type Built-in 1450 mAH li-polymer
Weight 200g
Dimension (mm) 127 x 85 x 19
What i want to do:
Export the rom so i can unpack it and make a few changes.
I would like to find a way to flash it with clean WindowsCE core5.0 (Or other if possible)
I cant figure out how to go into bootloader mode...
I want to take advantage of this big screen and transform it in to a pda. It doesent have camera,phone,gprs,3g,wifi,bluetooth,irda,
so no need to find drivers for them it souldent be to hard to make/edit a rom for it.
It has very large internal memory in a resident flash drive as it calls it 512mb that's without the rom memory size on the current setup that it has everything locked up!
I've managed to get an explorer running and put extra stuff in but the registry gets cleared on every reboot its so very limited....
Can't i just Run an app to make a backup.img/.nb0 of the existing rom take the drivers that i need from it an get a clean wm5 image and put the drivers in flash it by active sync or most probably sd and have it free???
Please give me a bit of help i would gladly donate for someones effort to help me! Im not a complete noob and many others would like this and use it because its a cheap good pna in Grecce,America,China,France,Europe generaly,Australia. There is also a smaller version of this pna with 3.5" screen and 256mb internal flash memory
Feel free to comment and direct me advise me. (Alex)
These are the link to pages that sell this device:
http://binatonegps.com/gps/_global/product_detail.php?item_id=4
http://www.kotsovolos.gr/site/product.jsp?catid=53081
http://www.myphone.gr/forum/showthread.php?t=219937
Firestarter42 said:
I have a Roadfinder 143 or more well known Binatone carrera x430 Pna specs i know so far:
Display Touch Screen 4.3" TFT LCD Resolution 480 x 272 pixels
SD/MMC Card Memory Up To 2GB
GPS chipset Sirf Atlas III
Processor Centrality Atlas III 372MHz High Speed ARM926J
Operating system Microsoft Wince 5.0 Core Version (Macallan)
Speaker 1w I Have Changed it with a internal very powerful speaker!
USB USB 1.1 and 2.0
TMC output
Headphone output
Memory on Board ROM/RAM up to 2GB / 64MB
Battery/Type Built-in 1450 mAH li-polymer
Weight 200g
Dimension (mm) 127 x 85 x 19
What i want to do:
Export the rom so i can unpack it and make a few changes.
I would like to find a way to flash it with clean WindowsCE core5.0 (Or other if possible)
I cant figure out how to go into bootloader mode...
I want to take advantage of this big screen and transform it in to a pda. It doesent have camera,phone,gprs,3g,wifi,bluetooth,irda,
so no need to find drivers for them it souldent be to hard to make/edit a rom for it.
It has very large internal memory in a resident flash drive as it calls it 512mb that's without the rom memory size on the current setup that it has everything locked up!
I've managed to get an explorer running and put extra stuff in but the registry gets cleared on every reboot its so very limited....
Can't i just Run an app to make a backup.img/.nb0 of the existing rom take the drivers that i need from it an get a clean wm5 image and put the drivers in flash it by active sync or most probably sd and have it free???
Please give me a bit of help i would gladly donate for someones effort to help me! Im not a complete noob and many others would like this and use it because its a cheap good pna in Grecce,America,China,France,Europe generaly,Australia. There is also a smaller version of this pna with 3.5" screen and 256mb internal flash memory
Feel free to comment and direct me advise me. (Alex)
These are the link to pages that sell this device:
http://binatonegps.com/gps/_global/product_detail.php?item_id=4
http://www.kotsovolos.gr/site/product.jsp?catid=53081
http://www.myphone.gr/forum/showthread.php?t=219937
Click to expand...
Click to collapse
You may need platform builder to generate a ROM for that device. But going to bootloader mode is still unknown for me.
Bootloader mode drivers
I think i have found how to go into bootloader mode, i keep the side power button pressed for a bit while switching the device on and then connect it to the pc and it comes up as a unknown usb device and prompts me for drivers and stays there!!! the thing is i can't get any thing to show up on the screen... Maby thats the bootloader type that it has by factory and doesn't show anything up on purpose...
Where do you think i can find drivers for it? i have realy looked everywhere that i know... Help me please guys...
try the voxtel carrera 430 file (prosh_430)
holding down the sleep button and press reset
after some 20 sec you will see the download image menu
release the sleep button
after 10 minutes you will have a brand new voxtel aka binatone.
but the menu is in russian so you have to find the buttons to change the lang in english and to calibrate the screan
First allow me to apologize for my clumsy English and this long boring post
I m a total noob when it comes to android, recently I bought a DHD and I would love to root it
However the first thing I would like to be 100% aware of is the worst case scenario
I m a PC technician so it would be very kind of you if you answered my Q by comparing the DHD to a computer
If you own a new laptop then u can mess with OS as much as u want, then u can recover the laptop to its factory defaults by using the recovery function
-in some laptops the OS has to be healthy and you'll have to able to log into your account in order to restore the system
-in some laptops you can restore the OS from outside the OS using a hot key cause the recover partition is a standalone partition and hot key is managed by a software which works in a layer above the OS
-in some laptops its even better! u can create recovery disk so you mess with the OS and HDD itself then you can restore the HDD to its factory defaults
-the only thing that might force u to go for a hardware solution is when u mess with CHIPS like the BIOS
if something went wrong while you are upgrading that chip u wont be able to fix it at home with any software but you'll have to take the chip out are reprogram it using a EPROM programmer
After this boring long introduction here comes my Q: how bad can I damage my DHD? I've read the word "brick" here and there, is that the worst case scenario?
I know less than nothing about the internal architecture of mobile phones but I always imagined old mobile phones it as a Read-Only chip that loads the OS into a RAM where u can mess as much as u want and once u reboot you are back to life
I m not sure if I m making any sense so I'll try to compare my Q to the iPhone
you can mess with the iPhone as much as you want (as long as u don't use a tool that upgrades the boot loader) and you can always restore the OS from a (higher) level using a third party application
Same thing with BBs right? u can always (inject) the OS back into the device using an executable OS file
What about android devices?
I apologize again for boring you
Thanks
Rooting wont necessarily brick your phone or damage it as all as when you root your phone you are basically gaining 'admin' rights on your phone.
The danger of 'bricking' or damaging your phone comes in when you start to remove the security off your phone so that you can flash a custom recovery, new radio or kernal.
This a very basic and minimalistic answer to your question but that is basically the just of it.
If you follow all the instructions to the point nothing should go wrong and if it does there is allways someone that can help
Running a PD98IMG.zip or RUU will revert your phone back to stock
Oh and once you have performed radio and/or eng s-off there are also very specific instructions to revert this back to stock over on the development section aswel.
Good luck!
RaymondErasmus thank you very much for your most-welcomed answer but can u be more specific?
tbh there are loads of tutorials all over the Internet but I m looking for simple in-depth details, in other words I m trying to understand which parts of the phone I m messing with
Regards
Okay, I'll try to explain it.. These phones have @secuflag, which is written deep in the internal memory. It tells your phone it's security state, S-ON or S-OFF. When security is off, your device's internal memory becomes read/write instead of read only. It allows you to flash ROMs (OS package) and do other exciting modifications to the software.
When security is off, you can do literally anything, even delete your phone's bootloader, so that it becomes just a pile of hardware with nothing to boot. That is called a brick. When you have the bootloader intact (always), you can recover your phone from any state. Usually people have ClockworkMod installed, which is a custom recovery application. It allows you to even format the internal memory of your phone, and then flash anything you want. Without ClockworkMod you can still go to bootloader no matter what, and send a whole OS into the phone using RUU USB connection.
Rooting itself does not turn security off, but S-OFF obviously does. Without S-OFF, you cannot hurt your device in any serious way.
jkoljo your answer is just awesome! Kiitos man!
This is exactly the type of answers I was seeking for, I was right about joining this great forum
Can you share more details? any diagrams to explain the relationship between the components/registers of the internal memory? and more details regarding the process of booting up in Android phones?
Thanks again man
Sure mate, about the boot procedure first:
The ARM SOC gets powered up
PBL (primary boot loader) starts running. It sets up partitions, for example, and initializes hardware. It executes DBL.
DBL, device boot loader checks bootloader (hboot) in case of corruption and such things, then executes OSBL
OSBL, operating system bootloader, hboot, sets up rest of the hardware system. It checks secuflag and sets internal memory accordingly, for example. It has the ability to read and write firmware. Then it basically executes linux kernel.
Kernel starts running, initializes your system (drivers etc) and starts booting up Android.
For end user, hboot and recovery act as the base of the device. Hboot provides access to various partitions like radio firmware, and clockworkmod recovery provides extensive control of /system, /data and such system related partitions. Hboot has the ability to boot up clockworkmod, regardless of the state of the system (corrupted and broken / fully healthy).
You might be interested in this.
For very extensive information about low level stuff, check this out.
For the record, seraph1024 posted a wonderful thread that helped me to understand some stuff
[Newbie Guide] adb/fastboot/bootloader/android 101
In Cyanogen Mod 7 version 12 is the apps2sd automatically enabled or do i need to create a partition on the sd card?
and if i need a partition then what type of partition do i need ext 3 or ext4??
rooting wont harm your phone if you followed the rooting process religiously
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