Related
So I had an idea today...I'm sure the geniuses that have gotten the Dx and D2 this far have already tried it; but I cannot find any information on it. What if we tried the good old fashioned trick of cold booting:
Google princeton cold boot. I cannot paste links.
I am going to make my best efforts to try this, but I know there are many people that are far better than I. I will let you know of my results, if I ever achieve any.
I think this is an interesting idea, and have read a lot about this being done on laptops... would be interested to see if this works for the android system...
It would only work if the keys are stored in RAM tho... and I think the keys are hard coded into a chip (thought I heard this somewhere...could be 100% wrong)
Anyways...would be interested to see some of the devs try this...
No idea if this would work but if this could be pulled off it would be a pretty epic hack
This looks to rely on the ability to run custom OS/Software. Since our current hacks involve loading *after* the kernel, I doubt this would work.
Kinda like a chicken before the egg problem.
It requires custom rims on another host. Realistically all you need is for the princeton program to read the ram from a different partition. Im sure it can be modified to mount the phone and read the ram from there.
Kinda as an acknowledgement/off-shoot of what zaphod has said...
What if a second init process could be kicked off to hijack the boot process kinda like what koush did..
If the ram could be dumped quick enough... Would this work? I'm not a dev, but do a lot of sys admin work and understand many of the concepts for kernels, and boot processes...
Just trying to help throw out ideas and get the creative juices florin for those who can develop.
Ps, zaphod, thnx for all ur contributions on this forum, many of ur posts have helped me.a TON
Just Chiming In
That's kind of what unrevoked did:
I know we have completely different phones, but this is basically how they cracked HTC:
They found out that in the booting of the phone, during the init, adb would start, but then immediately get killed off by HTC's init. what they did then was found out that if they inserted an SD card into the phone at the precisely exact time (between when ADB started and got killed off by MOTO) so that it would be read right before ADB was killed by MOTO, it would hang MOTO's init, so they had full adb access during the init process, which allowed them to run the phones STOCK recovery alongside ADB. Firstly it allowed them to get root, then once they got root what they basicall did was kick off a LEGIT system update through the phones recovery and then SWAP it for a payload right in between when the phone finished the key checks and started writing the new system....
I know that we have two different things going on here.... but if they did this, I'm sure we could pull something like swapping kernels during load.....
MAN I wish Unrevoked got and tried to crack the X, but they focus on HTC phones.
Any way to send this idea the devs' way without looking pushy? I think from a technical stand-point this is a worthwhile idea to look into...or at least give some thought to it...
thinking about it further
After thinking about this more I think the answer has to lay in this exploit. We are right in stating that the key is actually burnt into a chip somewhere. However, we must remember that there is some key generation going on during the bootloader phase. Thus: at some point the correct key is stored in memory as the phone correctly boots. If the phone boots, the key is laying someplace in memory. It's just a matter of finding it.
I haven't had time to play with this yet, hopefully I will have some time this week or weekend. I am very confident that this will work, it's just a matter of figuring out how to get the program that reads the memory to look at my phone, not my computer.
lilott8 said:
After thinking about this more I think the answer has to lay in this exploit. We are right in stating that the key is actually burnt into a chip somewhere. However, we must remember that there is some key generation going on during the bootloader phase. Thus: at some point the correct key is stored in memory as the phone correctly boots. If the phone boots, the key is laying someplace in memory. It's just a matter of finding it.
I haven't had time to play with this yet, hopefully I will have some time this week or weekend. I am very confident that this will work, it's just a matter of figuring out how to get the program that reads the memory to look at my phone, not my computer.
Click to expand...
Click to collapse
Liliott,
I'm really glad you are looking into this. I've read about this hack for pc's and think there may actually be something to this. I feel like if we could have something that hijacked the boot process real similar to Koush's recovery then if someone could write a program that would dump NVRAM (I think this is the equivalent to the phone RAM) this would work. With this said, I believe that the devs originally working on cracking the bootloader were able to get NVRAM into "engineering mode" (don't remember the exact terminology off the top of my head)....but I still am thinking this idea should definitely be given more credit and looked into.
I would love to help, but I don't have any dev experience, so I'm somewhat at a loss there....Thanks for pursuing this!
The key you need (presumably an RSA key) wont be stored anywhere on the phone at all.
What happens is that Motorola produce new software for the phone and sign it with their private key (that only Motorola have). This is then sent to the phone. (OTA or whatever they do) The phone verifies the signature using a public key burned into the ROM of the phone (i.e. you cant change it without physically modifying the hardware somehow)
The best hope to break the bootloader on this phone is to reverse engineer it and look for an explot, as has been done on Moto phones in the past (various Motorola MOTOMAGX linux phones have been cracked open this way)
jfwfreo said:
The key you need (presumably an RSA key) wont be stored anywhere on the phone at all.
What happens is that Motorola produce new software for the phone and sign it with their private key (that only Motorola have). This is then sent to the phone. (OTA or whatever they do) The phone verifies the signature using a public key burned into the ROM of the phone (i.e. you cant change it without physically modifying the hardware somehow)
The best hope to break the bootloader on this phone is to reverse engineer it and look for an explot, as has been done on Moto phones in the past (various Motorola MOTOMAGX linux phones have been cracked open this way)
Click to expand...
Click to collapse
Question:
Ok, I know that this will pretty much fall flat, but I have to ask. The Milestone, and OG Droid are pretty much the same phone. Do they have the same boot loader, just unlocked? If so is it the same as the X? The reason I'm asking is it might be easier to crack the Droid since it's already unlocked?
It might be like looking at the lock from inside out trying to figure out how it opens, vs trying to open the lock by looking at it from the outside.
Also, does the MOTO use "goldkeys" like HTC did at one point in time, or have they moved on from that?
On another point, MOTO changed their keys from 2.1 to 2.2, and the phone accepted them. That tells me that it's possible. How much time that will take, I don't know.
Finally, is there any way to "intercept" the process like unrevoked did? I mean if we could get adb working while recovery is working, we could start the recovery process using a legit OTA, and overwrite the zip through adb AFTER verification and before the actual copying. That shouldn't set off the fuse, right?
ideas?
dreamersipaq said:
Question:
Ok, I know that this will pretty much fall flat, but I have to ask. The Milestone, and OG Droid are pretty much the same phone. Do they have the same boot loader, just unlocked? If so is it the same as the X? The reason I'm asking is it might be easier to crack the Droid since it's already unlocked?
It might be like looking at the lock from inside out trying to figure out how it opens, vs trying to open the lock by looking at it from the outside.
Also, does the MOTO use "goldkeys" like HTC did at one point in time, or have they moved on from that?
On another point, MOTO changed their keys from 2.1 to 2.2, and the phone accepted them. That tells me that it's possible. How much time that will take, I don't know.
Finally, is there any way to "intercept" the process like unrevoked did? I mean if we could get adb working while recovery is working, we could start the recovery process using a legit OTA, and overwrite the zip through adb AFTER verification and before the actual copying. That shouldn't set off the fuse, right?
ideas?
Click to expand...
Click to collapse
The Milestone has a locked bootloader, and hasn't been cracked for a year.
Sent from Eris with Froyo
TheSonicEmerald said:
The Milestone has a locked bootloader, and hasn't been cracked for a year.
Sent from Eris with Froyo
Click to expand...
Click to collapse
I really am not trying to sound (too) rude when I say this, but
Did you even READ my whole post?
Yes, the Milestone is locked, but the Droid (the Milestone's US twin) is not.
*Golf clap*
Gotta love it when people reply to a post without even reading a few sentances of the post they are directly replying to. It is understood that the Milestone's bootloader is locked, he was questioning how close the hardware and programming were between the OD (Original Droid) and Milestone aside from the lock being activated in the Milestone. It is the general consensus that the same lock and efuse functions exist in the OD but they are not activated. If this is true then it might be beneficial to see if any of the developers out there with a spare OD test to see if they can figure out how to activate the lock on an OD and then potentially have a better understanding of what might be involved with de-activating it.
Thanks!!!
JinxtPhoto said:
*Golf clap*
Gotta love it when people reply to a post without even reading a few sentances of the post they are directly replying to. It is understood that the Milestone's bootloader is locked, he was questioning how close the hardware and programming were between the OD (Original Droid) and Milestone aside from the lock being activated in the Milestone. It is the general consensus that the same lock and efuse functions exist in the OD but they are not activated. If this is true then it might be beneficial to see if any of the developers out there with a spare OD test to see if they can figure out how to activate the lock on an OD and then potentially have a better understanding of what might be involved with de-activating it.
Click to expand...
Click to collapse
rant
*Bow*
I'm glad that there are still people out there that have a reading comprehension above that of a wet mop. I won't insult them and say they have a low IQ though
I hate it when you take the time to put something that you though about up and someone comes along, reads the first sentence, and (without making any effort to finish the paragraph or REALLY think about what the person is trying to say) spew up crap equivalent to that of the "First" post on blog comment boards.....
/rant
Any haxzors? is this liable, possible, waste of time?
*please don't reply with "waste of time". give us some reasoning, otherwise your post does not help us at all*
The reason it might now
The reason why it actually might not fail is this:
When the system boots, it runs it magic RSA/PGP/AES encryption. It then takes that and compares that to its bootloader routine that it loads. Where does it store the bootloader encryption result to compare to the system boot key? If you guessed memory you would be correct. Now if it stays in memory we will have the golden ticket. If Motorola is smart, and wipe that part of the memory upon OS boot, then it's a matter of timing. If we can get that key, we can, potentially, intercept the bootloader, present the key that we stole and boot our own bootloader/cooked rom.
I think there is quite a bit of potential here.
*Clapping continued...*
I'm glad to see more people finally chiming in on this topic. Call me naive...but when it comes to the dev communities, it seems like "where there's a will...there's a way"
They had made decent progress on cracking this (kinda...) maybe this idea is one that should be looked into (probably said this like 5x in this thread now...oh well)
Thank you to dreamerispaq and Jinxt, appreciate you guys throwing some comments in here
did the release of the 2.2 SBF help at all? If there was a kernel change from 2.1 to 2.2, wouldn't a method be inside of the SBF? Is there any way to hijack the SBF to allow installation of a custom Kernel and ROM?
Shouldn't there basically be an entire phone image inside of the SBF file? If so, would it be possible to alter pieces of that to create some kind of exploit, or use RSD Lite itself and altered SBF's to load up custom kernels and ROMS?
I'm just chucking stones blindly here, I know this is way above my skill level, but I can't help thinking that a full SBF should help similar to the way you can pull the system image from an HTC RUU.
giventofly17 said:
did the release of the 2.2 SBF help at all? If there was a kernel change from 2.1 to 2.2, wouldn't a method be inside of the SBF? Is there any way to hijack the SBF to allow installation of a custom Kernel and ROM?
Shouldn't there basically be an entire phone image inside of the SBF file? If so, would it be possible to alter pieces of that to create some kind of exploit, or use RSD Lite itself and altered SBF's to load up custom kernels and ROMS?
I'm just chucking stones blindly here, I know this is way above my skill level, but I can't help thinking that a full SBF should help similar to the way you can pull the system image from an HTC RUU.
Click to expand...
Click to collapse
Unfortunately, I don't think so. The issue is that both sets of keys are probably hashed and encrypted.... so even if we pulled out the private key out of the SBF that motorolla used, we'd have to brute force it to decrypt it. If, let's say they were smart and used something like RSA as stated above, it'd take a super computer a couple of decades to crack it.
A brute force attack is not going to be helpful here I'm afraid. I'ts going to be more of a lets look at the code, and see if we can find a flaw somewhere in moto's coding that we can use to our advantage.
That's why I recommended looking at the OD. If it shares the same bootloaded, it's already uncloked. Maybe we could take it, reverse engineer it, and look at the calls it makes, where it looks for files, what order it loads things in, etc.... THIS would be more beneficial IMHO.
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!!
Hello to all good guys in xda-developers forum.
This is my very first post and I really feel desperate and need your kind help.
New Acer iconia with stock firmware 3.2.1 was nicely running this morning until I tried to root the device.It was supposed to be very simple process and not to get into dirty complicated procedures but the gingerbreak.apk did not work as expected so I tried alternative methods.What I read in various forums was that the gingerbreak application is not able to root the new firmwares version so I tried to downgrade the firmware to 3.0.1.
Downloaded the Acer stock recovery firmware EUUs_SBK_Acer_A501_0.017.01_PA_ATT.exe and attempted to flash onto my tablet .I think I did all necessary pre-installation checks.The process started but it stopped on 10 percent for about 30 minutes without any progress.Only Acer logo was displayed and 'entering file downloading mode' at the top of the screen.
After long time no change I finally gave up and unplugged the device from the USB port and restarted but nothing works since then.
1. No vibration on Start
2. Black screen
3. No new USB device appear on my PC
4. No sign of any activity other then power button light
I guess the original firmware was wiped but the new firmware was not flashed...for whatever reason...perhaps the worst scenario.
I will really appreciate If anybody may give me advice how to fix it.
So it turns on but does not display anything? Have you tried to hold the power button and volume down button at the same to when you turn it on to try to get it into recovery. Also there is a little reset button on the side you can try to push.
Sent from my A500 using xda premium
tried all those thinks.All kind of tricks I could find on the net.The problem is that the device is not showing up in the device manager e.g not detected as USB device of an y kind....
acera500 said:
tried all those thinks.All kind of tricks I could find on the net.The problem is that the device is not showing up in the device manager e.g not detected as USB device of an y kind....
Click to expand...
Click to collapse
Try this thread. Look about halfway down, and you'll see almost the exact thing you did, and how this guy got it going.
http://forum.xda-developers.com/showthread.php?t=1291747
Basically you can run a search for APX in the main forum threads and find some other posts, but hopefully this will get you going.
I pulled this from the general forum (eventually), but you can also search the Q&A main forum page as well, and the dev forum.
Another link;
http://forum.xda-developers.com/showthread.php?t=1255519&highlight=apx&page=2
If its new just return it to the store for another one.
Sent from my A500 using xda premium
Acer or the store did not brick it
i THINK If you mess with the rom on your tablet and... BRICK your device .. you should tough it out and fix yourself... Acer or the store is not responsible for this .But then you could also argue that if they had not locked the bootloader this type of bricking would not happen..
So i say go above and beyond to try to fix it from the help on here.. if that fails.. THEN Maybe exchange it.. Its wrong to brake something then expect someone else to foot the bill. Yes im to honest for my own good at times... Acer has also been known to repair .
If you bought a extra warranty all of the above in my book is out the window.. Make them replace it ..
GIGGLES..
Good luck on getting it repaired ..and be more careful next time..
Piece of cake to fix if you kept you USB serial number (from the downgrade tool)???
===== If you have your USB serial number ====================
1. Lets assume you know your USB serial number. If not, then you might be able to get it from your registry.
2. Download my flashing tool at http://forum.xda-developers.com/showpost.php?p=20680452&postcount=137
a. Open up the readme.pdf for the instructions on how to flash
3. KEEP your acer unplugged and run the program
4. The program will install the APX flash drivers and will tell you to plug in the USB. Ignore this step. It will not work. In the instructions skip steps 3, 8, 9, 10.
5. Eventually the flashing tool will timeout because you do NOT have the tablet connected. It will then display a message box telling you how to use a paperclip and the power button to get you into APX mode. THIS IS THE secret to getting the tool to flash your ACER. However, once you get it into APX mode you will need your USB serial number (without it, you are fubar).
a. Plug in the tablet to your computer with the USB and paperclip yourself to fastboot.
6. Now in step 11, enter your USB serial number
7. Now just follow the rest of the instructions.
====== NO USB Serial number ==========
If you do not have your USB serial number than you are going to be out of luck, unless you have ever connected the device to your computer. If you did, then your registry will have a history containing your serial number.
Google usbdeview tool and download it. This will show the serial number of any USB device you've connected to your computer.
===== No Serial number, never connected it, what to do ==========
If you have no serial number and cannot get it, then hopefully you can get to recovery mode (power & volume) and flash using a signed update.zip from ACER. Download one of the update.zip's and put it on your external SDCard and then boot to recovery.
=== Bricked and No serial number, never connected, and you fubar'ed the recovery image ===
If you never connected your table to the USB and your computer to get the USB serial number then you are NOT going to be able to flash it to fix it.
If you fubar'ed the recovery image then you won't be able to get into recovery to run the ACER update zip.
At this point, you can still get your tablet into APX fastboot mode using a paperclip and the power button. But I know of NO way to flash it without the USB serial number and I know noway to get the USB serial number from the APX driver. I've tried and looked at getting the serial number from just APX mode, but I cannot determine how to get it. Someone out there might know.
Hope this helps,
TD
Your CPUID can also be found in the uid.txt file in your cwm backup folder - /mnt/external_sd/clockworkmod/backup/ - just remember to drop the 0x when you need to enter it
erica_renee said:
i THINK If you mess with the rom on your tablet and... BRICK your device .. you should tough it out and fix yourself... Acer or the store is not responsible for this .But then you could also argue that if they had not locked the bootloader this type of bricking would not happen..
So i say go above and beyond to try to fix it from the help on here.. if that fails.. THEN Maybe exchange it.. Its wrong to brake something then expect someone else to foot the bill. Yes im to honest for my own good at times... Acer has also been known to repair .
If you bought a extra warranty all of the above in my book is out the window.. Make them replace it ..
GIGGLES..
Good luck on getting it repaired ..and be more careful next time..
Click to expand...
Click to collapse
Honestly if more people returned bricked phones/tablets etc... they would quit locking them down... the you broke it you fix it because they want to keep people from doing things they should be able to do with THEIR system they bought... In other words I completely don't agree with this at all.. If everything was unlocked and such then I would support the you fix it, but then again we wouldn't be running into these issues now would we. But then again Most people need people to babysit them and tell them what they can and can't do with what they own..
wade7919 said:
Honestly if more people returned bricked phones/tablets etc... they would quit locking them down... the you broke it you fix it because they want to keep people from doing things they should be able to do with THEIR system they bought... In other words I completely don't agree with this at all.. If everything was unlocked and such then I would support the you fix it, but then again we wouldn't be running into these issues now would we. But then again Most people need people to babysit them and tell them what they can and can't do with what they own..
Click to expand...
Click to collapse
@wade7919. You clearly have never worked in IT support on a hardware level.
Or maybe, I am barking up the wrong panty-leg?
If you bought a high dollar corvette, GM will support it. If you add an aftermarket chip, and your engine blows, do you expect GM to fix it? No. I wouldn't expect it either. Not their problem. Just because you can add a chip, doesn't mean you should do it.
That's why they try to lock bootloaders. To prevent users from doing things they shouldn't. Unlock them, and it opens a whole world of issues based on "open source". God help us if they unlock bootloaders.....
Not sure what you are getting at. I am under the belief, if you broke it, you fix it. Take responsibility for one's own actions. Shouldn't take the panzy pussyass way (no offence Erica and werecaltf), and return it for replacement. Suck it up, and learn from experience. Otherwise, the next device, you'll do the same stupid thing again.
I like things the way they are. Difficult, but not impossible. That separates the people with balls (again Erica and wercatlf, no offense), from the sheep.
But if you fubar the device, own up to it, and fix it. Don't pawn it off to somebody else (return it). And if you don't have the brain cells to have a backup plan before you start... Well, don't shed tears over it. Own up, throw the testosterone in the garbage disposal, and fix it.
Somebody give me a zanex...
And people, stop using Gingerbreak!!!!!!
Why locking a bootloader will cost ACER billions
Moscow and wade7919, you both make good arguments.
But it is what point of view you're coming form. If I bought a car and changed the RIM's on all 4 wheels and the engine blew up, would GM refuse to honor the warranty?
However, if I put jet fuel and alcohol in for gasoline and blew the engine why would they honor the warranty?
So, the question here is does rooting a device cause actual damage to the device thereby preventing rooting saves them warranty issues? Or is the device also considered to include the software and is covered under warranty?
I'm not taking sides here, but you both are making very good points but with different examples at different points of view.
So, lets look at other items and see if we can draw a parallel. If I buy a brand new Dell computer and send it in for Warranty and there is nothing wrong with the hardware they charge me (correct?). So if I fubar the OS or load something that caused the damage I pay for it or fix it. If there is actually a hardware failure then they cover it under warranty.
So, why does an Android MFG take the warranty one step further and include the OS and take steps to lock it so you cannot change it? Well, this is because nobody owns the OS (it's open source) therefore they take ownership of the build. Because there's no Microsoft to blame, they lock the software and consider it to be part of the overall device (Apple claimed this in their lawsuit). So, in the MFG's mind, there is no difference from the screen, keyboard, or the firmware & software.
So the question is what do you think should be covered under warranty? Most people think it should be just the hardware like a PC. Others see the whole device which includes the OS.
My point of view:
What follows is my rant and my opinion (you are warned )
In my opinion, I had NO problem until they decided to lock the bootloader. I have no problem with them claiming warranty from A-Z and if I change anything they won't warranty it. No problem, I understand that and accept full responsibility. But by ACER locking the bootloader they went too far.
To me this would be like GM welding the hood shut on my car. Better yet, it would be like me waking up one morning and opening my garage to get in my car and discover that during the night GM welded the hood shut. This, in my opinion, is illegal. Matter of fact, in my opinion, it violates US Federal hacking laws because they enter a system and destroyed data. I eventually think OEM's will get a class action suit filed on them for this.
Secondly, Windows 8 is going to be the game changer. OEM's can now make a hardware device and sit behind only warranting the hardware. You have a problem with the OS, call MS. Also, there is a HUGE (I mean HUGE). Did I mention HUGE, demand for tablets in business. Businesses will NOT put a device that has all these consumer games and social networking loaded into the workforce. There are billions in business applications that can be made, but you cannot sell them if they only run on a tablet that cannot have games removed etc.
Example might help: Medical field <- Think of all the applications a tablet can be used to save costs in hospitals. Do your really want your doctor or nurse etc using this tablet on facebook? Insurance company's, law firms, retailers, traveling sales, etc etc (Government). The list goes on.
Developers will see this huge opportunity and will write applications because they can sell them to A-Z and the business buying them will buy them because they can remove facebook and gmail from their company owned tablets. Now, as more and more developers move to Windows they'll drop Android. Want another example, read about Netflix and the issues they have had supporting a fragmented Android OS. So, business applications will move to Windows, but you might say so what, the consumer market is still there. True, but all you need is one killer application that everyone will want and for that to only be on Windows 8. Want some examples, here's my list, NFL (or sports), Netflix, Skype (gee owned by MS now isn't it?), or something new.
Bottom-line is this, if ACER and the others want to lock their bootloaders then they have just taken themselves out of the game for any business sales. Can you imagine walking into a boardroom showing the Government how your new VA application will save the VA Hospitals millions next year alone and improve veterans healthcare. Your application runs on any HC Android tablet. Everything is smoking, going great, as you hand your tablets, ACER a500', around the room. They are loving it. You just hit 'pay-dirt', then someone says hey I see these ACER's have gmail, facebook, blah blah. We cannot have government employees using tablets with those applications loaded, your installer removes them doesn't it? Silence enters the room, all eyes are focused on you. Your mind see millions escaping which were just within your grasp, you pause, you think, and you say YES General as you grab your Motorola Xoom and say 'that's why we recommend you buy nothing but Motorola.'. ACER just kissed millions in sales goodbye (oh and this is a true story).
i do believe acer should lock the bootloader on there devices.
However thee are things I would be doing with my tab if it were not locked.
Acer should give us the ability to flash the bootloader and not use the proprietary software. Lock that software to there bootloader.for there protections.
Give us a wway to unlock it..AT OUR OWN RISK..
So it should be locked but have a way to unlock it with the end user understanding they are totally on there own ..
I would be OK with voiding my warranty.
@Dean,
"So if I fubar the OS or load something that caused the damage I pay for it or fix it. If there is actually a hardware failure then they cover it under warranty."
Yes, that is true. Bootloaders are locked, to prevent completely stupid idiots, from doing things they absolutely no idea what the sam hell they are doing.
The issue is, should we be able to return a device, after we fubarred it? Against warranty? To say, Hey, your weakness allowed me to do it.
Just because the ability to do it exists, and we can quote a thousand instances, It doesn't mean we should, and to shirk responsibility. And pass it off to the main individual.
The fact is, the policies and regulations are there, and we should abide. And if we don't, we have to own up and deal with it.
And if we don't, then we are no better than the low life of the world. The scum.
Moscow Desire said:
@Dean,
"So if I fubar the OS or load something that caused the damage I pay for it or fix it. If there is actually a hardware failure then they cover it under warranty."
Yes, that is true. Bootloaders are locked, to prevent completely stupid idiots, from doing things they absolutely no idea what the sam hell they are doing.
The issue is, should we be able to return a device, after we fubarred it? Against warranty? To say, Hey, your weakness allowed me to do it.
Just because the ability to do it exists, and we can quote a thousand instances, It doesn't mean we should, and to shirk responsibility. And pass it off to the main individual.
The fact is, the policies and regulations are there, and we should abide. And if we don't, we have to own up and deal with it.
And if we don't, then we are no better than the low life of the world. The scum.
Click to expand...
Click to collapse
Very well put.I do know of a few people who have sent there device to acer after messing it up installing rom and telling acer.acer still fixed it free.
Honesty is always best
The evils of rooting
I'm still missing something here, why locking a bootloader does anything. Go get a Mortorola Xoom (not the FE) and you run the unlock OEM. It tells you that you are unlocking it. It tells you that you unlock it at your own risk. You cannot relock it until it is 100% back to stock. It asks you three times are you sure.
Locking the bootloader and treating everyone as an idiot is the problem. Just do what Motorola does, and stop being everybody's keeper. If they want to 'Police' this then you should have to call ACER and they fax you a form. You give DNA to prove who you are and fax it back. Then you go to a mandatory rooting class, that lasts for 5 days, where ACER preaches to you the sins of rooting. Then you have to take and pass a test. Then and only then, after passing the test you get a certificate. Then you call back, give them your certificate ID. Now they give you the secret key to unlock only your tablet.
That's the ticket,
TD
Bottom-line, it's not that they locked the boatloader, it's that you cannot unlock it. Like I said, go out to your driveway some morning and find that GM welded the hood to your car shut because they think you are stupid and shouldn't be opening the hood. Mind you that YESTERDAY, and at the time your bought it, it was not welded shut. That ladies and gentlemen is what ACER did with their OTA.
Moscow Desire said:
@wade7919. You clearly have never worked in IT support on a hardware level.
Or maybe, I am barking up the wrong panty-leg?
If you bought a high dollar corvette, GM will support it. If you add an aftermarket chip, and your engine blows, do you expect GM to fix it? No. I wouldn't expect it either. Not their problem. Just because you can add a chip, doesn't mean you should do it.
That's why they try to lock bootloaders. To prevent users from doing things they shouldn't. Unlock them, and it opens a whole world of issues based on "open source". God help us if they unlock bootloaders.....
Not sure what you are getting at. I am under the belief, if you broke it, you fix it. Take responsibility for one's own actions. Shouldn't take the panzy pussyass way (no offence Erica and werecaltf), and return it for replacement. Suck it up, and learn from experience. Otherwise, the next device, you'll do the same stupid thing again.
I like things the way they are. Difficult, but not impossible. That separates the people with balls (again Erica and wercatlf, no offense), from the sheep.
But if you fubar the device, own up to it, and fix it. Don't pawn it off to somebody else (return it). And if you don't have the brain cells to have a backup plan before you start... Well, don't shed tears over it. Own up, throw the testosterone in the garbage disposal, and fix it.
Somebody give me a zanex...
And people, stop using Gingerbreak!!!!!!
Click to expand...
Click to collapse
Okay comparing A Tablet or PHone to a car is stupid... Compare it to a Desktop Computer or Laptop... Companies do not lock them down so you can not use different OS's now do they.. They offer Backups to restore the system back to how it was with recovery partitions dont they? or they offer the choice to buy whatever OS you want to install correct? they don't limit you to say just Windows or *NIX do they? But we don't see laptops or desktops locked down to where you can't upgrade your system yourself or anything else... and any dumdass can do that without an issue most of the time. and there is more issues with viruses and crap on computers than phones or tablets...
So before you start making statements like compare this to that learn what to compare to first. If you mess something up on a hardware level sure pay for it.. if you mess something up on a software level because they decided to Babysit people its their fault. and if you think its the persons fault because they decided to open up a PRODUCT that they bought and own then you are one of the people that need babysitting and like everyone telling you what to do and how to do it. Go to an apple product then.
---------- Post added at 07:07 PM ---------- Previous post was at 06:51 PM ----------
Also if you really brick your device you can always give
http://paranoidandroid.us an email to findout about getting it fixed
wade7919 said:
Okay comparing A Tablet or PHone to a car is stupid... Compare it to a Desktop Computer or Laptop... Companies do not lock them down so you can not use different OS's now do they.. They offer Backups to restore the system back to how it was with recovery partitions dont they? or they offer the choice to buy whatever OS you want to install correct? they don't limit you to say just Windows or *NIX do they? But we don't see laptops or desktops locked down to where you can't upgrade your system yourself or anything else... and any dumdass can do that without an issue most of the time. and there is more issues with viruses and crap on computers than phones or tablets...
So before you start making statements like compare this to that learn what to compare to first. If you mess something up on a hardware level sure pay for it.. if you mess something up on a software level because they decided to Babysit people its their fault. and if you think its the persons fault because they decided to open up a PRODUCT that they bought and own then you are one of the people that need babysitting and like everyone telling you what to do and how to do it. Go to an apple product then.
---------- Post added at 07:07 PM ---------- Previous post was at 06:51 PM ----------
Also if you really brick your device you can always give
http://paranoidandroid.us an email to findout about getting it fixed
Click to expand...
Click to collapse
I still like my car comparison
I make the car comparison to illustrate a point, because when I compare tablets to a PC everyone piles on *****ing about MS.
Bottom-line it doesn't matter if it's a blender or a PC. I own it, you own yours and I can do what I want with mine as you can with yours. Now, again I have a BIG(did i mention BIG issue with them changing it on me after I bought it.
To get back on topic, is the original poster still out there?? Has any of this helped? Are you still bricked?? Give us an update so we know if anything worked or you still need help.
The device was returned and accepted for replacement by the shop.Got new one and feel very nervous to start rooting procedure over.I was really lucky that they did not charge me anything but I really want to know what I did wrong so I don't brick my new device again.
I will provide further details soon about my computer OS and firewall settings and perhaps we may figure out what I did wrong.
To all good guys who send me them suggestions and solutions I wanna say big THANK YOU !!!
Your help is really priceless and thrilled me deeply. Will update topic soon
Happy New Yer to all Android fans!!!
So...Back on the subject.
My device was purchased in Japan and its current firmware version is
Acer_A500_7.009.03_AAP_CUS6JP
Q1. Can I flash US or World Wide firmware version on that device.
Q2. Does anybody know the Acer's ftp download server address for Japan
Q3. I think its a good idea to dump my original stock firmware but it seems there is no way doing that prior rooting.So..kinda stuck .any suggestions appreciated.
P.S. I'm thinking about flashing the latest Rooted rom 3.2.1 V3 by timmiDean (thanks for your hard work) I read the instructions very carefully and I think that everything will go smoothly but just in case (considering the specific Japanese firmware version)
would appreciate any further directions by the author.
Thanks
Hello,
I'm hoping some community members with extreme level of understanding of Samsung Knox Security can help clarify a warranty denial - perhaps for thousands (class action)...
First, and most notably, a device with a 'custom binary status does NOT unilaterally mean a device was Rooted, correct? Therefore, if Samsung were to systemically deny ALL devices' warrant entitlement - simply on grounds of 'custom' status, by officially pronouncing ANY device with 'custom status, as unequivocally (quote) "ROOTED" - that may be incorrectly oversimplified, in their favor.
Is it possible that a device with a hardware defect causing massive overheating, causing thermal shutdown, mid OFFICIAL LEGIT UPDATE, ect (or whatever reason) an Operating System corruption could, in fact, cause device to show as 'custom' - without ANY 'ROOT' at all, correct? (Especially when Samsung Knox Security shows 100% UNCOMPROMISED/TRIPPED, )
In fact, there are multiple scenarios in which a device may show 'custom status, without ever having been maliciously modified via security circumvention process of 'Rooting?
Please advise and discuss. I have found out that Samsung automatically, systematically, may have denied thousands of VALID warranty claims - which could result in a class action.
I don't know all the ins and outs of Knox Security, but I can add some experience pertaining to Custom Status. It is very possible to trip the Custom Status flag without tripping the Knox flag or being rooted. There are multiple package disablers available that can disable system packages, which can throw the Custom Status flag. The disablers are designed for NON-ROOTED devices, and if I recall correctly they are granted permission by Knox. Before root access was gained for the S7, a few people thought they accidentally figured out a way to root the S7 based on the phone showing Custom Status. Try using a package disabler on a NON-ROOTED S7 and disable a single package called sysscope, then suddenly your phone will say Custom Status. A lot of people got their hopes up that root had been found, only to have their hopes shattered when I proved it wrong.
As for hardware defects causing massive overheat and thermal shutdown, I have a Motorola Droid X that would overheat and shutdown if I was charging it in the car when it was hot outside. I'd even consider battery issues to be hardware related failures, such as the Note 7. There was enough media coverage as well as a total recall to prove it's possible. I'd also like to add that the Note 7 isn't the only phone to cause fires. There have been some iPhones and other Samsungs that have caught fire, but it was a much smaller scale compared to the Note 7.
I will get in to this topic more with you when I am not at work, but bottom line they are going to claim that you procured the hardware understanding it was manufactured for the purpose of completing task x. As soon as you run any customized software they will claim you are exceeding it's capability therefor creating an unstable environment where it would be impossible for them to support it, especially with all the 'custom' code that could be used.
With that being said, would you mind if I asked what you were trying to accomplish because it may still be possible.
What I'm trying to accomplish as far as the hardware or attempting to distinguish that there is a very distinct difference between a totally defect-driven (overheating interrupted official update, I imagine) Operating System Corruption causing integrity checks to fail, defaulting it's status to 'custom' vs Samsung automatically labelling Quote "ROOTED"?
Bottom line is, I'm trying to ascertain the exact specifics as to just how many ways and specific causes a device is triggered to be 'custom'....
As I've dealt with the Samsung Executive Office, after 13 calls, final being from State's Attorney General, Consumer Protection Division - Problem is that samsung does not bother to do any type of diagnostic to determine just how a 'custom' status is triggered. To be clear, they do not differentiate ANY difference between 'custom' and 'Rooted'.. EVEN when Samsung Knox has NOT been tripped/flagged for deliberate modification and/or security circumvention for gaining root access to run unsigned code (or whatever)...
If there is ANY way a device can be 'custom' from a simple operating System corruption (even worse, when directly attributed to being a symptom of a hardware defect - overheating, ect) and Samsung has systemically and unilaterally denied thousands of MFR Warranty claims on inaccurate assumption that all 'custom' status devices are in fact QUOTE: "ROOTED" - then there could be a very compelling argument for a class action.
What I do know is my despite NEVER having rooted, rather extreme overheating has caused thermal override to trigger up to 20 reboots an hour.... I and a Verizon Tech Level 2 or 3 (?) spent an entire day back and forth trying to pinpoint why/how my device become 'custom'. We postulate that a simple Operating System Corruption caused hash checks to fail and, by default, trigger an innocent 'custom' status.... This hypothesis seems to stand up (seems to is where you experts come in) [correct us if we're wrong] when considering that the Verizon Variant has a locked bootloader - which means any modifications would require "Rooting", which would be detected by Samsung Knox and flagged as such, and cannot be reversed. My (and, perhaps many other) device's software/operating system integrity was EASILY repaired and returned to 'OFFICIAL', with Samsung Knox UNFLAGGED, by simply using the Verizon Software Repair Tool. The tool simply reflashed the official firmware which was corrupted when update was interrupted by overheating.
I believe, in addition to my scenario, there is evidence that other users may have obtained a 'custom' status from something which is not QUOTE: "ROOTING", for example. a package disabler? That isn't anything that was used on my device, but merely another precedence, possibly, of there being more than one clear cut 'custom'="ROOTED" as far as Samsung treats ALL MFR warranty claims where HOW/WHY 'custom' status may completely matter - and if there is some question, their refusing to even inspect or investigate the specific reason a device is 'custom' maybe screwing thousands of legit mfr warranty claims > hence class action.
At first, I merely wanted my premium $800 device repaired/replaced... My device has exhibited dangerous behavior, after constant overheating may have warped component leads, shorted soldier traces, melted components, made lithium ion chemicals unstable. My device, upon charging with OEM supplied charger and cable, will completely become unresponsive to ANY user input (not even home/power/volume) - it continues to heat to such temps it cannot be handled without a glove or towel for very long - there's only one of three scenarios A) Chemicals become unstable causing a volatile chemical reaction (fire/explosion) B) Chemicals and/or components reach catastrophic state and simply fail permanently C) Battery dissipates 100%. I made sure to present my device in this state to a Verizon dealership so it was documented and an agent could affirm via an affidavit, should something awful happen. I was lucky that a regional Samsung Field Rep also overheard and was obligated to attempt to intervene as not doing so would have been negligent on his part - he's the one who tried for me but was told that any device that was 'custom' had to have been rooted... He hinted that he had knowledge that this was a bogus practice that Samsung policy dictates without any consideration for whether or not the 'custom' status was deliberate, nefarious, or even violated MFR Warranty terms....
@rbgCODE ^^^^^^^ Above^^^^^^^^
CVertigo1 said:
I don't know all the ins and outs of Knox Security, but I can add some experience pertaining to Custom Status. It is very possible to trip the Custom Status flag without tripping the Knox flag or being rooted. There are multiple package disablers available that can disable system packages, which can throw the Custom Status flag. The disablers are designed for NON-ROOTED devices, and if I recall correctly they are granted permission by Knox. Before root access was gained for the S7, a few people thought they accidentally figured out a way to root the S7 based on the phone showing Custom Status. Try using a package disabler on a NON-ROOTED S7 and disable a single package called sysscope, then suddenly your phone will say Custom Status. A lot of people got their hopes up that root had been found, only to have their hopes shattered when I proved it wrong.
As for hardware defects causing massive overheat and thermal shutdown, I have a Motorola Droid X that would overheat and shutdown if I was charging it in the car when it was hot outside. I'd even consider battery issues to be hardware related failures, such as the Note 7. There was enough media coverage as well as a total recall to prove it's possible. I'd also like to add that the Note 7 isn't the only phone to cause fires. There have been some iPhones and other Samsungs that have caught fire, but it was a much smaller scale compared to the Note 7.
Click to expand...
Click to collapse
Thanks for input... Exactly as we had thought - but would still appreciate any/all expert testimony LoL (actually, legal council has already suggested I begin search for expert witnesses... I'm sure they'll do their due dillegence as well but helps to do stuff yourself, too).
It's dumbfounding to me that I spent $800 cash up front on a device - was told quite literally by a regional Samsung Field rep to not so much as power on - words like 'potential bomb' and 'fire/property damage' used by the rep... He'd JUST returned from a debriefing on the Note 7 investigation findings. So, not only do I have an $800 bomb I was instructed to not even power on, but I continue to pay Verizon $120/mo for service.
Verizon already did a full investigation and examined very carefully - they found zero evidence of any modifications/unauthorized code which would violate MFR warranty claim, were able to repair corrupted software environment via Verizon Software Repair Tool. At least Verizon cares that I don't have a chemical explosion in my ear while I'm driving. Unfortunately, even after Verizon's repairing the Operating System and device has long since returned to "official' status, with Knox untripped and uncompromised, extreme prolonged temps have cause permanent compromise to hardware... This was the chicken before the egg bit, it began overheating before 'custom' status began and continues after back to 'official' - Samsung caring about me, class action? Not so much. Awfully smug in my humble opinion.
Appreciate any/all input - either for or against. I can handle the truth, Samsung cannot.
BTW, We'll know if a Samsung Legal Spy Troll is among us :cyclops:
I'd see if @Chainfire would give any input on the topic or point you in the right direction. I don't think there is anyone else out there that has more experience with Knox, Custom Status, and modifications. I don't know his background, but his Android knowledge is phenomenal, and from some of his posts it sounds like he has a very in depth knowledge of hardware as well.
I'd also like to add that from your post, I realize your device hasn't been modified via root or package disabler, but maybe the system is seeing something else as a modification. Chainfire might be able to mention what the system sees as modifications. I do recall when the S7 first came out, you had the ability to use Nova Launcher to change the scaling before it was implemented in the system settings. This was a non-root method that wasn't exactly a modification, but it would trip the DM-Verity flag for modifications, so you never know what the system might determine is a mod and throw the Custom Status flag.
CVertigo1 said:
I'd see if @Chainfire would give any input on the topic or point you in the right direction. I don't think there is anyone else out there that has more experience with Knox, Custom Status, and modifications. I don't know his background, but his Android knowledge is phenomenal, and from some of his posts it sounds like he has a very in depth knowledge of hardware as well.
I'd also like to add that from your post, I realize your device hasn't been modified via root or package disabler, but maybe the system is seeing something else as a modification. Chainfire might be able to mention what the system sees as modifications. I do recall when the S7 first came out, you had the ability to use Nova Launcher to change the scaling before it was implemented in the system settings. This was a non-root method that wasn't exactly a modification, but it would trip the DM-Verity flag for modifications, so you never know what the system might determine is a mod and throw the Custom Status flag.
Click to expand...
Click to collapse
I thank you, very much! This is the exact type of input/leads council is seeking.
Hopefully @Chainfire is willing to assist on whatever level... I know some people hear 'litigation' and want nothing to do with, others understand that sometimes huge corporations will screw consumers until checked - and are more than willing to help do that very important checking for the greater good. Yet others, whom possess background/credentials needed for expert witness testimony/affidavit, understand that should their assistance lead to probable cause of/justification to file litigation - very likely could be financial compensation (expert witnesses are in high demand - this is the community to find you, too ) Now, in all fairness, I cannot, at all, suggest that assisting will result in compensation - but, it could. The very least, you have power to share wisdom and hopefully hold parties accountable.
I'm still on fence about litigation... Honestly, I really just want what's fair - but the deeper Samsung gouges my time and money, it has become, to me (still semi-ignorant about specificities regarding Knox, 'custom', rooted.
I do wholeheartedly believe that the letter and spirit of consumer law (MFR Warranty) are very much in question of having been short changed, by Samsung, perhaps on THOUSANDS OF SIMILAR VALID WARRANTY CLAIMS. Denying an in warranty device claim, without even accepting for inspection or, at the very least, using in place, commonly used for tech support, remote diagnosis via Samsung+ App - is an absolute failure of due diligence.
I hope someone on this forum is willing to help. There are some very brilliant minds that lurk around here.
@CVertigo1
I'd also like to add that from your post, I realize your device hasn't been modified via root or package disabler, but maybe the system is seeing something else as a modification..... I do recall when the S7 first came out, you had the ability to use Nova Launcher to change the scaling before it was implemented in the system settings. This was a non-root method that wasn't exactly a modification, but it would trip the DM-Verity flag for modifications, so you never know what the system might determine is a mod and throw the Custom Status flag.........
Click to expand...
Click to collapse
This is the exact type of KNOWN issue, which sets a precedent of 'custom' status, which may well NOT violate the letter and spirit of consumer rights, as far as warranties... Thus dictate the necessity for Samsung to investigate exact reason for 'custom status' warranty claim - but they do not differentiate 'custom' status from "ROOT" AT ALL!
Now, still yet, if Nova launcher is flagging as custom status as which something that legitimately voids a mfr warranty (which is shifty and arguable, at best) - does Samsung and/or Android/Google Play store have protection and/or warnings in place to, at least, make user aware!? I carefully went through all previously installed apps and none disclosed ANY modifications - let alone, as Samsung has determined quote "ROOTED"!!! NO, not rooted.
On a single case, maybe seems blowing out of water - BUT, if talking about a high performance premium Galaxy device, which is known for overheating and failures, and thousands of users being denied rights to mfr warranty - entirely something else.
Also, a big deal is a federal courts ruling that Samsungs arbitration/class action opt-out notice is not binding. Failure to respond is not acceptance of warranty and terms of use stipulations, with opt-out gotcha's - which attempt to take away consumer's rights to join class action claims.
I had a verizon s7edge which I sent back for an insurance claim. The replacement from Assurion was also defective - the wifi did not work. Could not even get it to turn on let alone work. It would crash and randomly reboot. When it did reboot - it would sometimes display the unlocked logo and custom when booting. It would even say custom in the settings/about phone.
The phone was doing this right out of the box - was never rooted or flashed. I ended up sending that one back for a second replacement which has been flawless.
So, yes you can have an issue with your phone that is not flash/rooted related and it will still show "custom" when booting.
I've always found it kind of hard to pick "the next phone" to buy... especially since my interests seem to be orthogonal to what all the review sites focus on. This time around I found success by combining (1) the lineage os stats (what everyone else is having success with), and (2) the device wiki data (because I needed a special feature: dual sim slots).
There is one thing, though, that I think the device wiki is missing... and it is hinted at in this commit:
* https://github.com/LineageOS/lineage_wiki/commit/f489e78535360e09aaa7425d894e602e25e44760
Especially for one that does not follow modern trends, or who does not have a lot of time to weed out phones that are "popular but unofficial" (like the homtom) and research possibly-stale forum info concerning the bootloader (as I have bought several phones on such ground thinking they could be unlocked!); I recommend adding another enum field to the LOS device wiki to describe the current state of the bootloader.
Why? Not only would it save huge amounts of time for those searching out their next LOS phone, but it might also gain wider visibility into the "bootloader problem", subtly pressuring companies to produce favored unlockable phones, or at least not regress (as huawei has done).
I recommend a new enum field: bootloader_type
already_unlocked - The device ships from the factory unlocked. You might be able
to lock it, but why would you want to.
freely_unlockable - Unlockable without needing any sort of code, "phoning home",
or secret-sauce-software to unlock it. e.g. Nexus phones, oneplus phones
with_permission - Unlockable only with permission and interaction with a another
party, and that party is known to currently be issuing permission to anyone who
asks. e.g. motorola phones
jail_breakable - The device is intended to be locked up tight, but they failed.
Care must be taken as there is often a closing window of opportunity to use this
device before a firmware update removes its utility. Often shifts to not_permitted
(below) once the last known jail break is patched.
not_permitted - There may be an unlock mechanism, but it is generally infeasible
or secret. e.g. huawei
confusing - Phones with the same model number come with different unlockability,
or only special bootloader versions can be jailbroken, so extra care must be taken.
e.g. pixel phones