Related
" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Great work! With this base, can yout get something like CW to run?
I'm so waiting for him to come back and say April fools.
I'm gonna screw him up if this was an april fool
First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
Don't know alot about the bootloader, but what advantage does this have?
SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.
He said root with r/w access. Archangel won't do that, the file system is still protected.
pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.
Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.
After stupidly doing OTA update and getting SBK flashed on my tab I have been analyzing what how it happened. I figured I would put info here in hopes it might help someone else. Now this is basically my theories based on analysis of the bootloader code. I could be 150% wrong, Caveat emptor.
Useful resource was the Uboot git repository that has some Tegra 2 support:
git.denx.de/?p=u-boot.git;a=summary
Also Ac100 kernel tree gave some insight into fuse logic:
gitorious.org/ac100/kernel/trees/cd81507c9c1075b363f5af1222fa93deee09a13e/arch/arm/mach-tegra/include
Onto the boot loader itself. Even on the unlocked tablet (First thing I did is copied everything using nvflash) the bootloader has logic to burn the fuse settings from FOTA mode. There seem to be 3 modes:
1. Static Key hardcoded in the bootloader
2. Production key that is passed through some parameters area
3. Random key
Now if I am understanding the code right. If the last case is what is used then ultimate unlock does not seem likely as every unit would have its own key.
I am still hoping it is the case #2 that is usually used.
Another avenue of getting SBK I was thinking is getting an unlocked tab to get to fetch update but not let it install. If it is case #2 and key is shared by tablets this could be the way to get hands on it.
I spent some time looking into this a few months ago and came to more or less the same conclusion. My feeble attempt at throwing the bootloader into IDA didn't pan out, especially since I'm a tightass and was trying to trick the free version into letting me load it, and messing around in objdump got nowhere. There's a lot to be gathered from the strings and looking at the Android-side FOTA code though. It seems that one of the partitions (can't remember which) holds a structure used to send messages back to the bootloader, one of which can contain the SBK and other keys. However, some people managed to get their SBK burned by asking to be repartitioned in ODIN, so in that case either a random or predefined SBK must be used. I have my doubts that the FOTA mechanism is being used, and was likely left in for possible future use.
I am curious to see how options 1 & 3 are determined. One possibility is that the SBK may be hashed from the emmc's CID (a unique 128-bit key hardcoded into the onboard flash chip), as that's checked and printed early on in the serial output of the bootloader. (on the other hand, my GS2 does the same thing, it may just be force of habit for Sammy).
The SBK flash code in the bootloader appears to print the SBK to burn during the burning process. IF someone were to still have an unlocked tablet AND they were willing to lock it in the name of science, someone could capture the serial output during the process. One of four things will result: No useful output at all and the tab gets locked, an SBK is printed and it doesn't work on that tab, an SBK is printed and it works on that tab and no others, or an SBK is printed and it's valid for all tabs.
In all likelihood it is completely random. There are probably very few Tabs that come back to Sammy for service that validly need a complete reflash under warranty. In that case it would be most secure to lock the door and throw away the key, and just bite the bullet on the few boards that need to be trashed and replaced.
There seems to be a trigger file written to EFS partition with parameters of what to write to the fuse from a quick look at some strings.
On a separate note. I was thinking on how to tell which option Samsung chose. If the same version of boot loader in encrypted with the same key would it not result in the same encrypted partition? If so then collecting bootloader version with say first 32 bytes of encrypted partition from users should tell if same encryption key is used. Unless some sort of per machine is combined with SBK.
We know the encryption is AES, so it's symmetrical and therefore any keys won't be randomly salted. However, like you said it's likely that the encryption key includes the device serial number or something else that would keep partitions on identically keyed devices from matching. A quick test of this would be to compare bootloader partition dumps from two devices locked with the same SBK, i.e. two Transformers. What's important to realize is that the decryption of the bootloader is driven by firmware built into the Tegra2 that's identical for all chips, so what applies to one Tegra2 device applies to the rest.
I am wondering if there's a working temp root (or even perm root without bricking Android 6.0 OS) for this Verizon exclusive ASUS Zenpad z10, as I am now looking for a way to unlock the bootloader as most of unlock commands are intact in the bootloader itself - only "Allow OEM unlock" tab is missing, so I will have to extract the bootloader partition and system configuration partitions - the problem is root.
That way I can get started on putting TWRP after unlocking the bootloader.
Already tried temp root the manual way; running su in /data/local/tmp after giving it the correct permission. All I got was "1" in shell, basically along the line, "f*** you, I am not letting you run as root." Why temp root? I have to do it so I don't accidentally brick the tablet - all I want to do right now is to extract the vital partitions and examine every single of them to see if I can indeed get "Allow OEM Unlock" or some bootloader unlock approval commands so I can get ASUS ZenPad z10 unlocked. And there's absolutely NO ASUS update RAW file extractor tool to date.
Apparently it looks like ASUS and several other OEMs don't bother going the extra miles getting the bootloader locked down as tightly as Evil Moto, or worse, Samsung. They just simply remove "Allow OEM Unlock" tab and call it a day. (Beware, though, Qualcomm second stage bootloader varies so much among OEMs which is why I have to take a peek into the partition image and see what I can find.)
Although I'm of no help to you, I will be following this. I just picked up one of these today. There's simply not a lot of information out there.
Sent from my SM-N920V using XDA-Developers mobile app
Apparently, due to the way Android Marshmallow security system works, all I can do is wait (and probably trawl the forums, although I doubt it will happen unless I pull the kernel from the eMMC SSD which is technically a catch-22 situation, as I have to root before I can touch the kernel or even "Allow OEM Unlock" configuration file in some partition - a bit like chicken and egg paradox).
UNLESS there is a temporary root that works by abusing the Dirty Cow exploits, and allows me to pull the eMMC SSD partitions so I can look through the files contained within the pulled partitions.
Discovered that this tablet do have root detection system - it basically tattle to Verizon. Those bastards. Nevertheless, I would need to find a way to allow OEM unlocking (which I had gut feeling that it's there somewhere) without it getting all antsy.
The more I dig into it, the more I just want the bootloader itself to be unlocked. It never cease to amaze me how far Verizon will do anything to be so nosy.
Slightly off topic, but since you seem to be the only other person here who has this tablet... Have you attempted to figure out a simultaneous charge and data option? I've tried several different cables and adapters so far without much luck.
Sent from my SM-N920V using XDA-Developers mobile app
Good question, however I don't really have a computer with USB-C port, if you meant that (been considering doing a new computer build at some point which then I get better idea how this tablet function on USB-C doing general stuff via USB - it may be by the time this tablet is running CM 14.x, once we figure out how to unlock the bootloader, so it may be hard to say how it will function with stock ROM). On the other hand, regular USB is usually limited to 500 milliamps (1/4 that of bundled charger), so may not charge because of the current requirements that may have to be met within the power management firmware (meaning about 1 Amp - which many DIY PC motherboards now meet the minimum specifications).
However, the screen backlight consume the most juice so you may try turning off the screen after you have mounted the MTP drive (due to MTP security in Android - it will stay mounted after you plug it into computer and turn off the screen however), which then you may be able to charge it. It will take a while as there's a huge battery inside (7.8 Amp hour rating). You would have better luck with a computer that conforms to USB Power Delivery specifications (USB 3.x already support that - USB 3.x ports are usually blue, BTW, so it's kind of hard to miss).
Finally extracted the files from ASUS' Verizon ROM image - ZArchiver Pro apparently can read ASUS' RAW image file, much to my delight. Now, I will have to figure out how to treat the Qualcomm second-stage bootloader (aboot.img) and few other partition images as a disk drive so I can figure out how to enable OEM unlock so I can get this thing unlocked (and I will disassemble the Linux kernel - boot.img - and recovery toolkit - recovery.img - so I can get ball rolling).
Tried to unpack the boot.img and recovery.img - the boot unpacker failed with "Android boot magic not found". Oh well, I will try to keep at it.
Alright, I think it's because the kernel is compiled in ARM64 assembly codes (thus not really standard as far as most Linux kernel boot.img unpackers are concerned), so now I will try one that can and will touch 64-bit kernel image. Then keep on probing the entire recovery and boot images for potential clues to the OEM unlock configuration (and as well as system.img - one problem is, Linux refuse to touch the system.img even though it is evidently the EXT4 FS SSD image).
Anyone who know of decent multi-faceted disk image extractor (the ones that can touch the non-standard disk image, including boot.img and recovery.img which doesn't have the standard "ANDROID!" magic), let me know. I have been googling anywhere, and it's difficult to pull the vital files which I can look for important files. System image, however, may have to be analyzed for type of fuse file system (if it's not sparse file system, then it's definitely an odd SSD image).
Another ZenPad owner checking in. I had to go to asus's site to say this thing even is. The model number P00l is absolutely worthless.
Anyways I've ordered a laptop with native USB 3.0 so will poke around where I don't belong soon.
I absolutely hate this UI, who is to blame? Asus? Verizon?
Verizon. They usually make the call in firmware development (Can you say who locked the bootloader?) and yeah, they're famous for horrible stock firmware. Hence, I am figuring out how to unlock the bootloader just so we can get rid of garbage on the tablet. ZenUI is on ASUS though.
Nice hardware, bad software. That's kind of a shame. It will hurt even less when we get CyanogenMod 14.x operating system on it.
EDITED: the model number is zt500kl, not superfluous "P00l" - I had to figure it out, and GSM Arena had the model number (and bootloader apparently confirmed that).
Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).
Asus ZenPad ZT500KL
I just purchased this tablet yesterday. If you need me to test anything feel free to pm me.....
Thanks for working on this, if I can be of any help. do not hesitate to ask.
Dr. Mario said:
Did a bit researching in how the "Enable OEM Unlock" tab in other devices' Developer Option works; the toggle goes into persistent data block (hitting home in PersistentDataBlockService.java file), thus going into factory device configuration file in the syscfg partition (mmcblk0p28) - however, I will need to successfully extract the system.img in the ASUS Verizon OTA, or if we can successfully root this thing, I can go ahead and pull some apps and files and see how Allow OEM Unlock can be accomplished.
Correction: it's actually config (mmcblk0p13) as the build.prop said ro.frp.pst points to /dev/block/bootdevice/by-name/config - this is where it will get tricky; the config.img file is actually blank - it's on the physical soft efuse partition on the eMMC SSD itself, which there will be some legit data. Which is essentially untouchable until we get shell root of some kind to extract it. After I get to it, all I have to do is to find out the magic value to "blow" the last value sector in soft efuse partition to allow OEM unlock (note - soft efuse is just that, you can relock the bootloader when you write blank partition image to reset the efuse values contained herein, so beware the official OTA update image package).
Click to expand...
Click to collapse
Due to a potential brick risk due to entering the wrong magic value, I'd rather that we have temporary root or shell root first so we can pull the soft efuse partition and some setting files from ASUS settings.apk / systemui.apk to figure out the FRP values just so we don't accidentally lock ourselves out or worse.
Once we find out what it is, we can go ahead and test that (kind of wish I have extra money to get a sacrificial tablet to take a jab at the bootloader, as Verizon love to make it risky).
Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.
Dr. Mario said:
Oh, and BTW, this tablet also have several hardware disabled by Verizon, like the fingerprint scanner (home button). All the reasons to get CyanogenMod, crDroid and any of the favorite CyanogenMod derivatives on it.
Click to expand...
Click to collapse
I'm within my 14 day return period ...., send me a pm
Sent from my iPhone using Tapatalk
Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).
Dr. Mario said:
Give me a bit time and I will figure out what to poke in config partition and we can go from thereon. Some one-click root (like KingRoot) are questionable so it's hard to know as of yet, due to secure boot which will prevent the tablet from booting all the way to password request lockscreen if it notice something (and there's a root detection app inside /system/priv-app directory - even though Verizon doesn't care about me, whether I hacked it or not, given my history of hacking several Qualcomm-based smartphones, especially RAZR M, even though it may probably be because I paid all my bills on time).
Click to expand...
Click to collapse
Sounds good. Didn't even know the tablet had a fingerprint reader ( home button)
Sent from my iPhone using Tapatalk
Models: SM-G930_, SM-G935_ (Flat & Edge, all Snapdragon variants, NOT Exynos)
Developer thread only!
Work in Progress!
DONT flash anything on your phone unless you either a)Dont care of the result or b)Know what you're doing! I will take NO RESPONSIBILITY for you breaking your phone! Know the risks!
Research & Development Thread for Unlocking S7 bootloader
What is this thread?
This is a thread with all information (research) I can find regarding the locked bootloader for the S7 Snapdragon (Exynos has been unlocked so this thread will NOT cover that.) There are a lot of great seasoned Devs out there, but it seems all have given up, or remained in the dark. Flagships like the S7 we all bought because they're amazing phones, but it appears the future is locked bootloaders; if you're here then you're interested in custom ROMs. If we give up and can't 'crack this', then I'm afraid amazing phones like this will never get custom ROMs, ie, that will be a thing of the past.
In other words, there doesn't appear to be any development anymore on trying to unlock the bootloader. Hope is lost... or is it? Therefore, we need new talent. We need a new generation of developers walking into the game knowing that what they're trying to do is almost impossible. I'm hoping this thread will quickly bring any developer up to speed so we can get some "unlocking Dev rookies". We are recruiting! Come here and ask questions regarding this so hopefully you can figure this out!
I'm going to update from time to time the first few posts with critical info, links to info, etc. My goal with this thread is to put all of the great information from the community in one place. I don't way people to have to search this entire thread, rather get the info quick so they can begin developing quick, so we can get an unlocked bootloader, QUICK!
Remember, there were previous locked bootloaders, but many of them have been cracked so let's take away the 'impossibility factor'!
Who is this thread for?
Anyone that wants to quickly be brought up to speed on the S7 locked bootload status, all the hurdles, etc
Developers that want to be part of the future of locked bootloaders and something great!
Who can post and what posts are allowed?
Anyone with PRODUCTIVE comments towards unlocking the bootloader or efforts already completed (regarding of fail or success)
Developers working on this initiative
Developers with questions for other developers regarding this
Wanna-be developers with questions (There is no shame, and you never know if YOU just might be the rookie dev we're looking for to unlock this! If you're willing to try something to potentially brick your device, then you can play here Or maybe you might throw out an idea that might spark an idea with someone else that leads to an unlock.)
Links to things that have been attempted
Information you think people should know regarding this, that's not already listed. Or information you think should be in the original post so people can easily see it. (I don't want great info hidden deep in the thread, rather on the first page)
Keep me honest! If I post nonsense or inaccurate information, WE NEED you to correct me! Last thing I want to do is steer anyone in the wrong direction!
What NOT to post:
"+1"
"Thanks"
Petitions
Bounties
ANYTHING NEGATIVE! Negative Nancy, PLEASE go away!!
Etc. In other words, DONT waste thread space with nonsense. (Don't let that comment confuse you however with the 'very welcoming' questions from developers; This SHOULD be a collaborative thread. Productive input certainly welcome.) The idea is to QUICKLY allow someone to read this and get ALL the info to start trying to crack this. Going through pages and pages of irrelevant or useless comments will only make the goal more difficult, or prevent our new rookies from coming up to speed and trying to unlock this bootloader.
Who am I and what am I trying to get out of this?
I'm an application engineer and developer that bought an S7 from Tmobile and found out the hard way it had no way to get a custom rom, despite TMobiles past of typically allowing this. I'm frustrated like you all & want my phone unlocked, pure and simple! Besides, this is a community, and what better of an agenda than to try and conquer what others have said, "that's impossible"!
Other Notes:
MANY, many thanks to all the contributors out there!!! I got most of this information from other forums on XDA!
Following few posts will have resources and additional links. This thread is new so I'll find a good organization method in time.
PLEASE subscribe if you are (or want to be) a contributing developer, or have anything to add - or if you can answer others questions. I think a lot of this knowledge will expand to other devices, and not just Samsung, but future devices as well.
Please let me know of anything to fix with this thread, like tags, thread description, etc.
Make sure to send the link to this thread to people you think might be interested (but don't spam them!) Or post a link to this thread in other seemingly dead threads on unlocking this bootloader. Alone it just may be impossible to do this...but as a community, sharing all of our knowledge...we can do this!
Still not motivated to do this? Try this: https://www.google.com/webhp?source...=1&espv=2&ie=UTF-8#q=s7+bootloader+bounties&*
If you found this thread useful hit "Thanks"!
.
Information
Quick facts
Exynos bootloader is unlockable, which is why we won't talk about that here!
S7 Variants https://en.wikipedia.org/wiki/Samsung_Galaxy_S7#Variants
US & China use a Snapdragon processor, all other locations use the Exynos
Knox counter: will void warranty (if you still have one!) Most could careless if there's a remote possibility of unlocking the bootloader. Methods or tampering could possibly trip this counter.
Mostly when people say a phone is "locked", they mean locked to a CARRIER. That is NOT what we're talking about here - we're talking about a locked bootloader which allows you to install a custom ROM.
FRP: (Factory Reset Protection) Requires username/pass after factory resetting http://www.androidcentral.com/factory-reset-protection-what-you-need-know Reset: https://forum.xda-developers.com/galaxy-s7/how-to/samsung-factory-reset-protection-gmail-t3446788
Bootloader version: PhoneSettings->AboutPhone->Baseband version: 5th from last number.
Ex: Bbaseband: G935UUES4AQC1 = Bootloader version 4 @thescorpion420 (Tmobile & U = ver4, China=ver2)
Locked bootloader
Easy way to tell you bootloader locked status(?)
What is the bootloader? Part of the Android boot process. See all about it here: http://newandroidbook.com/
Why can't we currently unlock the bootloader? There is something called the chain of trust, whereby 'everything' from when the phone first turns on, through each 'piece' it verifies the contents of the flash is legit and from a listed trusted source (either Samsung or carrier). What controls this is the current, existing software/FW on your phone. So if we took what's there and removed these checks, we currently don't have a way to write this to your phone, since "we" aren't from the list of trusted sources. How do they enforce this? The images need to be digitally signed.
What does it mean to digitally sign a file (or image, FW in our case)? There is a private key and public key. Samsung and/or Carrier have the private key, your phone has the public key. Author writes a new SW package, then uses a tool to get a checksum. The checksum gets encrypted with the private key. The encrypted checksum gets appended to the SW package. Using OTA (over the air deployment) or ODIN, we push the package to the phone. The phone decrypts the appended encrypted checksum using its public key, does a checksum on the remaining package, and makes sure they both match. Now you can see why we can't fake this! Only way would be to find an exploit or get the private key so we can sign these ourselves!
Links (relevant threads)
Potential way to unlock bootloader? https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220
ROOT DISCUSSION / TEKXv2 Dev Thread Extension SM-G935T - Dev Section / Discoveries https://forum.xda-developers.com/tmobile-s7-edge/how-to/root-discussion-future-sticky-root-t3327399
G935AVPT cross bootloader, flash Chinese Version , support ALL lte band,Knox stil 0!! https://forum.xda-developers.com/ve...ross-bootloader-flash-chinese-t3432190/page15 or
https://forum.xda-developers.com/att-s7-edge/how-to/g935avpt-cross-bootloader-flash-chinese-t3435043
High-level explanation on whats going on with this locked bootloader: https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
Resources
Android Internals: A Confectioner's Cookbook http://newandroidbook.com/
Many thanks to Jonathan Levin for releasing that to the public for free, but please support his work via the other listed means. Also Reverse Engineering Aboot: http://newandroidbook.com/Articles/aboot.html
Samsung Source (Tmobile) http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-G930T
Bootloaders, Encryption, Signing http://www.androidpolice.com/2011/0...ncryption-signing-and-locking-let-me-explain/
LOCK download mode (opposite but might have useful info) https://ge0n0sis.github.io/posts/20...-mode-using-an-undocumented-feature-of-aboot/
Tools
Phone Apps
Root Browser app (doesnt need root) access all files on phone (across ALL partitions?) https://play.google.com/store/apps/details?id=com.jrummy.root.browserfree&hl=en
Phone INFO (get info about phone) https://play.google.com/store/apps/details?id=org.vndnguyen.phoneinfo&hl=en
Other
S7 USB driver http://samsungodin.com/SamsungUSBDriver/USB_Drivers_1.5.27.0.rar
ADB (Install Android SDK)
DD: https://forum.xda-developers.com/showthread.php?t=1153991 (can be "disk destroyer" if used stupidly)
Sandbox: Possible to make a virtual S7 to test on? (including ALL partitions such as aboot, etc)
Ubunto VM: How to build a Linux VM for Dev & testing on this: http://imicrov.com/small-tech/android-development/android-development-with-ubuntu-in-virtualbox VMWare: http://www.vmware.com/products/player/playerpro-evaluation.html Ubunto image: http://www.osboxes.org/ubuntu/
Flashing
Info https://code.tutsplus.com/articles/an-introduction-to-android-firmware--cms-26791
Firmware (Android ROM) is stored in a writable form of memory called NAND flash memory, the same type of memory that is used in storage devices, such as USB sticks and SD cards
Bootloader more info
Ways to Flash
ODIN - Odin3_v3.12_PrinceComsy (ODIN is Samsungs replacement of Fastboot) https://www.androidfilehost.com/?fid=24591023225177749 or http://samsungodin.com/ (?)
ODIN is the only possible way (that we know of). You push a download from PC to phone, it runs checksum and signature verification, if it doesnt match what it expects, it never writes from memory to phone and throws away image. This intense security likely due to Samsung pay.
ADB - No standard way to do this, but maybe something creative might work...
Heimdall https://forum.xda-developers.com/galaxy-s7/how-to/guide-heimdall-to-flash-firmware-t3452904 (still work? couple years since updated) Sourcecode: https://github.com/Benjamin-Dobell/Heimdall
USB jig: https://forum.xda-developers.com/galaxy-s7/accessories/usb-jig-t3347793/page4 eBay: http://www.ebay.com/sch/i.html?_odk....H0.Xusb+jig+s7.TRS0&_nkw=usb+jig+s7&_sacat=0 Or make your own: http://www.instructables.com/id/USB-JIG-to-give-life-to-your-Bricked-mobile/
SD card: https://forum.xda-developers.com/showpost.php?p=69235306&postcount=38
Z3X Box: eBay: http://www.ebay.com/itm/2016-Z3X-BO...I-Unlock-Flash-Tool-C3300KCable-/291810363162
Safestrap(?)
Flash Errors & What they mean:
Failed aboot Fused 2> binary 1 - bootloader error: ?
SECURE CHECK FAIL: No Bueno! You're trying to flash something that's not digitally signed correctly
Firmware/Files:
AP (Application Processor or PDA or Android Partition): Android. System partition with recovery, etc. Recovery, kernel and ROM will be in this file. This is the only FW that is open source.
Typical contents of update.zip:
android-info.txt: Text file specifying the prerequisites of the build, such as the version numbers of the bootloader and the radio firmware that the build needs
boot.img: Binary file that contains both a Linux kernel and a ramdisk in the form of a GZIP archive. The kernel is a boot executable zImage that can be used by the bootloader. The ramdisk, on the other hand, is a read-only filesystem that is mounted by the kernel during the boot process. It contains the well known init process, the first process started by any Linux-based operating system. It also contains various daemons such as adbd and healthd, which are started by the init process More info
recovery.img: Very similar to boot.img. It has a boot executable kernel file the bootloader can use and a ramdisk. Consequently, the recovery image too can be used to start an Android device. When it is used, instead of Android, a very limited operating system is started that allows the user to perform administrative operations, such as resetting the device's user data, installing new firmware, and creating backups.
system.img: Partition image thats mounted on the empty system directory from boot.img. Contains the Android OS binaries as well as system apps, fonts, framework JAR files, libraries, media codecs, bloatware, etc. (Most used for flashing a custom ROM)
userdata.img: Partition image that will be mounted on the empty data directory from boot.img. Custom ROMs typically come with this image as blank so that it resets the contents of the data directory.
BL (Bootloader): Proprietary code that is responsible for starting the Android operating system when an Android device is powered on. Typically, it checks if the operating system it is starting is authentic as well. (Checks if the boot partition has been signed using a unique OEM key, which belongs to the device manufacturer, & is private.) Ie, Locked bootloader. Fastboot, IF allowed on a device, disables this check.
CP (Core Processor): Modem. This proprietary Radio firmware is another operating system on an independent processor called a baseband processor, independent of Android. This adds the cellular radio capabilities of the device like 3g & LTE. Qualcomm, etc develop this FW.
CSC (Consumer Software Customization): It is specific to geographical region and carriers. It contains the software packages specific to that region, carrier branding and APN setting. Eg Wi-Fi Calling. Flashing will lose your data (factory reset). Variations of CSC may retain data.
PIT files (Partition Information Tables) (Danger! Dont flash these unless you know what youre doing!)
Different variants of the S7 have different partition sizes; same phone/same carrier with different storage size have different PIT. One issues people were having flashing images for other variants is that the partition would fill up. A workaround would be to reformat with a correct PIT file and check "repartition" in ODIN. More info via @[Ramad] https://forum.xda-developers.com/sho...d.php?t=999097
"Get PIT for mapping" error while flashing (indicates you need a PIT file to flash what youre trying to flash)
-Extract current PIT file from phone: http://www.**********.com/how-to-ext...alaxy-devices/ (need root)
Unlock Methods
High-Level Ways to Unlock:
Get leaked private key so we can sign our own images
Find exploits
Dev bootloader gets leaked
?
What does work:
Can flash digitally signed images
Can write to partitions with engineering kernel
Ideas:
Use engineering kernel that has root to somehow modify bootloader partition to remove digital signature checks - at level/entry point can or should this be done? (ie, where in boot process at a minimum do we need to remove the check?)
Thread on installing LineageOS on bootloader locked Note 3: (this possible on our device?) https://forum.xda-developers.com/redmi-note-3/how-to/kate-guide-install-lineage-os-locked-t3546154
Thread on Recovery for locked bootloaders by @hsbadr : (work on our device?) https://forum.xda-developers.com/an...g/tool-multirom-recovery-replacement-t3102395
...Reading sdd10 line by line. I did find an entry "Device is unlocked! Skipping verification...". I'm starting to think we need to look into recovery-side exploits" @Flippy125 https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220/page2
Back rev bootloader version (or other partition) to reintroduce security exploits (dont believe you can backrev though, easily) dd Chinese version? (Hard brick?) https://forum.xda-developers.com/showpost.php?p=70977356&postcount=39 @thescorpion420
Exploits: (known existing)
SD card most vulnerable?
Samsung Source available I believe (in its entirety though? See Resources links above) Perhaps viewing this may reveal exploits
?
Attempted Methods:
OEM Unlock in Android Settings menu: YES! We tried that!
Flashed Chinese images via ODIN. People used PIT (Partition Information Table) files and checked reformat partitions in ODIN and still failed.
Result: Errors during flash process, won't take, "Thread Failed" error
Chinese bootloader is v2 where all US models are v4(? How to determine?)
Convert Chinese ROM to another variant: https://forum.xda-developers.com/android/general/guide-how-to-convert-chinese-roms-based-t3577469
Use CROM app (Chinese phones have this app to unlock their phones):
Result: This app communicates to Samsung servers and ends up writing a flag (kiwibird?) to STEADY partition. US phones dont have this partition so this currently wont work.
Dirty cow exploit - (didnt work) indicated by @Binary100100
Android OS & Everything about it
Engboot kernel write protection seems to be off, so it appears you can use dd to write to normally write protected partitions such as the bootloaders (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully "dd" a backed up aboot (secondary bootloader) partition and also write to the modem partition and have it stick @qwewqa
MBN files: Multi boot binary firmware. Mostly used with Samsung, binary data for storing the device's memory partitions, such as the resources and power manager, secondary boot loader, AP boot loader, and trust zone. Can't just edit, need source then compiling creates mbn files? Info: https://www.quora.com/What-is-mbn-file-format-where-is-it-used https://forum.xda-developers.com/showpost.php?p=29787988&postcount=31
Create MBN: https://forum.xda-developers.com/showpost.php?p=28145975&postcount=198 Moreinfo: https://forum.xda-developers.com/showpost.php?p=28149932&postcount=212
Cook custom ROM: https://forum.xda-developers.com/showthread.php?t=901417
Extract mbn files using unyaffsmbn: https://forum.xda-developers.com/showpost.php?p=6303911&postcount=827
How to get existing versions, eg, bootloader version? (Many versions are in Phone->Settings->About device)
Partitions... needed to be modified(?) @qwewqa https://forum.xda-developers.com/tmobile-s7-edge/help/potential-to-unlock-bootloader-t3544220
- rpm (Resource and Power Manager / Primary Bootloader) located at /dev/block/sdd1 (/dev/block/bootdevice/by-name/rpm)
- aboot (AP Bootloader / Secondary Bootloader) located at /dev/block/sdd10 (/dev/block/bootdevice/by-name/aboot)
- xbl (Extended Bootloader) located at /dev/block/sdb1 (/dev/block/bootdevice/by-name/xbl)
- ? located at /dev/block/sdc1
- Sdd1 is the primary bootloader
Boot Process @qwewqa
RPM = Resource and Power Manager = Primary Bootloader
ABoot = AP Bootloader = Secondary Bootloader
I believe the boot process is "RPM > ABoot > boot.img (Main OS)", so both the rpm and aboot file would be needed
Partitions (Correct? via @silentwind827)
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://source.android.com/devices/bootloader/partitions-images
http://davinci-michelangelo-os.com/2017/01/22/edit-init-rc-android/
ls -l /dev/block/bootdevice/by-name/
cat /proc/partitions
/dev/block/sda1 => modemst1
/dev/block/sda2 => modemst2
/dev/block/sda3 => fsc
/dev/block/sda4 => ssd
/dev/block/sda5 => persist
/dev/block/sda6 => efs
/dev/block/sda7 => param
/dev/block/sda8 => misc
/dev/block/sda9 => keystore
/dev/block/sda10 => devcfg
/dev/block/sda11 => frp
/dev/block/sda12 => bota
/dev/block/sda13 => fota
/dev/block/sda14 => persistent [edited]
/dev/block/sda15 => apnhlos
/dev/block/sda16 => modem
/dev/block/sda17 => boot (Kernel, RAMdisk, & boot images get flashed here see link above for details)
/dev/block/sda18 => recovery
/dev/block/sda19 => persdata
/dev/block/sda20 => system
/dev/block/sda21 => cache
/dev/block/sda22 => userdata
/dev/block/sdb1 => xbl
/dev/block/sdd1 => rpm
/dev/block/sdd2 => tz
/dev/block/sdd3 => hyp
/dev/block/sdd4 => fsg
/dev/block/sdd5 => sec
/dev/block/sdd6 => pmic
/dev/block/sdd7 => dsp
/dev/block/sdd8 => dip
/dev/block/sdd9 => mdtp
/dev/block/sdd10 => aboot
/dev/block/sdd11 => devinfo
/dev/block/sdd12 => bluetooth
/dev/block/sdd13 => lksecapp
/dev/block/sdd14 => keymaster
/dev/block/sdd15 => cmnlib
/dev/block/sdd16 => cmnlib64
/dev/block/sdd17 => apdp
/dev/block/sdd18 => msadp
/dev/block/sdd19 => dpo
/dev/block/sdd20 => ddr
/dev/block/sdd21 => pad
Restore Stock Methods
(Since we need a way to fix a bricked phone while we're trying to break it!)
Hard bricks likely not restorable though?)
Note: Not all of these methods will work, depending on how bad you bricked your phone.
https://www.androidsage.com/2016/03/...ware-download/
How to Fix a Bootloop: Turn off your device and reboot into recovery mode by press and holding Power + Volume down + Home keys for a few seconds. From the Recovery, select Wipe Data / Factory Reset. Confirm the action and reboot once done. Your device should now boot up.
Samsung Kies & Samsung Smart Switch https://forum.xda-developers.com/galaxy-s7/how-to/guide-revert-to-stock-anytime-kies-t3396314
Stock Files
Stock Files Collection https://forum.xda-developers.com/galaxy-s7/how-to/s7-s7e-stock-rom-bootloader-modem-t3383963
[Collection] Firmware/ROM Full, PIT Files https://forum.xda-developers.com/galaxy-s7/how-to/collection-firmware-rom-pit-files-t3326707
Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
[ROM][TMOBILE][S7_SM-G930T][Oreo Rooted]
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (Works on latest Android with root) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
Stock ROM Engineering kernel modified, with root (NOT installed traditionally via recovery like TWRP) Ex: https://forum.xda-developers.com/tmobile-s7-edge/development/rom-t3572739 by @jrkruse or https://forum.xda-developers.com/tm...ekx-dev-deodex-systemui-3minit-multi-t3411776 by @TEKHD
xposed not available yet for nougat as of 4/1/2017
kevin712467 said:
Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (This still work?) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
xposed not available yet for nougat as of 4/1/2017
Click to expand...
Click to collapse
Not on the newer versions of Android unless rooted, then it does.
Does anyone know if the phone boots differently when using a)the SD card boot & b)USB jig? Or z3x box? If so, how? (I'm guessing the jig boots the same as button pressing into download mode, but wanted to leave no leaf unturned!) Knowing this might open some doors of vulnerability if it boots differently. All the reading I did about this, I haven't read about anyone trying to flash an image via either of these methods. (I'm assuming & hoping this is even possible & you can actually boot off the SD card, if not at least install via SD) Testers?! (Reference "Flashing -> Ways to Flash" above for details, links.)
can try on your phone 7 edge
kevin712467 said:
Alternatives to unlocked bootloader
A Quick and Simple Summary list of things to get by until we get custom roms:
Use Engineering kernel to get root https://forum.xda-developers.com/tm...eres-how-rooted-nougat-s7-edge-g935t-t3567502 (SOME people complain of lag with the engineering kernel)
Remove bloatware:
Debloater by @gatesjunior (Works on latest Android with root) https://forum.xda-developers.com/android/software/debloater-remove-carrier-bloat-t2998294
Other apps: Titanium Backup, Package Disabler Pro, Root Package Disabler
Freeze these apps: https://forum.xda-developers.com/galaxy-s7/how-to/touchwiz-bloatware-save-to-remove-list-t3330241
Stock ROM Engineering kernel modified, with root (NOT installed traditionally via recovery like TWRP) Ex: https://forum.xda-developers.com/tmobile-s7-edge/development/rom-t3572739 by @jrkruse or https://forum.xda-developers.com/tm...ekx-dev-deodex-systemui-3minit-multi-t3411776 by @TEKHD
xposed not available yet for nougat as of 4/1/2017
Click to expand...
Click to collapse
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.
kenshin6106 said:
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.
Click to expand...
Click to collapse
The 935f bootloader is for exynos, you want to flash the 9350 bootloader. Odds are if you succeeded in flashing the 935f bootloader you'd have a nice shiny paperweight.
kenshin6106 said:
well ive been reading the BL.mdf file and how ive done it if you delete the mdf extension and etract it as a tar file youll get three files with encryption, some of it is readable i'm studying the code and looking for loop holes. however i have tried flashing the G935F BL file on my G935V and it gives me an device ID not supported error so if we can somehow implant the US models device ID to the G935F BL file we should have an unlocked bootloader. it's just a theory but i believe this would be a great start for us models of the s7 edge.
Click to expand...
Click to collapse
Where are you finding a "BL.mdf" file? I'm looking at stock images and see mostly mbn, bin, and img files. Is this an extraction of one of these files, images? Not sure this will help but here they talk about "brushing" (flashing) 'pick and choose' images making a compilation for a full flash (like pick US modem, with chinese bl, etc) & the Chinese are successful using US "pieces"/images despite having a different phone variant https://forum.xda-developers.com/ve...g935v-cross-bootloader-flash-chinese-t3432190 Another possible way could be the opposite of what you're trying: implant the international device ID on our phone so the image can flash without your error. (via engineering kernel possible to change this value, wherever it sits?)
Also, another thought: I wonder if there's a way to modify the PC ODIN tool (or Heimdall since that source is easily available) to add functions to talk to "hidden functions" on ODIN (on the phone) to unlock it that way. Or modify it to turn it more into an interactive console so we can navigate and investigate the phone's ODIN program. Does anyone know if the ODIN source for the phone side has been leaked? If not, any intelligent folks out there know how to 'reveal' all methods so we can go through it and maybe find exploits? (This been done already?)
One more thing: Those thinking the S8 is nearly out now so let's give up... Well, can anyone predict the future like I can?!! I'm SURE it will be locked as well. I wouldn't be surprised however if any exploit we can find for the S7 will be relevant on the S8!
Thanks for the efforts kenshin6106 ! And all the viewers of this thread make sure to hit the "Thanks" button on the bottom right of the developers posts to show your support. Remember, most think this is a dead subject, let's change that mentality!!
Can anyone please indicate what images or partitions are allowed to be downgraded, version-wise (if any)? I'm reading conflicting information - or its hard to tell if the bl rejected it due to a fundamental error or because it will not allow down-reving, whereby it would be possible had an acceptable image been used. eg, I read the bootloader cannot go from ver4 (US) to ver2 (Chinese). I'm not sure what's accurate. And Does ODIN/bootloader allow you to go from Nougat to Marshmellow? Knowing this will help with our unlocking methods...
Any instructions on how to flash g930p to u firmware I get errors
Bump.
I have a rooted SM-G930v using the engineering kernel, but I find the limitations of having a locked bootloader hyper-frustrating. In fact, I started researching which non-samsung android phone will be my next. (Looking at the Huawei P10/P11). I've been trying to use Magisk, TWRP, and a few other tools and have come to the realization that none of these are possible with a locked bootloader. Why is it that the Chinese variants have unlocked bootloaders? Samsung surely didn't make the decision to lock down their devices. It must be the US carriers that insist on locking down their devices and systems so that people can't modify certain apps, systems, and roms. Like bloatware for example. We just can't have nice things.
I wish I had more time to work on this, but I am not very experienced and I would almost rather get a similar device that is easier to root. I will however follow this thread and contribute what I can.
Chiller252 said:
I have a rooted SM-G930v using the engineering kernel, but I find the limitations of having a locked bootloader hyper-frustrating. In fact, I started researching which non-samsung android phone will be my next. (Looking at the Huawei P10/P11). I've been trying to use Magisk, TWRP, and a few other tools and have come to the realization that none of these are possible with a locked bootloader. Why is it that the Chinese variants have unlocked bootloaders? Samsung surely didn't make the decision to lock down their devices. It must be the US carriers that insist on locking down their devices and systems so that people can't modify certain apps, systems, and roms. Like bloatware for example. We just can't have nice things.
I wish I had more time to work on this, but I am not very experienced and I would almost rather get a similar device that is easier to root. I will however follow this thread and contribute what I can.
Click to expand...
Click to collapse
Check out this thread - https://forum.xda-developers.com/s7...heoretical-variant-bootloader-unlock-t3627286
We need testers!!
Hi,
I do have some MK903V TV Sticks that came with Android 4.4.2 and some with Android 7.1.
I thought I could potentially just clone the complete flash from one device to another using AndroidTool v2.3, but that failed.
I used "ExportImage" from "Advanced Function" to export the flash from 0 to 0x00E90000. I then selected the exported file and flashed it to Address 0x00000000 and name "system" using the "Download Image" tab.
The AndroidTool said it uploaded the file and verified okay. But after that I re-exported few blocks from 0x0 and found that the flash was not overwritten. The device did not boot (no HDMI signal).
I re-exported the system partition and found that it wrote the full backup into the system partition instead.
So basically the Tool used the "name" column and completely ignored the "address" column?
Is there a way to just write the complete flash using AndroidTool v2.3 ignoring partitions? I basically just want to mirror a device to another.
Okay, so I guess I understood that "LOADER" is actually aware of all partitions on the device and also their use/format. The "Address" column seems to be ignored completely. I guess this is only relevant for "MASK ROM" mode devices?
I found out by trying to write to "parameter" partition, hoping it would write to 0x00. But instead it wrote into the first partition at 0x08 and properly wrote the header in front of it with the size of the written data.
So, I now know how to properly extract the "parameter" image from another device and I assume all other partitions can be simply dumped and written without any magic happening to them? But I need to write them partition by partition?
For my understanding... The LOADER mode / the green "Loader" row in AndroidTool is something that is not on the flash, right? But it obviously reads the flash and its partitions.
If I'm right, I cannot brick the device as long as I don't flash a different "Loader" (which I don't have anyways as I cannot extract it from another device).
But: When I mess up the "parameter", will LOADER mode still boot fine and allow me to rewrite "parameter"?
Is "Loader" always booting "uboot" next, which then decides on booting into "kernel" or "recovery" if "R" is pressed?
Okay, I have so many questions and I can't really find any documentation :/
So at least I'll continue my self conversation here.
The bootloader of the RK3288 - and I'm still not sure what exactly it is - has two modes, LOADER and MASKROM.
I think in LOADER mode it is aware of partitions and makes sure users can only flash data to specific partitions. However, you can also update the partitions (and other stuff?) by writing to "parameter", which is part of the first few blocks of the flash.
In MASKROM mode it is not aware of any contents of the flash and you can basically write over the complete flash. In this mode the AndroidTool will actually use the Address column to flash data (I think).
I'm not exactly sure what triggers MASKROM mode but I guess the bootloader boots MASKROM mode if it cannot find "valid" data on the flash.
For example
erases the Flash and IDB, which forces the device from LOADER into MASKROM mode.
I also found lots of instructions that tell you to short two pins on the NAND Flash chip of the device to trigger MASKROM mode. None of these instructions tell you why you do it and how it works, but I guess it just disables the Flash so the bootloader reads back all zeroes or anything like that?
I also cannot find any information what IDB is, what it stands for and where it is stored, but it seems to play an important role here :/
There are multiple Versions of the "bootloader". e.g. https://github.com/neo-technologies/rockchip-bootloader / https://forum.xda-developers.com/t/rk-bl-rockchip-bootloader-collection.3739510/ lists RK3288Loader_uboot_Apr182014_155036.bin, RK3288Loader_uboot_Apr212014_134842.bin, RK3288Loader_uboot_V2.17.02.bin, RK3288Loader(L)_V2.17.bin, RK32xxLoader(L)_uboot_V2.15_replace_ddr.bin
They obviously do some things differently, but I'm not sure if this is relevant for "normal" operation of the device or just if you need to do special things. e.g.
Running Android or Linux from an SD card on a RK3288 device - An easy way to dual boo
If you are interested in dual booting Android and Linux on your RK3288 device or you simply want to try a different Android ROM or Linux distro without flashing the device, then use this method of booting from an SD card. You will need a PC...
forum.xda-developers.com
says that RK3288Loader_uboot_V2.17.02.bin is required to boot from SD card. So earlier versions can't do that?
Can I flash these Loaders to any RK3288 device (I guess?) or are they device specific? Can I downgrade? Can I flash them in LOADER and MASKROM mode? Many things I don't understand properly...
The filenames usually contain "uboot". I guess that's not because they include uboot, but because the bootloader starts U-Boot from the "uboot" partition on a regular boot?