Related
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
The eMMC module "crashed" in my Nexus 7, and it got into write-locked mode as much as I can tell.
Actually I get -110 on init, I can't reach the block devices in adb, as it says it's busy.
What I can do:
Get into bootloader mode
Get into recovery mode (The screen stays at TWRP logo, but I can adb shell in it, but I can't read or write the mmc blocks)
Now this is not much help in write locked mode of course, but then I ran into this thread.
I could try the same with my Nexus 7, but I need some help:
Reset command (if there is any) for H26M64003DQR (I guess that's what is inside the 32GB version)
A dump from the boot and some other neccesary partitions.
As an alternative if someone knows the pinouts of eMMC chip I can use to solder to an sd card reader, it would help a lot.
As a second alternative, if anyone knows a way to boot right from usb, it would help too.
If anyone could help me with this, I would be really grateful.
Having the same issue and need help
I'm also having the exact same issue. No access to the eMMC at all -- all attempts to mount or read from it results in I/O error (-110 error when checking via dmesg).
It all happened randomly and I thought it was just a random restart. But after it was stuck for 30 minutes on the Google logo, I found out something was not right.
Does someone have any ideas? I would be **very** interested and grateful if I can get this fixed. The warranty just expired two months ago... :crying:
leoetlino said:
I'm also having the exact same issue. No access to the eMMC at all -- all attempts to mount or read from it results in I/O error (-110 error when checking via dmesg).
It all happened randomly and I thought it was just a random restart. But after it was stuck for 30 minutes on the Google logo, I found out something was not right.
Does someone have any ideas? I would be **very** interested and grateful if I can get this fixed. The warranty just expired two months ago... :crying:
Click to expand...
Click to collapse
I've tried everything, and as far as I can tell, you have 2 options:
Solder a microsd card to the proper pins on the motherboard. (When I looked, nobody knew those pins, maybe there is some development since then)
Buy a new motherboard. - That's what I did, it was about 75$ from eBay. It's working beautifully since.
Xmister said:
I've tried everything, and as far as I can tell, you have 2 options:
Solder a microsd card to the proper pins on the motherboard. (When I looked, nobody knew those pins, maybe there is some development since then)
Buy a new motherboard. - That's what I did, it was about 75$ from eBay. It's working beautifully since.
Click to expand...
Click to collapse
I think I'll buy a new motherboard: is this one [1] okay?
Also, would you mind writing up a quick guide as to how to change the motherboard? I've found a video on YouTube for disassembling but unsure on how to change the motherboard safely. Thanks!
L i n k s (sorry, but there's a restriction; you know what to do with the l i n k s):
[1] www-ebay-fr_itm/ASUS-Google-Nexus-7-tablet-Gen-2-2013-16gb-motherboard-logic-board-100-working-/271623781886
[2] www-youtube-com_watch?v=uv3u78YNUHk
Yes, it's okay.
I've done the disassembling from a youtube video too. Just be careful, the case can be easily cracked on the corners. Memorize(or take photo from) every cable's place. There is a few hidden screws holding parts of the MB you should be aware of, but you'll find them if you search.
It's not that hard, just be patient and gentle.
Good luck!
Thank you! I'll try this and hope I can revive my Nexus 7.
Did you also try booting from a USB flash driver through an OTG cable before replacing the motherboard? I'm just curious what you did end up trying when you say you tried everything.
I'm not the OP, but as I've had the same issue, I can definitely say it wouldn't have helped, since it was a hardware failure.
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
devmihkel said:
For good or for bad NOT everything appears correct, except the running 17.x version... As of now neither the "commercial jailbreak" supports new versions (well yes they were using exactly the same file to start with Also 16.51.x or newer appears to be no go: uconnect-8-4-8-4an-update
EDIT: haven't got 17.09.07 to try, but on 17.11.07 manifest.lua has changed and the last block/ search keyword is "ota_update" instead. Otherwise all the same, image valid after the edit and script.sh gets fired - at least on 16.33.29 that is @HanJ67 Did you actually try to mount installer.iso after the edit and checked /etc/manifest.lua for the end result before?
Click to expand...
Click to collapse
devmihkel said:
Yeah, 2nd attempt is much better as last lua block is correctly terminated and your script might actually run, but unfortunately no successful 17.x runs have been reported so far SWF scripts are not involved in update/jail-breaking run, these ones become relevant only once you are in (and need to enable some app or wifi or navi features etc). Afaik 17.x blocks ethernet dongle usage as well, but let's see if even the USB driver/link gets activated at all?
Click to expand...
Click to collapse
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Do You have an idea how to connect by USB2LAN adapter to uConnect ?
Do You know if there is an UART pins on the mainboard ?
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
Hello, any news about it?
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
sofro1988 said:
Hello, any news about it?
Click to expand...
Click to collapse
I have not had had much time to work on this.
I actually had an idea last week that brought me back to this. I plan to use a custom flash drive to present an unmodified ISO for verification, then swap nand to an identical image that has been he's edited to enable usb Ethernet and add a custom key for ssh access.
I thought to stack a NAND on top of the original on a is flash drive, then breakout the Chip Enable pin to a switch. I've seen this done for with guys modifying game consoles to be able to run modified firmware.
Once the 2nd NAND is in place I will restore an image of the original nand containing the unmodified update, then hex edit the required portions to allow access after updating.
If this method works, I should be able to pass the verification with the original nand chip, then switch it (hopefully there's a big enough window to do this by hand) then present the modified nand before it begins the flash procedure.
Hopefully someone more intimately familiar with the update scripts can verify I'm not missing anything in the process
Tajadela said:
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
Click to expand...
Click to collapse
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
thanks for answer.
I saw an ssh key with the hex editor, but I would like to see exactly what you have replaced.
if it's not too much trouble, it would be interesting to see with some screenshots the changes you've made.
So we could work on two fronts. The idea of the double nand is good, but not very simple to make ...
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
SquithyX said:
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
Click to expand...
Click to collapse
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
martinbogo1 said:
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
Click to expand...
Click to collapse
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
sofro1988 said:
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
I managed to connect with the cisco adapter (usb / ethernet), but I don't know the root password. is the problem at the moment insurmountable ..
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
martinbogo1 said:
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
Click to expand...
Click to collapse
I connected in telnet on a uconnect 6.5 with firmware 15.xx.xx. You can connect to Uconnect with static IP it brings up if no DHCP is offered is: 192.168.6.1
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
after rsa key replaced, do you have recalculate the checksum of UPD file?
have you replaced the first 64 bytes of the file?
thanks
@itsJRod, isn't it that you would like to explain the procedure to replace the RSA key in the swdl file? thank you
Hello,
have you made any progress? I am a bit lost. I put the EU uconnect MY15 to US dodge charger MY16 and Perf Pages were working fine even on 16.16.13, although after upgrade to 17.x (17.46.0.1 right now) I am meeting the problem of expired subscription (which is not possible to have on EU radio).
I am considering basically three solutions:
a) going back to US radio, but modify the language pack/nav/FM frequencies (it is doable, but I do not know how, although I can pay for it relatively less than time invested)
b) downgrade to 16.16.13 - I have no clue how to do it, I tried to put swdl.upd with swdl.iso as and installer.iso with no luck of course.
c) take xlets from KIM2/ of 16.16.13 to KIM23 of 17.46.0.1 secondary.iso - this is probably preferred way but I do not know how to make it to pass ISO validation.
Of course root on uconnect is extremely nice to have but I will be fully satisfied with Perf Pages working again.
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
djmjr77 said:
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
Click to expand...
Click to collapse
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
I created an account just to reply to this and All I have to say is you're literally an absolute life saver. I've been working on this every day for two weeks now, trying every trick people said, trying every USB, every format, every version and nothing ever worked from me. Uconnect support was absolutely no help and it was a lot of back-and-forth finger pointing and no you need to reach out to this person between them and the dealership. Dealership tried to charge me for a Proxy Alignment when I asked to just update my damn radio stuck in this loop.
I have a 2015 Jeep Cherokee 8.4AN VP4 NA Head Unit 68238619AJ. I was updating from 17.11.07 to 18.45.01 and got stuck at the step 11 1% and would get a failed sierra wireless every time and then got in that "bolo update failed" loop..Well to fix it just now all I did was download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in the previous comment and quick format to FAT32 on a 16GB Micro Center USB extracted the files from 16.33.29 to the USB with 7ZIP, plugged in like normal and BOOM it ran the first step restarted and I had a working radio again showing update 18.45.01.
(So i'm assuming you don't have to do the S Byte thing I didn't even mess with it I just used the 16.33.29 to bypass step 11 since that version only has 14 steps and 18.45.01 was already preloaded from attempting before. My navigation still is the wrong address but I don't care about all that just thankful to have my radio back before my wife killed me for trying to update it by myself. )
I hope this helps someone else one day because it took some deep research and hours on hours of forum hoping to finally find the solution. <3
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
Do you have another link to download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe files? I am trying to help a friend of mine they way this helped me. Thank you again for this!