Hi all
A quick question please. I hope nobody minds me posting his here as a new thread. Aplogies if so.
I read somewhere yesterday that custom ROM's are only a "grey area" as opposed to automatically and immediately invalidating your warranty. Is this corrrect please? I must admit I have always conisidered being forced what ROM to run is a bit like telling me I cannot change my PC's OS from Windows to Linux. At the end oif the day it is my hardware and I can put what I like on it in terms of software is, my view. I really take exception when HTC support tell me and have done more than once, I should install no 3rd party apps. on my phone. A PC with no software now, either!?
Many thanks in adavnce.
As far as I can guess...
Well, you're kinda right about it being a "grey" area. Reason being, as far as I can figure, is because HTC needs to cover their bases. Their devices can really only be insured to work according to the specifications they were designed to work. Ever heard of a flasher bricking their phone? Well, it wouldn't have happened if said person didn't flash their phone. These devices are tried and tested at the company's factories, to run well under very specific conditions. When we go flashing other roms onto them, it begins taking the hardware out of those safe confines of operation.
If you've ever read about what to do with a phone you need to return, it always states that you should return the phone to it's original SPL, and that if the spl is hacked, the company won't take it back. Most likely because if they took back a functional phone (with a hacked SPL) it would work against them if another device with a hacked SPL had to be returned on account of hardware problems.
If the hardware faults while running the intended rom, the blame is easy to place, and hard to dispute. If the device faults while running modified software (rom) it becomes harder to place who's fault it is. Sure, the phone SHOULD technically run the other rom and SPL, but then again, if something goes wrong you're certainly going to be trying everything in your power to get a new one for free. And unfortunately for HTC, that means they take the brunt for a failure that otherwise wouldn't have happened were you not modding your phone.
Grey area? Yep. One of those things, if you get caught, you're guilty. Then again, the amount of phones that need to be returned on account of modding, seem relatively low compared to the amount of devices which are regularly and successfully modded.
-Caid.
444
It's not that big a deal. If there's a hardware fault - just flash everything back to the stock spl and rom before you send it back and HTC will honour the warranty. If you brick it through flashing that's your problem though although it's basically unheard of.
How to re-flash if the phone won't boot
How I re-flash if won't boot up?
You can always start it in Loader mode (power and volume up (or down, never remember) button and reset the phone, it will launch in loader mode) while having the image in the root of your Flash card. It should flash the rom from there.
I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.
NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...
The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.
The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.
Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.
From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?
The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.
One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.
We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.
What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.
For anybody with the time and the hardware, that should be easy enough to try. TheBeano?
There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.
If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.
So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
I will add a little insight without giving too much away
Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...
I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet
Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
I've looked at the schematic fragments from the service manual but they weren't much help. If anyone has a schematic that shows what is connected to the application processor OM pins that would be a big help. Obviously the bootloader sources would be great too!
TheBeano said:
Obviously the bootloader sources would be great too!
Click to expand...
Click to collapse
Come on guys, lets have some input here, and I will give out snippets of info to help, just in case anyone is in any doubt to what I said, take a look at the attached screendump
Odia said:
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
Click to expand...
Click to collapse
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
http://megaupload.com/?d=C0JHS7A8 - service training manual 01/2011
manosv said:
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
Click to expand...
Click to collapse
Hey, off topic here, but i have seen these phones on ebay, chinese own brand of course, but dual boot, runs both android and windows on one phone.
so it is possible for someone who knows how to.... would be very interested in seeing this develop
http://cgi.ebay.co.uk/W6000-Dual-Ca...ile_Phones&hash=item230f1eea0a#ht_3411wt_1139
Fuma said:
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
Click to expand...
Click to collapse
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
TheBeano said:
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
Click to expand...
Click to collapse
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Fuma said:
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Click to expand...
Click to collapse
It's the schematic for a cheap phone with the Mediatek MT6225 processor, the "CSL Blueberry" I think. They have an "i9000" model so maybe that's how it started.
mmm...well if i stumble upon more stuff i'll send your way . it might help.
TheBeano said:
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
Click to expand...
Click to collapse
Yeah, it's got to be the fsa9480. That plus (possibly) the volume/power/etc buttons are the only possibilities. The fsa switches which lines from inside the phone are connected to the micro-USB pins 2 & 3 (aka D+/D-). But it also has (at least) 2 digital outputs called JIG and BOOT which feed back to the CPU. BOOT presumably causes a hardware reset, so the JIG line is free to determine the boot mode.
We know the normal boot is from OneNand. Looking at table 6.3 of the data sheet tells us that the only pin that matters is OM5. Pins OM[4:0] determine which of the 4 different OneNAND boot modes is used, and that mode is the same regardless of OM5. So they are almost certainly just fixed. If OM5 is 0, the chip boots normally (directly from OneNAND). If it is 1, the ROM will first try to negotiate a UART connection, then try a USB connection, and only then (if I'm reading it right), fail over to a normal OneNAND boot.
So it's hard to imagine any scenario other than pin OM5 connected to the JIG output of the fsa9480.
From the Samsung source code linux/drivers/usb/gadget/fsa9480_i2c.h, there are a few interesting resistor choices (I'm not sure what the 5 bits represent; maybe they are for setting/reading the switch state over i2c) :
Code:
1 0 1 1 0 150K UART Cable
1 1 0 0 0 255K Factory Mode Boot OFF-USB
1 1 0 0 1 301K Factory Mode Boot ON-USB
1 1 1 0 0 523K Factory Mode Boot OFF-UART
1 1 1 0 1 619K Factory Mode Boot ON-UART
The 301K case (Factory Mode Boot ON USB) is the familiar "jig" people on xda use. But USB protocol is fairly complex, and since the whole idea of using the fsa switch is very non-USB compliant (the thing sends analog audio over D+/D- lines !) I don't think we can assume anything about what the ROM code does to "negotiate a connection". In addition, I think that all the people who have already looked into this were specifically trying to get into "download mode" (i.e., Loke protocol to talk with Odin). So who knows what else was going on beforehand.
I'm most curious about the behavior with a 619k resistor (Factory Mode Boot ON UART). The nice thing with UART mode is that we already know from TheBeano's thread that there is output at 115200 baud that appears at some point in the boot process. By putting a scope probe on the Tx line and simultaneously watching the text output in a terminal emulator, it should be very simple to see if any kind of negotiating is going on at an early (ROM) bootloader stage. Maybe it involves different baud rate, banging on a key, or pressing/holding a button. But (for someone with time and the right hardware) this is very do-able. If there is any hint of negotiation going on before the NAND-based bootloaders begin, we know we're onto something promising.
Like Odia pointed out, any stuff that we load during the ROM bootloader stage is not being flashed to the OneNAND; it is simply being loaded into RAM and executed. So even with no clue how to write a bootloader, I can imagine writing a "hello world"-grade program to, say, toggle a GPIO. That would clearly establish that the UART bootload procedure works.
So I think its an exciting prospect. Some of it is way beyond my abilities, but there are some easy steps early on that could really generate some intense developer interest.
I've got a I897 and a scope, but no connectors or cables to sacrifice. I may get a breakout board from Sparkfun to mess around with. In the meantime, I'd love to hear if anybody with a resistor/cable combo can sniff out anything interesting.
Also, I'm glad to see some response. I guess my title was a little cryptic, but at first it was just me and the crickets.
Found an interesting post about the ROM bootloader : http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
Another interesting link : http://chdk.wikia.com/wiki/GPL_Disassembling
Lets just say that the ROM code from my phone (Captivate) is definitely talking to the serial ports (all 4) and the USB OTG port.
I just sent off a quick order to Sparkfun for their USB micro-B breakout (the male connector with all 5 pins broken out) and a 3.3V FTDI (USB/serial) board. Just in case I find myself w/ too much time on my hands.
js22 thats actually sounds promising.
waiting for more updates.
Goodluck
e-fuse bits anybody ?
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Oops. I just checked and any read from the SFR address range (0xE0E00000 and up) returns zero. At least if you're using viewmem.
js22 said:
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Click to expand...
Click to collapse
Its using none secure boot and your quite right JTAG access is also none secure.
So, the source code to the IROM would answer all our questions.
It would probably take me a week to reverse engineer it, unfortunately, I don't have the time right now.
The I9000 is a fairly open platform. Would samsung themselves be prepared to give this source code out.
If we could get to a point where any hacker could un-brick their own phones without even having to unscrew the case, using pin 4-5 resistors, and a 3 Volt UART cable or a USB cable, developers would be much more willing to experiment more.
I have a method to force the IROM to try alternative boot methods, and specifically not run the PBL, SBL, but without more information on what to try in order to talk to the IROM directly, is it difficult to proceed further.
To force IROM to ignore PBL and SBL, just do a heimdall dump in Linux and press CTRL-C half way through. It results in a bricked phone, with only the IROM working. I have been told a 301K Resistor will help switch it back to loading PBL and SBL but I have not tested this yet.
Does anyone have contacts within Samsung that might be able to help, or shall I try to use my contacts to source the information?
The IROM looks like it would try to use the USB in OTG mode. Thus expecting the external USB device to be a gadget and not a PC Host. This can have advantages and disadvantages.
1) Disadvantage: Not many Android developers will have USB Gadget test hardware.
2) Advantage: The I9000 itself might be a good USB gadget development tool. Changing the kernel usb driver so that it can respond correctly to commands from the IROM over USB. Potentially, we could then use one I9000 connected directly to another I9000 and the healthy I9000 could automatically unbrick the bricked I9000.
For development though, I think using the UART option would be easier to do, as any Android developer would have a serial port, and then just need a RS232 levels RS232 to 3.3V levels converter, wired up to a Micro-USB connector and the correct resistor on the ID pin.
It is also easier to write a Serial port controlling application than USB controlling applications.
I think that we would still need to reverse engineer the IROM in order to analyze it and discover what the protocol is for loading software directly into the I9000 RAM and running it without going through the boot of IBL/PBL/SBL.
We would then need to write our own boot loader to put in this RAM in order for it to reach a mode where it can program the flash and possibly provide the same functions as the current "download mode".
If we can get it as far as partitioning, and writing the IBL/PBL/SBL. That would be enough.
There are other advantages of this IROM interface. We could use it to root the phone by writing an "su" to the /system folder.
A stepping stone to this could be a "hello world" program that simply controls a GPIO. For example, flashing the LEDs that light the BACK key or writing a message to the screen.
Having the current source code to the IBL/PBL/SBL would really help here as it contains the routines to display characters and graphics on the display etc.
I'm partway through disassembling the ROM boot code, it's pretty interesting! The serial protocol is definitely in there, but I haven't worked with ARM code before so it may take some time. If anyone has already worked it out or is nearly there please let me know now!!
MODS: I AM NOT 100% SURE THAT THIS GOES HERE. MOVE THIS IF NEEDED.
Ok. So all my android phones up to this one have had the ability to have their bootloader unlocked. I know that this specific phone has only been out for about 8 months now and we are seeing little to no progress on the unlocking of the bootloader.
My question is, how?
Where do you even start to unlock a bootloader?
What tools are needed?
Once you find a way to unlock your device (the one you have been working on) how do you package it and test it on other devices?
The reason I ask is because I have a bit of time on my hands and I know a bit about code.
I understand that trying to do something like this is EXTREMELY hard or it would have been done by now, but the way I see it the more heads banging against the same wall. Sooner or later the wall is going to give.
If you want to look into trying to do this I would guess the threads Adam Outler left in the VZW Note 2 forums on how he did it.
Sent from my SM-N900V using Tapatalk
The N3 takes full advantage of ARM Trustzone technology in the Snapdragon 800 SoC. This involves a microkernel running on a separate ARM core from processor ROM space and SoC private memory to do things like key storage and crypto computations, as well as chain-of-trust bootstrapping where each image loaded in the boot sequence is cryptographically verified before loading.
There is a portion of the eMMC flash memory chip (rpmb - Replay Protected Memory Block) which can only be accessed via a hardware protocol that re-keys every read-write transaction. So, even if you could sniff the eMMC (hardware) bus, you might be able to passively read data, but the key used to generate the transaction nonce is never exposed... meaning you won't gain control of it.
In addition, as of the MJ7 release, part of this boot sequence (aboot - the part which interacts with Odin) stores & uses anti-rollback protection information which disallows even valid *prior* Samsung firmware from being re-flashed onto the device. This is to prevent vulns discovered in prior releases from becoming a gateway to device customization.
Sounds complicated, right? Well, that's only the start of it. In addition there are "trustzone applets" that are running during the normal boot that continuously perform a variety of attribution measurements that detect tampering of kernel memory, changes to certain partition signatures, etc. It is sort of unknown at this point whether or nor these live "tripwires" also blow irreversible tamper fuses on the SoC or merely write tamper detection into the rpmb via the TZ api. In either case though, the possibility exists that "harmless" activity such as a kernel exploit that writes into volatile private kernel memory could result in semi-permanent disabling of the device.
In any event, there isn't a playbook for exploit discovery, other than this: understand approximately how a given subsystem works, and look for/test against implementation errors. If one is found, the dev needs to create and test hypotheses that might allow a minor exploit to be leveraged up into increasing privilege or control.
I'm not optimistic that a "class break" exploit of the hardware trustzone technology will occur; but the normal OS requires services from the trustzone, so perhaps there are implementation errors that exist that are close to the exposed APIs.
Probably there are private methods known to Samsung ARCs (Authorized Repair Centers) for reprogramming/resetting devices. These are probably low-hanging fruit in the sense that (a) if known they would enervate devs to experiment, knowing they have a rescue method, and (b) are the type of thing which could be exposed through social methods, and (c) are close in function to the goal of loading altered images onto the phone.
This phone has a *ton* of security stuff going on compared to phones that are only one year old. Given Samsung's dominance in the Android "premier device" segment, if I were CyanogenMod's new investors, I would be worried about what this portends for the future for aftermarket ROMs which require a custom kernel.
Maybe the right approach is to beat Samsung up over their horrid track record for making developer devices available - or maybe it is time to start rewarding OEMs who are happy to allow opt-out of device lockdown through market mechanisms. Samsung boycott, anyone?
Personally, I find it objectionable that my phone needs to be locked down and bristling with security armament on the off-chance that it might someday become a corporate BYOD device. That puts the interests of a low-probability straw-man ahead of the actual device owner... namely, me.
bftb0
I agree with you that it is a load of rubbish that our phones are locked down, but I still have hope that we will get an unlock procedure. Adam Outler, despite saying he was done with Samsung devices, has somehow managed to get past Secure aboot and turn it off. He posted a picture of it on his G+, which he promptly deleted because people were sending massive amounts of hate simply because they didn't understand that bypassing aboot was not an unlock.
I still have hope for an unlock but it fades everyday, I think one of our best hopes would be Outler if he is truly looking into to bootloader unlock us. There are so many devs looking into it though that any one of them could do it any day.
Sent from my SM-N900V using Tapatalk
I know there's a lot of threads on this, and some guides, but they're all so vague. It seems like a lot of people are making suggestions based on assumptions that the people having the problem have a slight idea of what to do.
I don't. At all. All I know is there's a program that lets you control your phone with your PC, but you have to do something that NORMAL people DO NOT think to do with their phone. (Enable USB Debugging.)
Now I'm stuck with an entirely, repeat, entirely non-functioning screen. As in, no display, no response to touch, nothing.
What I want to get off the phone, as far as I know, can't be done just by copying and pasting the files to my computer.
I have some game save files on there that I didn't upload to Cloud, so I can't exactly get them back.
It's really irritating to start games over constantly, and I had a fair bit of progress on a number of them, so I really DON'T want to start over again.
If someone could PLEASE help me with this, properly, with more detailed instructions, I would be grateful. I already downloaded [email protected], but again, since I don't have USB Debugging enabled, and NO WAY to do so by means of the phone, it's kind of useless.
I had a similair situation myself and I just gave up.
You need to enable it in the build.prop and you need to disable rsa signature.
The only way you can do that is by flashing it trough a custom recovery. But you cannot select the file. Thus unless you can figure out a way to flash that trough Odin.....
See, now if it's possible, it would be great to get a walkthrough of how to do so.
Either that, or just be told how to grab the save files of my mobile games so I don't have to start over again.
So recently I decided to reinstall Windows 10 for my iRULU 2-in-1, model W10, but I had no idea this would cause things like my webcam, sound, HDMI, SD card reader, battery detection, touch screen, and more to all stop working. And the website where you would have been able to get a W10 image for the device, is no longer online (I guess iRULU has dissapeared or something). The tablet is nearly useless at the moment with half the stuff on it no longer working, and my search for the drivers have turned up nothing. If anyone happens to have an OS image for the device or something, that would REALLY help me out.
Did you find anything? I am still looking for it as well. I had the firmware but then I deleted it or lost it I don't remember where.
I just found back this tablet in a drawer and I was to try either an install of Linux (I have some good clues for that) or an Android x86 (seems to be feasible as far as I have seen from other BayTrail tablets).
But before that my tablet is ready to help if someone needs something on it before I wipe W10. If so, drop me a line
I'll keep it for some time under W10 because I will try on another BayTrail tablet where the process is well documented...