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!!
Related
Ok, setting up the old debian chroot is pretty straight forward. I had it up and running within a couple of days. What I really want to try to do is boot into debian natively.
I've been poking around and looking into a few things. I'm thinking it shouldn't be too hard to modify the init.rc to bring up debian instead of the normal android services and whatnot. From looking around it looks to me like init.rc lives in the boot image. So I'm guessing I would need to put together a boot.img with my custom init.rc and any supporting files.
Thoughts?
Should be totally doable. Debugging the boot process is a PITA though. Some things that might help with that:
TTL level serial (2.8v, 3.3v tolerant, I think) is available on the D+/D- lines of the microusb connector when VBUS (usb +5vdc) is not present. You can test a cable with a running N1 -- a couple taps of enter should get the debug> FIQ debugger prompt. For your own build, you'll probably want to enable serial console on ttyMSM0 and disable the FIQ debugger.
Alternatively you could try to dust off the fbconsole support. We never build with it, so it is *possible* that it has some problems, but it might Just Work <tm>.
Until you get a GUI environment up that has touch support, your inputs for on-device for debugging are limited -- volume buttons, power button, trackball button, trackball. The "soft keys" are implemented in userspace, not the kernel -- the kernel just provides a touchpanel driver.
Somebody could probably do an in-kernel softkeyboard, like the guy who did the android-for-vogue stuff way back when did, or perhaps you could convert graffiti-style strokes to keys in-kernel or something suitably fun like that.
I don't currently have the equipment I would need to setup a serial cable for that. Perhaps in the near future though. Thanks for that tip.
Is fbconsole part of the android source, or is a kernel option? I've been digging around for it, and haven't been able to track it down yet.
I poked at this a little over the weekend. Played around with init.rc, but I couldn't get my sdcard to mount without logging in via adb and mounting it by hand. I also decided it would probably be easier to install debian on a partition on the SD card instead of mounting an image off of the card.
I have a lot to learn here, espesially figuring out how to get debian to boot so I expect this will take me some time to figure everything out.
fbconsole is doing some very weird stuff. Scrolling sideways, a very distorted looking image scrolls by. All in all pretty much unusable. I have a mini - micro adapter, and a spare mini usb cable I don't mind donating to science, so having a go at building a serial cable tonight.
You might want to have a look at this
Woot! BOOTS!
Hit default run-level tonight
Next. Configure it so it does more then start cron.
It's already been done, as of 11 days ago...
http://forum.xda-developers.com/showthread.php?t=622474
Could have saved yourself some time with a simple 3 second search...
I hate to break it to you but chrooting into a debian image is not booting into debian. Cute trick, but I had that done the day after I got my nexus.
I'm talking about booting debian from the boot-loader.
Anywho...
I got hung up with getting getty running. Once I installed udev, getty started playing nice.
Debian GNU/Linux 5.0 TheBriaDroid ttyMSM0
TheBriaDroid login:
Stumbled upon this a bit ago, a company called Mobile Tech is offering an "unbricking" service on all versions of the Galaxy Tab. At the time of this writing they charge $50. I have not used this service, am not in any affiliated with this company and cannot vouch for their work, so beware. Just thought someone out there might use this when other options aren't available.
They have a nifty video up on youtube showing how they do it:
it will be a good help for those who brick their tab because they ain't follow the steps .. thanks for sharing this out
I can actually vouch third party for this service. Have had two friends use it and the device was returned within a few days. If I'm not mistaken, the guy lives in the southern US, but can arrange international he says.
Sent from my "better than an iPad" tab... Running Overcome GINGERBREAD!!!
This is cool, but I would recommend trying to go through Samsung first if you are still under warranty. I screwed up my primary bootloader and contacted them. They took care of shipping costs, fixed it up, and sent it back in about a week and a half. If Samsung hadn't fixed it I would defiantly have payed the $50 here though.
WOW, that seems like a lot of work for $50.
Thanks for the info, should I ever screw something up its nice to know there are people out there who can clean up my mess!
spacemoose1 said:
a company called Mobile Tech is offering an "unbricking" service on all versions of the Galaxy Tab.
Click to expand...
Click to collapse
Hi spacemoose1
Thanks for link and as always, thanks for honeycomb port. I would like to ascertain the definition of BRICK? with your help, if I may.
(disclaimer: pls forgive my wrong terms or exagerated explanation, but most importantly, pls correct me if I'm wrong)
BRICKed = software total lost, must use JTAG to force revive it, Samsung has it, or buy from web supplier around 300 USD ??? 500 USD ???
JTAG is a device to push software into all newly borned IC. I.E. when factory make IC, it's empty software inside, hence has a special device to push voltage into all sections of the IC, then force the code in.
Another term is ???CRASH??? or ???HANG???, (I don't know) anyway is not BRICKed, hence a reflash can recover it.
Samsung uses proprietary method a lot, not follow conventional, make usb driver very complex. USB driver install EXE around 15MB to 28MB depends on version, ALL work the same.
but, when the device = sgt7 in different state/condition, the driver must RE-ESTABLISH again, or else cannot work.
I.E.
state 1 = "OPERATIONAL"device in android operation, normal use, surf web, phone call etc
state 2 = "SLEEP" device powered off, show battery big icon charging when powered by charger
state 3 = RECOVERY mode
state 4 = DOWNLOAD mode - this is one of the way to FORCE flash to recover, as long as bootloader and something still intact
state 5 = PHONE-!-PC mode
stage 6 = "COMA" device powered off, NO show of battery big icon, even when charger supplied. Don't panic, let it charge fully 4 hours from 2 amperes supply, 10 hours from PC 500mA. It will start again !!!. Battery big icon will appear around 30% battery charged, I know because that's what I saw. I didn't check when it's in 10% or 20%. The 1st time I check was already 30% up from no-boot or no respone.
User need to plug device into PC during each of the state above at least once, in order for various flashing functions to work.
i.e. when it's a newly arrived device, usually install the usb driver 1st, with device state in android OS running properly, then plug in to USB and see "new device detected" installing, pls wait. Finished.
But when flashing via Odin using state 4 = DOWNLOAD mode, user may experience no connection, no COM3 or something. Because device must be unplugged in USB, power-up in state 4 = DOWNLOAD mode, plug in USB, "new device detected" installing = RE-ESTABLISH, done. UNPLUG USB, replug in usb, then COM3 appears FLASH will be succesfull.
same goes for other state.
p.s. many users reported BRICKed but then recovered WITHOUT JTAG is misleading beginners, hence should rename the term to ???CRASH??? or ???HANG???. although some previously use "SEMI-brick", which is acceptable.
stage 3 = ClockWorkMod flashing (super convenient, especially on the move without PC)
stage 4 = Odin / Heimdall both works (still convenient and easy )
stage 5 = Odin / Heimdall both works (still convenient and easy )
???CRASH??? or ???HANG??? or "SEMI-brick" is usually SUCCESFULLY recovered via restock+PIT
(final disclaimer, incase above is correct and help and is copied, pls correct whatever mistakes found, feel free.)
*** Thanks for all those who taught me my mistakes *** devs and fellow forumers
ManticoreX said:
This is cool, but I would recommend trying to go through Samsung first if you are still under warranty. I screwed up my primary bootloader and contacted them. They took care of shipping costs, fixed it up, and sent it back in about a week and a half. If Samsung hadn't fixed it I would defiantly have payed the $50 here though.
Click to expand...
Click to collapse
Yeah, warranty repair is always a better choice. But sometimes you've already voided the warranty, lol.
I guess, if u change factory installed rom/kernel warranty gonna be history
thanx for the post ... it might gonna be the last resort...
cx5 said:
Hi spacemoose1
Thanks for link and as always, thanks for honeycomb port. I would like to ascertain the definition of BRICK? with your help, if I may.
(disclaimer: pls forgive my wrong terms or exagerated explanation, but most importantly, pls correct me if I'm wrong)
BRICKed = software total lost, must use JTAG to force revive it, Samsung has it, or buy from web supplier around 300 USD ??? 500 USD ???
JTAG is a device to push software into all newly borned IC. I.E. when factory make IC, it's empty software inside, hence has a special device to push voltage into all sections of the IC, then force the code in.
Another term is ???CRASH??? or ???HANG???, (I don't know) anyway is not BRICKed, hence a reflash can recover it.
Samsung uses proprietary method a lot, not follow conventional, make usb driver very complex. USB driver install EXE around 15MB to 28MB depends on version, ALL work the same.
but, when the device = sgt7 in different state/condition, the driver must RE-ESTABLISH again, or else cannot work.
I.E.
state 1 = "OPERATIONAL"device in android operation, normal use, surf web, phone call etc
state 2 = "SLEEP" device powered off, show battery big icon charging when powered by charger
state 3 = RECOVERY mode
state 4 = DOWNLOAD mode - this is one of the way to FORCE flash to recover, as long as bootloader and something still intact
state 5 = PHONE-!-PC mode
stage 6 = "COMA" device powered off, NO show of battery big icon, even when charger supplied. Don't panic, let it charge fully 4 hours from 2 amperes supply, 10 hours from PC 500mA. It will start again !!!. Battery big icon will appear around 30% battery charged, I know because that's what I saw. I didn't check when it's in 10% or 20%. The 1st time I check was already 30% up from no-boot or no respone.
User need to plug device into PC during each of the state above at least once, in order for various flashing functions to work.
i.e. when it's a newly arrived device, usually install the usb driver 1st, with device state in android OS running properly, then plug in to USB and see "new device detected" installing, pls wait. Finished.
But when flashing via Odin using state 4 = DOWNLOAD mode, user may experience no connection, no COM3 or something. Because device must be unplugged in USB, power-up in state 4 = DOWNLOAD mode, plug in USB, "new device detected" installing = RE-ESTABLISH, done. UNPLUG USB, replug in usb, then COM3 appears FLASH will be succesfull.
same goes for other state.
p.s. many users reported BRICKed but then recovered WITHOUT JTAG is misleading beginners, hence should rename the term to ???CRASH??? or ???HANG???. although some previously use "SEMI-brick", which is acceptable.
stage 3 = ClockWorkMod flashing (super convenient, especially on the move without PC)
stage 4 = Odin / Heimdall both works (still convenient and easy )
stage 5 = Odin / Heimdall both works (still convenient and easy )
???CRASH??? or ???HANG??? or "SEMI-brick" is usually SUCCESFULLY recovered via restock+PIT
(final disclaimer, incase above is correct and help and is copied, pls correct whatever mistakes found, feel free.)
*** Thanks for all those who taught me my mistakes *** devs and fellow forumers
Click to expand...
Click to collapse
I pretty much agree, but I might refine:
BRICK= Unit does not power up, visibly charge, reach a boot-screen of any kind including a service or "download" screen. A device in this state requires service from the manufacturer or an individual equipped with the proper tools. There is no other way to recover a device in this state.
SOFT-BRICK= Unit powers up, reaches a "download" or service screen, visibly charges but does not boot into an OS. Crashing, hanging etc. all apply here. It is easy to recover a device from this state so long as one has access to a firmware that was designed for the device and the ability to flash said firmware.
SEMI-BRICK= See soft-brick above
JTAG= Provides access to system hardware by applying the correct voltage to the correct pins in order to push software via an external program.
In regards to the usb drivers, there are only actually 4 states
1. Active userspace
2. Serial gadget mode
3. Recovery
4. USB storage mode
And there is a separate driver for each of these (except recovery) in the Samsung driver package that should install automatically when the device is plugged in during normal use on a stock rom, or with the installation package available on the web.
The rest of it you've got pretty much correct.
Money seems right, but the amount of work that guy has to go thru is amazing, so much to tare it apart, and reassemble. Then again when it is put back toether, he checks it, what if it did not take the fix... all over again.
Hardbricked Tab Save by Mobile Tech
I hardbricked my galaxy tab bought in Cambodia. My little brother open the tab trying to take the battery off and put it back on, thus void the warranty, found him on the Samsung vibrant forum, sent the tab to him got it back good as new. This person is professional, honest and good communication with his customers, you'll be happy with his work, if he can't fix it you get your money back (minus shipping and diagnosis)...Glad he is arround to help...
spacemoose1 said:
I pretty much agree, but I might refine:
BRICK= Unit does not power up, visibly charge, reach a boot-screen of any kind including a service or "download" screen. A device in this state requires service from the manufacturer or an individual equipped with the proper tools. There is no other way to recover a device in this state.
SOFT-BRICK= Unit powers up, reaches a "download" or service screen, visibly charges but does not boot into an OS. Crashing, hanging etc. all apply here. It is easy to recover a device from this state so long as one has access to a firmware that was designed for the device and the ability to flash said firmware.
SEMI-BRICK= See soft-brick above
JTAG= Provides access to system hardware by applying the correct voltage to the correct pins in order to push software via an external program.
In regards to the usb drivers, there are only actually 4 states
1. Active userspace
2. Serial gadget mode
3. Recovery
4. USB storage mode
And there is a separate driver for each of these (except recovery) in the Samsung driver package that should install automatically when the device is plugged in during normal use on a stock rom, or with the installation package available on the web.
The rest of it you've got pretty much correct.
Click to expand...
Click to collapse
You should post this in Q/A thread on its own as its very helpful and maybe it will stop the 1% of people saying help my phone is bricked comments ... the other 99% don't read anyway otherwise they would discover their phone isn't bricked and if they read properly it would not have gotten to the state in the first place .. and no I never posted something like that myself >:¬}
but well done on this..
alexgogan said:
You should post this in Q/A thread on its own as its very helpful and maybe it will stop the 1% of people saying help my phone is bricked comments ... the other 99% don't read anyway otherwise they would discover their phone isn't bricked and if they read properly it would not have gotten to the state in the first place .. and no I never posted something like that myself >:¬}
but well done on this..
Click to expand...
Click to collapse
+1
Sent from my GT-P1000 using Tapatalk
Nice find. For that amount of effort disassembling, and reviving, $50 is a very realistic price. I'll keep these guys in mind if I run into issues with my tab.
$50 for that much work is an absolute bargain! I wish I didn't live in a country where you get charged $200/hr for someone to pick their nose.
It's actually not that much more difficult than popping an OS install CD into a hosed computer and pressing 3 keys to let it run through the installation after flashing a corrupt motherboard BIOS. Yes, it takes familiarity with the software and hardware, but it's by no means a feat that requires a special skillset.
Granted, few people have JTAG stuff handy, so $50 is definitely worth it if you've hosed your device, but don't make it sound like he's sweating and coding the bootloader by hand, strenuously manipulating micro tools to disassemble the tablet and flipping DIP switches to restore the bootloader. You spend 5 minutes taking apart the tablet, you attach the JTAG cable, run the supplied software on your computer, and sit there recording the screen with your video recorder while the progressbar moves from 0 to 100.
Again, it's worth $50 simply because not everyone and their mother has JTAG hardware sitting around, but by no means is it hard. It's the same reason I can get away with charging $100 to clean viruses off of a computer. People either don't have the tools or don't know how to use them. That being said, I don't know a damn thing about using JTAG to restore a corrupt bootloader, nor do I have the right hardware, so I'd pay $50 if I were ever in the situation.
Edit: And yes, $100 for a virus clean is a lot, but people generally change their mind when I explain to them why they got viruses, as well as installing proper antivirus software and then instructing them on how to avoid infection in the future. I rarely get repeat business from the same customer but I get A LOT of referrals ;p They're happy paying that much when the person educates them instead of cleaning, not installing/explaining, then having to bring the computer in again two weeks later for another wallet-gouge, which most other computer 'repair people' gladly do over and over.
Everything in this world is rinse and repeat... The money comes from time spent learning to use the hardware properly, micro soldering skills (which isn't easy, no matter who you are), confidence enough to offer it as a service, not to mention the couple hundred bucks for the jtag software and hardware.
Now, the fact that if you have your device in a bricked state you likely voided the warranty, it's a 600 dollar brick if your samsung tech recognized it... 50 bucks is a steal to not deal with samsung anyway.
Try to be less pompous next time oh savoir of the hundred bone virus... Your poop stinks too, promise.
Sent from my "better than an iPad" tab running Overcome Hermes.
LycaonX said:
It's actually not that much more difficult than popping an OS install CD into a hosed computer and pressing 3 keys to let it run through the installation after flashing a corrupt motherboard BIOS. Yes, it takes familiarity with the software and hardware, but it's by no means a feat that requires a special skillset.
Granted, few people have JTAG stuff handy, so $50 is definitely worth it if you've hosed your device, but don't make it sound like he's sweating and coding the bootloader by hand, strenuously manipulating micro tools to disassemble the tablet and flipping DIP switches to restore the bootloader. You spend 5 minutes taking apart the tablet, you attach the JTAG cable, run the supplied software on your computer, and sit there recording the screen with your video recorder while the progressbar moves from 0 to 100.
Again, it's worth $50 simply because not everyone and their mother has JTAG hardware sitting around, but by no means is it hard. It's the same reason I can get away with charging $100 to clean viruses off of a computer. People either don't have the tools or don't know how to use them. That being said, I don't know a damn thing about using JTAG to restore a corrupt bootloader, nor do I have the right hardware, so I'd pay $50 if I were ever in the situation.
Edit: And yes, $100 for a virus clean is a lot, but people generally change their mind when I explain to them why they got viruses, as well as installing proper antivirus software and then instructing them on how to avoid infection in the future. I rarely get repeat business from the same customer but I get A LOT of referrals ;p They're happy paying that much when the person educates them instead of cleaning, not installing/explaining, then having to bring the computer in again two weeks later for another wallet-gouge, which most other computer 'repair people' gladly do over and over.
Click to expand...
Click to collapse
I've got to call you out on this one. Mis-connecting or shorting any wires will lead to a damaged PCB and an un-resurrectable TAB. I'm also a Systems Admin for a living so I understand where you are coming from. You must realize that I solder at levels of .1mm in spacing on the Captivate, Vibrant and Nexus S. Electrical engineers and technicians have first hand talked with me about the difficulty of doing this and is NOT something that anyone can do. You'd think twice when you burn up a phone or two valued at $500 a pop trying to JTAG them. There is more skill involved than you would think. Not to mention the liability when dis-assembling the device. JTAG software is decent but it's not fully automated. There are TCK frequencies, RTCK frequencies different PBL partition sizes, full dcc loader read/writes and the requirement of EXACT voltage from an external power supply that are needed in MANY cases. Plus, there is little to no support when fixing a device. This means that if you can't figure it out, nobody else is going to for you. I'm not trying to brag but yet point out that this isn't like plugging in your phone for an ODIN flash. I've taken hundreds of hours of time and 1000's of dollars to create what I feel is the most trusted JTAG authority online ANYWHERE. I greatly appreciate having the opportunity to help the community and enthusiasts in this community. If this was as easy as you are claiming, you could get JTAG hardware and a manual at Best Buy. I have to say you put it best when you said you don't know anything about JTAG... Ok end of rant I was just a bit bothered by your post.
Ok with that being said, thanks for the personal testimonies and compliments. I will be here whenever anyone needs JTAG assistance in the future or around the forums to help answer Q&A when it doesn't require JTAG. Here is a Nexus S promo to realize how tiny some of these things are
http://www.youtube.com/watch?v=Ecp8jKmm48k
i would love to learn more on how to do stuff like this if i had moneyz. the .1mm ext.
not just for android but to make my own ish.
thanks for the awsome videos.
Thanks for the link, hope I won't need it ;-)
Sent from my GT-P1000 using XDA App
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
So one day I was using Samsung Smart Switch to restore my firmware from Lineage OS to default Samsung. Everything was going well until the application gave me some kind of error box.
It said something along the lines of, “Update mode failed to initialize.” After that, my tablet went dark. I couldn’t power it on, or anything. Couldn’t even get it to go into download mode. If anyone could help, please do. Thanks in advance.
龍88 said:
So one day I was using Samsung Smart Switch to restore my firmware from Lineage OS to default Samsung. Everything was going well until the application gave me some kind of error box.
It said something along the lines of, “Update mode failed to initialize.” After that, my tablet went dark. I couldn’t power it on, or anything. Couldn’t even get it to go into download mode. If anyone could help, please do. Thanks in advance.
Click to expand...
Click to collapse
Have you tried holding the Home, Vol down and Power buttons for over ten seconds? It could be that, even though the screen is black, that the tablet is still on.
4929york said:
Have you tried holding the Home, Vol down and Power buttons for over ten seconds? It could be that, even though the screen is black, that the tablet is still on.
Click to expand...
Click to collapse
Yes, I have. And I know the screen isn't just black, because every time I attempt to plug it into my computer no input is detected.
Nevermind, it was actually just my charging universal serial bus port that was broken. I guess I had no battery that time so it ran out during the process of restoring my tablet.
龍88 said:
Nevermind, it was actually just my charging universal serial bus port that was broken. I guess I had no battery that time so it ran out during the process of restoring my tablet.
Click to expand...
Click to collapse
Yeah, I was gonna say, probably the greatest thing about Samsung devices, which almost makes up for the slow updates and the difficulty ROM developers have historically had in supporting Exynos, is Download Mode. It's hardcoded onto a read-only chip, will boot even if you lack a bootloader, and always works perfectly with Smartswitch or Odin as long as your MicroUSB port works, thus making is literally impossible to hard-brick a Samsung device except by causing physical damage (dropping, water damage, sledgehammer, etc). I don't know of any other OEM that has something similar. HTC's S-On sort of did the same thing, but it was on the regular NAND chip which made it less noob-proof than Download Mode, could theoretically be turned off, and was much more restrictive in the partitions it gave developers access to. I'm not loyal to Samsung or any other brand, my current Tab A 10.1 is my first Samsung device and could still be my last if someone else has better specs and better software for a better price in the next generation, but this is one of my favorite features. The moment you suggested you'd hard-bricked it with a simple attempt to flash something onto the regular NAND, I knew something had to be wrong with the battery or MicroUSB port.
Seanthedroid said:
Yeah, I was gonna say, probably the greatest thing about Samsung devices, which almost makes up for the slow updates and the difficulty ROM developers have historically had in supporting Exynos, is Download Mode. It's hardcoded onto a read-only chip, will boot even if you lack a bootloader, and always works perfectly with Smartswitch or Odin as long as your MicroUSB port works, thus making is literally impossible to hard-brick a Samsung device except by causing physical damage (dropping, water damage, sledgehammer, etc). I don't know of any other OEM that has something similar. HTC's S-On sort of did the same thing, but it was on the regular NAND chip which made it less noob-proof than Download Mode, could theoretically be turned off, and was much more restrictive in the partitions it gave developers access to. I'm not loyal to Samsung or any other brand, my current Tab A 10.1 is my first Samsung device and could still be my last if someone else has better specs and better software for a better price in the next generation, but this is one of my favorite features. The moment you suggested you'd hard-bricked it with a simple attempt to flash something onto the regular NAND, I knew something had to be wrong with the battery or MicroUSB port.
Click to expand...
Click to collapse
While DOWNLOAD mode is fairly robust it actually can quite easily be killed by a bad flash.
Speaking from experience. Aboot is responsible for booting the kernel or DOWNLOAD mode.
ABOOT should always be flashed with its corresponding SBL.
If not then the SBL may reject ABOOT as it wont have the correct signature. This breaks a chain of trust which is started from when the device is turned on and the firmware initialized.
(basically this is what is meant by secure boot seen in download mode)
If the SBL rejects ABOOT the device simply will not boot and will appear dead. No DOWNLOAD mode nothing.
Unfortunately I did this by accident when trying some mods out and flashed the wrong ABOOT thus killing my T555.
If you're lucky the device will drop into qhsusb_dload mode, however I think this mode only activates if the SBL believes ABOOT is corrupt not if it's failed the chain of trust.
Unfortunately this didn't happen, so the only option I have is to flash the EMMC direct using something like RIFF BOX in ISP mode(which I already have, but needs an update).
Failing that there is a little trick with an SDCARD adapter that could work with limited success I may try.
So just to sum up anything beyond flashing bootloaders is unlikely to brick the device as this will ensure DOWNLOAD mode is always accessible.
Anyone owning a Fire 7 needs to stop drop and roll...literally. Please go to your tablet and with a file explorer (i don't know if you need root) in the root directory please try in whatever way possible to read the contants of all files (theres like 3 or 4) with 'fstab' in the file title. Look for ANY properties ANYWHERE that have to do with 'acm'. I am fairly certain, without root you can persist this property in ADB. Get your tablet, plug into PC and open ADB window and type:
Code:
adb shell setprop persist.sys.usb.config mtp,adb,acm
Your PC will light up like a christmas tree with new drivers for the tablet. If it does, then the chances are VERY high that you will be able to root and unlock your fire 7. This is almost certainly going to work on the HD 10. https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
Turns out I wasn't crazy or stupid after all !!!!!! All I ever asked was for you guys to just listen to me and understand I knew exactly what I was seeing
DragonFire1024 said:
Anyone owning a Fire 7 needs to stop drop and roll...literally. Please go to your tablet and with a file explorer (i don't know if you need root) in the root directory please try in whatever way possible to read the contants of all files (theres like 3 or 4) with 'fstab' in the file title. Look for ANY properties ANYWHERE that have to do with 'acm'. I am fairly certain, without root you can persist this property in ADB. Get your tablet, plug into PC and open ADB window and type:
Code:
adb shell setprop persist.sys.usb.config mtp,adb,acm
Your PC will light up like a christmas tree with new drivers for the tablet. If it does, then the chances are VERY high that you will be able to root and unlock your fire 7. This is almost certainly going to work on the HD 10. https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
Turns out I wasn't crazy or stupid after all !!!!!! All I ever asked was for you guys to just listen to me and understand I knew exactly what I was seeing
Click to expand...
Click to collapse
Can you explain what is the acm mode, its bootrom download mode? I do not understand what we can do with the tablet in ACM mode. If we do not get the tablet to enter the BootROM Download Mode this mode will not help us at all.
How does the computer detect the tablet when it is in ACM? I tried it on my Fire 7 and it does not install any driver ...
EDIT: I read this:
Code:
Before Download mode can be entered, the Preloader has to find out if a host is connected via USB or UART and running the MTK SP Flash Tool. It does this by configuring a virtual CDC ACM discipline on USB, so both lines are in fact serial ports and behave similarly.
The USB port will assume that the tool is connected if it receives a “set line coding” (configures baudrate etc.) CDC message. It then sends the string READY to the tool and waits for the reception of a token of eight bytes.
After successful detection, the tool can send the special Start command sequence (0xa0 0x0a 0x50 0x05) to enter a special mode that is only available via USB. It interprets the following commands (I left the ones marked with “legacy” out):
Its seem that ACM mode its Download Mode
Rortiz2 said:
Anyone owning a Fire 7 needs to stop drop and roll...literally. Please go to your tablet and with a file explorer (i don't know if you need root) in the root directory please try in whatever way possible to read the contants of all files (theres like 3 or 4) with 'fstab' in the file title. Look for ANY properties ANYWHERE that have to do with 'acm'. I am fairly certain, without root you can persist this property in ADB. Get your tablet, plug into PC and open ADB window and type:
Can you explain what is the acm mode, its bootrom download mode? I do not understand what we can do with the tablet in ACM mode. If we do not get the tablet to enter the BootROM Download Mode this mode will not help us at all.
How does the computer detect the tablet when it is in ACM? I tried it on my Fire 7 and it does not install any driver ...
EDIT: I read this:
Its seem that ACM mode its Download Mode
Click to expand...
Click to collapse
ACM allows a device to emulate ports. Example: the tech doesn't have a usb port to connect the tablet. ACM can be used so the tablet emulates a different port other than USB. In our case, ACM appears to be the God mode.
DragonFire1024 said:
ACM allows a device to emulate ports. Example: the tech doesn't have a usb port to connect the tablet. ACM can be used so the tablet emulates a different port other than USB. In our case, ACM appears to be the God mode.
Click to expand...
Click to collapse
Had this device before. Got a new phone and gave it to my brother. But can you explain a bit, just entering those acm commands wont give you root, I know but what after that?
Will check this method when I go to my brother's.
Adyatan said:
Had this device before. Got a new phone and gave it to my brother. But can you explain a bit, just entering those acm commands wont give you root, I know but what after that?
Will check this method when I go to my brother's.
Click to expand...
Click to collapse
Please see: https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
ACM is a proprietary function mediatek uses to emulate the USB port as a different port so they can access their devices using various hosts. It's also a way for them to access the device without modifying the firmware or system. It's a clean, legit way an oem should access a device. This explains a lot of my discovery that kicked off this whole process. We could see all this happening in the HD 10 binary files, but we couldn't see how this access was happening or where it was coming from. My theory was Amazon used a back door and a mode or user ID greater than super to access devices without the use of private keys. Of course that was crazy talk and impossible and I can't blame any one of you for not believing me. I however never imagined this going beyond Amazon. I'm honestly in total disbelief that any of this is happening and even more so that my crazy cat lady theory was right from day one. I'm just greatful and honored that the few of you who didn't think I was crazy, took it to the next level. If it weren't for all of you, my theory would have been buried and forgotten. In the 3 years since I started all this I never imagined it would come to this. All of you are amazing!!!
DragonFire1024 said:
Please see: https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
ACM is a proprietary function mediatek uses to emulate the USB port as a different port so they can access their devices using various hosts. It's also a way for them to access the device without modifying the firmware or system. It's a clean, legit way an oem should access a device. This explains a lot of my discovery that kicked off this whole process. We could see all this happening in the HD 10 binary files, but we couldn't see how this access was happening or where it was coming from. My theory was Amazon used a back door and a mode or user ID greater than super to access devices without the use of private keys. Of course that was crazy talk and impossible and I can't blame any one of you for not believing me. I however never imagined this going beyond Amazon. I'm honestly in total disbelief that any of this is happening and even more so that my crazy cat lady theory was right from day one. I'm just greatful and honored that the few of you who didn't think I was crazy, took it to the next level. If it weren't for all of you, my theory would have been buried and forgotten. In the 3 years since I started all this I never imagined it would come to this. All of you are amazing!!!
Click to expand...
Click to collapse
ACM isn't a proprietary function from mediatek. TtyACM is typically used for modem-devices, but in the end it's just a serial-connection.
And the ACM you are enabling using this command has nothing to do with the ACM of the BOOT-ROM.
Also this has nothing to do with amazon or backdoor-keys or any super user access.
It is an exploit of the mediatek boot-rom which is part of the SOC and cannot be changed.
They are totally different things.
DragonFire1024 said:
Your PC will light up like a christmas tree with new drivers for the tablet. If it does, then the chances are VERY high that you will be able to root and unlock your fire 7.
Click to expand...
Click to collapse
Does that mean the 2015 Fire 7 in (5th gen) may be able to be rooted? If so, do we have to do the thing where the back of the tablet needs to be opened and the pins have to be grounded?
whattheclap said:
Does that mean the 2015 Fire 7 in (5th gen) may be able to be rooted? If so, do we have to do the thing where the back of the tablet needs to be opened and the pins have to be grounded?
Click to expand...
Click to collapse
If device is running FireOS 5.3.1 or lower it can be rooted via software hack. Otherwise, you'll need to crack open the case and play the pin shunt game.
whattheclap said:
Does that mean the 2015 Fire 7 in (5th gen) may be able to be rooted? If so, do we have to do the thing where the back of the tablet needs to be opened and the pins have to be grounded?
Click to expand...
Click to collapse
Davey126 said:
If device is running FireOS 5.3.1 or lower it can be rooted via software hack. Otherwise, you'll need to crack open the case and play the pin shunt game.
Click to expand...
Click to collapse
Don't have to open the case! Need to start by bricking with 5.0.1 sideload, then you can talk to 5.0.1 preloader as in here:
https://forum.xda-developers.com/amazon-fire/development/downgrade-fire-7-2015-softbrick-t3894671
It'll be bricked with 5.0.1, but preloader with get into Bootrom via a button push, and that's all you need.
bibikalka said:
Don't have to open the case! Need to start by bricking with 5.0.1 sideload, then you can talk to 5.0.1 preloader as in here:
https://forum.xda-developers.com/amazon-fire/development/downgrade-fire-7-2015-softbrick-t3894671
It'll be bricked with 5.0.1, but preloader with get into Bootrom via a button push, and that's all you need.
Click to expand...
Click to collapse
Would this work on the Austin?
Pix12 said:
Would this work on the Austin?
Click to expand...
Click to collapse
Yes it already does. A bit limited by the current low knowledge of the hardware but it will improve with time
and some software tool to help less skilled people avoid to have to do with a soldering iron and/or disarm the tablet.
.:HWMOD:.
hwmod said:
Yes it already does. A bit limited by the current low knowledge of the hardware but it will improve with time
and some software tool to help less skilled people avoid to have to do with a soldering iron and/or disarm the tablet.
.:HWMOD:.
Click to expand...
Click to collapse
Oh nice, so this could lead to a bootloader unlock for both Fire 7s?
bibikalka said:
Don't have to open the case! Need to start by bricking with 5.0.1 sideload, then you can talk to 5.0.1 preloader as in here:
https://forum.xda-developers.com/amazon-fire/development/downgrade-fire-7-2015-softbrick-t3894671
It'll be bricked with 5.0.1, but preloader with get into Bootrom via a button push, and that's all you need.
Click to expand...
Click to collapse
Well that's an interesting approach and one I would not advise to the faint of heart. That said, it's probably the path I'd pursue on a personal device that I would be willing to sacrifice. Advantages of 5.0.1 bootloader outweigh other considerations in my world where simplicity, stability and minimal maintenance outweigh redirected blood flow.
Davey126 said:
Well that's an interesting approach and one I would not advise to the faint of heart. That said, it's probably the path I'd pursue on a personal device that I would be willing to sacrifice. Advantages of 5.0.1 bootloader outweigh other considerations in my world where simplicity, stability and minimal maintenance outweigh redirected blood flow.
Click to expand...
Click to collapse
Why not advice? Definitely safer than opening it up and poking around with a paperclip
But sure, if you have a rootable OS and that's all you desire both methods aren't for you.
That said the tablet is now basically unbrickable
k4y0z said:
Why not advice? Definitely safer than opening it up and poking around with a paperclip
But sure, if you have a rootable OS and that's all you desire both methods aren't for you.
That said the tablet is now basically unbrickable
Click to expand...
Click to collapse
It can need a paper clip and opening the device as well.
"With older preloader-versions you can then simply hold the left volume-button while pluging the device in.
If you have a newer version, you will have to open the device and remove the metal-shielding (it is clipped on)"
k4y0z said:
Why not advice? Definitely safer than opening it up and poking around with a paperclip
But sure, if you have a rootable OS and that's all you desire both methods aren't for you.
That said the tablet is now basically unbrickable
Click to expand...
Click to collapse
Most of my varied devices are bootloader unlocked which affords full control over hardware and flexible recovery from all but the most aggregious flubups. Not my first stroll through the turnip patch. That slobber lined path is far removed from experiences of the common user. Intentionally bricking a working device is not guidance I would give lightly during the early stages of exploit exploration. Same goes for blindly probing around the circuit board with metal objects. Die hards will eagerly take the plunge regardless of risk and share their experiences, good and bad, with the community. Tip of the hat to those bold adventures. Only after the liabilities and rewards are fully understood would I reconsider guidance for non card carring members of the geeks-r-us society. Seen plenty of noobs go down in flames naively following supposedly 'easy' instructions to nirvanaville.
Simply put .... a suggestion for the novel user poking around in the hardware is enough as a sign of being helpful.
Why should we insist trying to make them stay away from the world of electronics ?
I just suggest to start using a resistor about 1kohm when shorting test points or pads on the motherboards working from 3V to 5V.
This gives them a minimum margin of safety and potentially avoid or makes it less probable they burn some components on the PCB.
Later on they can try to lower that resistor value to a value from 100ohm to 200ohm if they didn't had the expected results and retry.
Many will burn some of their stuff, yeah ... why not, they are used to it. They paid for it and deserve to do what they want with it.
My view though, everybody has the right to express different point of view.
.:HWMOD:.
hwmod said:
Simply put .... a suggestion for the novel user poking around in the hardware is enough as a sign of being helpful.
Why should we insist trying to make them stay away from the world of electronics ?
I just suggest to start using a resistor about 1kohm when shorting test points or pads on the motherboards working from 3V to 5V.
This gives them a minimum margin of safety and potentially avoid or makes it less probable they burn some components on the PCB.
Later on they can try to lower that resistor value to a value from 100ohm to 200ohm if they didn't had the expected results and retry.
Many will burn some of their stuff, yeah ... why not, they are used to it. They paid for it and deserve to do what they want with it.
My view though, everybody has the right to express different point of view.
Click to expand...
Click to collapse
Agree with all the above including the sensible cautions. If one understands the basic function of an electrical resistor and the units involved then there is probably both interest and knowledge to proceed. Now we've addressed the 5% club I submit the rest should stay on the sideline until more is known. Same for the brink-n-revive suggestion that started this exchange. I hold no power over what individuals do with their devices. I can only provide guidance based years of experience that extends well beyond hand held gizmos.
Davey126 said:
Agree with all the above including the sensible cautions. If one understands the basic function of an electrical resistor and the units involved then there is probably both interest and knowledge to proceed. Now we've addressed the 5% club I submit the rest should stay on the sideline until more is known. Same for the brink-n-revive suggestion that started this exchange. I hold no power over what individuals do with their devices. I can only provide guidance based years of experience that extends well beyond hand held gizmos.
Click to expand...
Click to collapse
I agree with both of you, all I'm saying is for those who have made up their mind and want to do this, I think bricking intentionally and then using the exploit is the safer route, since it's a software-only solution.
With poking around on the mainboard there is more things that could go wrong, I've seen people shorting VBAT to ground.
Pix12 said:
It can need a paper clip and opening the device as well.
"With older preloader-versions you can then simply hold the left volume-button while pluging the device in.
If you have a newer version, you will have to open the device and remove the metal-shielding (it is clipped on)"
Click to expand...
Click to collapse
It's going to cost you .... You can make a hole like me with a knife but I do not recommend it ...
ITS SOLDERED ON! In Austin