Related
I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse
Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything
thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.
File under "I'm no expert but..."
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App
heyy, I'm not punchie, I've got what the doctor calls a relaxed brain
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck
deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.
" 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.
Hi emmc bricked folks,
this is a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It's a companion software for my xda thread: "PIT file method to revive your phone from a MMC_CAP_ERASE brick".
The tools are started via "install zip" from a recovery.
emmc_scan_all_partitions_once.zip
emmc_scan_all_partitions_infinitely.zip
these allow fast scanning of all blocks of all emmc partitions in 1MiB steps.
The main purpose is to access each emmc block to find any bricked block in the partitions after repartitioning.
The "infinitely" variant runs checks infinitely, which may help to find emmc brick effects which only occur sporadically (if such effect really exists). Run this as long as you want. Reboot to finish.
If this freezes the last partition shown may have a bricked block inside.
emmc_find_brick_start.zip
emmc_find_brick_end.zip
these scan the whole emmc device.
emmc_find_brick_start starts scanning from the beginning of the device upward.
emmc_find_brick_end searches the end of the device and then scans downward.
If this runs up to the end or down to zero (showing a message with "completed --> OK"), no bricked block was found.
If it freezes, the block shown last with "..." at end of line is the first bricked block in that direction.
The line before with "-> ok" is the first usable block before/after the brick.
The tools above only read bytes from the emmc block devices, so it generally shouldn't harm anything.
Don't worry about the term "flash", because it doesn't really flash, it's only using the update mechanism of the recovery (edify scripting).
This is called fake flashing.
emmc_scan_write.zip
this is a very experimental scanner.
It is for experiments on phones, which have no obvious bad blocks in the partitions (scanned by scan_all_partitions_infintely without freeze) but still freeze randomly (without having problems with apps etc.).
It continuously creates a file of 10MB and deletes it after that.
The theory behind that:
* the wear leveler will assign different blocks each time the file is created
* the wear leveler may get a problem when assigning blocks to the file
* then it will freeze
* hopefully, if the file isn't deleted it will claim the bricked block(s), so they are not assigned again
* this will allow to isolate the blocks
* to keep those files containing bricked blocks, they are placed on the internal sd
note: the running counter is the amount written yet. It is not related to the partition size.
important:
The internal sd is determined by an environment variable EXTERNAL_STORAGE.
Despite it's name it should be the *internal* sd, instead SECONDARY_STORAGE contains the external sd.
I hope, this applies to all android OSes...please report if not.
For now you shouldn't use the tool, until you checked this:
adb shell set
If EXTERNAL_STORAGE isn't your *internal* sd, the tool will not help, because it writes on the external sd.
Some users wonder why it works so fast.
That's because it doesn't read each and every byte (like dd command or the "emmc brickbug check" app) but instead jumps in reasonable steps and in each step reads only the first byte of the chunk.
I think, reading each byte is not needed, because the flash memory is always used blockwise and the wear leveler (which has the bug) is working on the block level not the byte level. So a bricked block should always affect each byte in this block, which means reading one byte should be enough.
I choose steps of 1MiB (1024x1024 bytes), mainly because it's like parted etc., but unfortunately 1MB (1000x1000) doesn't work well so I was forced to use the MiB steps and calculated the other (currently rounded). May be the internal wear leveler block size is smaller (e.g. 256kiB = 256x1024 bytes), but it seems that the affected block area is always bigger than 1MiB. But I may rethink this decision...
when it's running slow
The scan method is very fast, I think the complete scan of the internal emmc should be done in under a minute, add several minutes for the external sd if scanning all partitions.
That said, if you get much slower performance, you probably hit an emmc bricked block. It seems the emmc brick can show up in two ways, either completely freezing the device or returning an error after a timeout which slows down the scan process significantly.
The word "FREEZE" in the descriptions above should be replaced by "freeze or slowdown".
So if it slows down, note the numbers at this point, like if the emmc freezes.
It's possible to use the scanner manually in adb (also from a terminal in the gui).
Extract file emmc-scan from one of the zips, put somewhere (=PATHTOSCANNER).
Eventually use
Code:
chmod 555 PATHTOSCANNER/emmc-scan
to make it executable (depend on how you extract it).
usage for find-brick-start:
Code:
PATHTOSCANNER/emmc-scan -p -f MMCBLOCKDEVICE
usage for find-brick-end:
Code:
PATHTOSCANNER/emmc-scan -p -b MMCBLOCKDEVICE
with e.g. MMCBLOCKDEVICE = /dev/block/mmcblk0 for N7000, etc.
example session:
Code:
unzip 120824-221256-emmc_find_brick_end.zip emmc-scan
adb root
adb push emmc-scan /cache/
adb shell chmod 555 /cache/emmc-scan
adb shell /cache/emmc-scan -p -f /dev/block/mmcblk0
to scan all partitions of all flash memory devices automatically (using my algorithm to find the flash devices) simply use:
Code:
adb shell /cache/emmc-scan
for usage description use:
Code:
adb shell /cache/emmc-scan -H
which outputs something like this:
Code:
usage:
emmc-scan [-f | -b] [-a] [-p] [DEVICE | PARTITION]
emmc-scan -w [-a] [-p] DIRECTORY
emmc-scan -H
operations:
-f forward, scan from begin to end of device
-b backward, scan from end to begin of device
-w write to writable partitions (fill with small files)
targets
-a scan all partitions
DEVICE device to be scanned (e.g. /dev/block/mmcblk0 )
PARTITION partition to be scanned (e.g. /dev/block/mmcblk0p10 )
DIRECTORY directory to be filled with files (e.g. /data, /sdcard )
other:
-p print position while scanning
-c print CR after position
-H output this help text
comments:
- scanning/writing is done in 0 byte steps (0 MiB)
- multiple devices/partitions/-a can be given with different options
- devices are scanned with all options given before
examples:
emmc-scan -b mmcblk0p10
scan /dev/block/mmcblk0p10 backward
emmc-scan -f -a -b /dev/block/mmcblk0
scan all partitions forward and mmcblk0 backward
To use the scanner with a terminal app in the android gui,
you ommit "adb shell",
so the example session would look like this:
Code:
chmod 555 /cache/emmc-scan
/cache/emmc-scan -p -f /dev/block/mmcblk0
There were several problems to be solved, mainly:
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* finding the emmc device(s)
* finding all emmc partitions to be scanned
* finding the end of a partition without working seek/setpos and without touching a block
* showing live outputs from the program in recovery (unfortunately doesn't work with \r)
the zips are now signed (but see "known bugs" section below).
currently tested on:
* Samsung Galaxy Note N7000
please report if it works for your phone model (e.g. finds the correct partitions) if it's not on the compatibility list.
known bugs:
* the signed zips may not work with stock recovery (1 report but no reports after changing the signing method)
Disclaimer: of course I cannot give any guaranties.
Please don't copy or link directly to an attachment. Link to the whole thread instead.
I will probably update this first post and the attachments frequently, at least until all calms down.
hg42 said:
Hi emmc bricked folks (and perhaps others),
I just created a emmc partition scanner which is mainly usable for emmc bricked phones (only Samsung?).
It is started via install zip from recovery.
It allows fast scanning of blocks in 1MiB steps of all emmc partitions.
The main purpose is to access each emmc block to find any bricked partition after repartitioning.
There were several problems to be solved.
Mainly
* seek, setpos functions not working for big partitions (only 4 byte numbers)
* dd command with skip= also not working for big partitions
* showing live outputs from the program in recovery
* finding all emmc partitions to be scanned
Please report, if it works for each unreported phone model. I will add a compatibility list and try to fix incompatibilities.
currently tested on:
* Samsung Galaxy Note N7000
Click to expand...
Click to collapse
Thank you for the post,
I need to try...
However, is it okay to flash this with STOCK ICS ROM?
tannykim said:
Thank you for the post,
I need to try...
However, is it okay to flash this with STOCK ICS ROM?
Click to expand...
Click to collapse
yes, this software only reads, so generally cannot harm.
It doesn't really flash, it's only using the update mechanism of the recovery (scripting).
hg42 said:
yes, this software only reads, so generally cannot harm.
It doesn't really flash, it's only using the update mechanism of the recovery (scripting).
Click to expand...
Click to collapse
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
please i neeed a good help whene its ok with custom partition but after flashing stock pit i have a good black screen i cant access to nothing either with jig
nice work will try.Thanks
tannykim said:
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
Click to expand...
Click to collapse
this might be, I am using custom ROMs all the time (mostly cm9).
But anyway, it's better to flash a custom kernel in these times (emmc brick is waiting).
tannykim said:
Please let me know if I am wrong.
I think I can only run signature confirmed flash with STOCK ROM.
Could you please confirm I can flash this with STOCK KERNEL [3.0.15-N7000XXLPY-CL474507] ?
Click to expand...
Click to collapse
hg42 said:
this might be, I am using custom ROMs all the time (mostly cm9).
But anyway, it's better to flash a custom kernel in these times (emmc brick is waiting).
Click to expand...
Click to collapse
Hi hg42, I'm on S2, but I think your work is great for all user that have bricked their devices, so any question: there is a cwm.zip for note (a temporary CWM flashable from the stock recovery like on S2)? If yes this can answer the question of tannykim.
Thank you
Mario
Inviato dal mio Galaxy S2 con Tapatalk2®
XWLPF Stock
Siyah 4.1 beta 6
Jkay V14.1
Mario1968 said:
there is a cwm.zip for note (a temporary CWM flashable from the stock recovery like on S2)? If yes this can answer the question of tannykim.
Click to expand...
Click to collapse
yes, you are right, I didn't think of it.
So he can flash cwm.zip and from cwm flash the scanner
But again I would not stay on stock ics kernel.
Too much danger to brick again.
Btw, this cwm.zip together with the stock ics kernel will cause the brick if wiping.
Newer cm recoveries and I think current chainfire's versions don't brick with the dangerous stock ics kernel.
hg42 said:
yes, you are right, I didn't think of it.
So he can flash cwm.zip and from cwm flash the scanner
But again I would not stay on stock ics kernel.
Too much danger to brick again.
Btw, this cwm.zip together with the stock ics kernel will cause the brick if wiping.
Newer cm recoveries and I think current chainfire's versions don't brick with the dangerous stock ics kernel.
Click to expand...
Click to collapse
I do not want to stay on stock but if I do not try anything [root... Custom OS...] There will be no further issue with STOCK...
I do want to have Rocket ROM but there is no way I can get Odin file for Custom ROM. After PIT change Odin installation is more efficient from my experiences. I tried to start with GB then Root and Wipe then Flash Custom ROM in recovery, but it is not stable after these process.
I am not expert so I need someone who have better experiences and knowledge on this.......
As I already posted on PIT post, I tried more than 50 times and I found most stable method, which is
1. Odin Flashing PIT file.
2. Odin Flashing CM9 safe kernel.
3. Boot in recovery Wipe everything / format everything
4. Odin Flashing Stock ICS ROM.
I can not use my Note same as before the Bricked...[No more many apps/No more multitasking....]
However I did not have any freeze and force to restart...
Dear hg42,
As tannykim said, I don't know what is happening with may Note too, it do exactly that same as his SGN !!!!!!!!!
Now I'm able to locate the bad blocks .. and I'm surly out of these blocks in my eMMC structure now. I did everything to make sure that FACTORYFS, DATAFS, and UMS partitions are in clear blocks, even though, random restarts, freezing, and hanging all the time.
Note: RECOVERY, CACHE, and KERNEL are also in clear blocks (after running the Partition Scanner app).
I also did a check that certainly made me sure that the I'm in a clear area in UMS. I mounted my SGN in the PC after flashing a ROM, then I copied to/from anything in the UMS partition till its full (more than a time) and it works like a charm, with no hangs at all. That made me certain that these blocks are OK. Even though, it hangs!!!!!. In addition I did the following checks:
Run the Partition Scanner app and shows no errors at all.
Did the DD command scan method, and shows no errors in all partitions (from forest1971 post)
Did the e2fsck check method, and shows no errors (from forest1971 post)
I can wipe all partitions in Recovery without any errors or hangs at all
I can install all types of roms without errors, no hangs in FACTORYFS image in odin at all
Now I'm about to go mad, everything is fine, I'm out of bad blocks, even though; freezing all the time and Force Close !!!!!!!!!!!!!!! WHY??
I noticed also that ICS stock ROM installed without the Lock Screen, strange!!!
Is there any explanation of what my phone is doing?
Thanks a lot for your efforts hg42, you rock
Mohamed
tannykim said:
I do not want to stay on stock
...
I do want to have Rocket ROM but there is no way I can get Odin file for Custom ROM.
Click to expand...
Click to collapse
ok
After PIT change Odin installation is more efficient from my experiences.
Click to expand...
Click to collapse
but there should be absolutely no difference.
Either you have other problems or the emmc brick behaves different in your case.
I can imagine, that a problem like the emmc brick, which is to be located in the wear leveler could produce any kind of errors.
It may just like a faulty memory.
I remember when reviving my phone, the start offset of the bricked blocks was higher first and then moved some 100 MB.
So my very first attempt didn't work, because some good blocks changed to bad blocks, so factoryfs freezed again.
Perhaps you may scan multiple times (the more the better in this case) to be sure it works reliably...
I tried to start with GB then Root and Wipe then Flash Custom ROM in recovery, but it is not stable after these process.
Click to expand...
Click to collapse
what is unstable then?
1. Odin Flashing PIT file.
2. Odin Flashing CM9 safe kernel.
3. Boot in recovery Wipe everything / format everything
4. Odin Flashing Stock ICS ROM.
I can not use my Note same as before the Bricked...[No more many apps/No more multitasking....]
However I did not have any freeze and force to restart...
Click to expand...
Click to collapse
this shouldn't be like this. E.g. the data partition has the same size afterwards, so the maximum count of apps should be the same.
What do you mean with "no multitasking"? You cannot switch between apps or such?
With absolutely *no* multitasking the OS wouldn't work.
What happens if you install cm9 (stable) in step 4?
Btw. do you do all these tests with a clean new system without any bloat? Or do you restore apps e.g. via Titanium backup?
what is unstable then?
- It keep freeze and randomly shut down
this shouldn't be like this. E.g. the data partition has the same size afterwards, so the maximum count of apps should be the same.
What do you mean with "no multitasking"? You cannot switch between apps or such? -If I want to switch between apps. Note get freeze step and do not do anything even screen stop.-
With absolutely *no* multitasking the OS wouldn't work.
What happens if you install cm9 (stable) in step 4? -I will try to flash the Rocket Rom V10 since your OP state Odin flash is best way to install the ROM I followed your OP. However, I will try and report that.-
Btw. do you do all these tests with a clean new system without any bloat? Or do you restore apps e.g. via Titanium backup?[/QUOTE]
-I did all these tests with a clean new system without any bloat. I am not sure what bloat you means but I did not have any backup since I lost all my data from the first bricked situations HaHa-
I updated the thread starter:
* added brick finder (start and end)
* added infinite variant of scanner
* some minor cleanups and improvements
* the files now start with date and time in YYYYMMDD-HHMMSS format
tannykim said:
It keep freeze and randomly shut down
Click to expand...
Click to collapse
you may try the new indefinite scanner, may be it finds a bricked block after many iterations.
The speculative theory behind that assumes the wear leveler which assigns free blocks to a write request may sometime assign a bricked block.
This would then result in random freezes (which usually reboot the phone after many seconds, if you wait patiently).
signed zips (hopefully)
update:
the zips should now be signed.
Those with stock recovery, please report failure and success.
EDIT: someone reported the zips still don't work with stock recovery.
I assume I have to dig deeper into the signing
sry for my bad english
when i use emmc_find_brick_start.zip , it's process Stop on 834MB
when i use emmc_find_brick_end.zip , it's Stop on 3064 MB
i use ( Q1_20110914_16GB-patched-regain-1126400-kB.pit ) pit file
any better pit file for me?
biostar said:
sry for my bad english
when i use emmc_find_brick_start.zip , it's process Stop on 834MB
when i use emmc_find_brick_end.zip , it's Stop on 3064 MB
i use ( Q1_20110914_16GB-patched-regain-1126400-kB.pit ) pit file
any better pit file for me?
Click to expand...
Click to collapse
note, this is a general android thread.
I'll answer in the PIT thread instead.
signed with testsign
I updated the emmc scanner tools with another signing method applied.
Hope this works now on stock recoveries...please report success or failure
hg42 said:
I updated the emmc scanner tools with another signing method applied.
Hope this works now on stock recoveries...please report success or failure
Click to expand...
Click to collapse
Hello hg42,
I have just flashed back a stock ICS recovery to test the signature verification, but unfortunately it failed with the standard message:
Code:
E:signature verification failed
Please, let me know if you need more tests.
Best regards,
aDEO
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Ps : sorry for my bad eng
Sent from my D5803 using XDA Free mobile app
This is flash memory. If they delete it and afterwards send the command to trim or gc then it's gone for good.
The unlocking process is too fast, I do not think they are rewriting the partition. I think they only remove the DRM then dalvik cache / cache and reboot the phone.
But I could be wrong.
I tried different software, they are effective on my SD card.
But my problem is that I do not see the internal hard disk of the phone, so I can not try it.
My phone is boot unlocked. No root / No recovery
If it was possible this would have been done already.
Skickat från min LG-V500 via Tapatalk
I don't talk about "if we can, if it's possible", i talk about doing this, to trying this.
for now, no one has tried.
Being negative without trying, is the best way of failing
dahod said:
It's just an idea but if we can access on the entire hard disk, I think it's possible to recover DRM.
It exists softwares to recover datas deleted. Maybe a way to explore.
Everybody knows datas are never totally erased.
Have discuss
Click to expand...
Click to collapse
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
cschmitt said:
The tools that are used to recover deleted files from a file system operate on the premise that deletions are performed by marking the sectors allocated to the file as 'free' in the allocation table without actually erasing the file data contained on the disk. Recovery tools can scan the entire disk to discover file chains and then rewrite the recovered data to some other device.
These tools will not work on the Trim Area (TA) because it is not a file system, but a raw partition that is accessed by directly reading/writing data at known addresses. There is no allocation table or file chains to recover.
The DRM keys are deleted when the bootloader is unlocked by overwriting the key data with 0x00 or 0xFF. This can be verified by dumping the TA partition of an unlocked device and examining the raw partition.
Click to expand...
Click to collapse
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
matapo said:
That makes perfect sense. Taking things one step back, why shouldn't we consider rewriting the DRM keys to the TA though? They're consistent among Z3C devices after all...Is there a bootloader validator that will just overwrite the keys again? Or preventing the overwrite in the first place, rather than worrying about an impossible recovery of the deleted key data?
If neither is possible, could you explain why please?
Click to expand...
Click to collapse
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
i thought with towelroot you can root without bootloader unlock ? if not, we just need a possibility to root without bootloader unlock and than we can backup the keys ?
yelp, only that needing JUST a way to root without unlock sounds so easy while it's not.
dahod said:
The unlocking process is too fast
Click to expand...
Click to collapse
TA.img is exatcly 2MB, writing 2MB of zeros to flash memory only takes fractions of a second.
cschmitt said:
We don't have the keys because w/o root we cannot dump the TA partition. If bootloader is unlocked to gain root, keys are wiped.
The assumption that the keys are common among all devices may not be correct. In previous Z series devices restoring the TA partition from a different device would brick it. This indicates the TA contains some device specific signature, etc. The keys could be protected with device-dependent public/private key encryption tied to IMEI and some private key. If Sony went to the trouble of protecting their IP with DRM, they are going to protect the DRM keys as well.
Click to expand...
Click to collapse
Thanks for the explanation - much appreciated! Hopefully, someone will attempt the 'almost impossible' and find an exploit or two like towelroot, allowing for root access without compromising the bootloader then. Seems like our only option. Sony hasn't made this easy...I can understand why our fellow users are upset.
Just so people don't get confused: that doesn't mean that the DRM keys can be recovered when the phone was already unlocked, but they can be restored if a backup is made before.
PS: and restoring the keys automatically relocks the bootloader which means they can only be used by stock roms iirc. At least that was the case with RomAur I've been using, restoring the keys resulted in a bootloop.
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
For the root exploit on the older Z devices, did the exploit work only on certain firmware versions, or could it work on most or all of the versions?
I'm asking this because I've for the notification for a system update, but I've been holding back on installing the update, thinking that perhaps any exploit might be patch in newer versions.
Thanks.
Only specific versions. But it was possible to downgrade, root and then upgrade while keeping root. Towelroot then worked with various versions that used an affected kernel version.
My brain wouldn't let me sleep last night over this (probably stupid) idea:
If /system can be written to by certain tools (correct me if I'm wrong, but afaik you can flash .ftfs with flashtool with a locked bootloader), would it not be easier to find an exploit there (in the .ftfs)?
Much easier said than done, yes, but sounds much easier than finding an exploit in Android, imo.
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Iruwen said:
I guess tampering with an FTF changes its checksum so it cannot be used anymore.
Click to expand...
Click to collapse
Well yes, you cannot alter an ftf, but what if we somehow made a small img of system and tricked flashtool into tricking it's actually just the system part of an ftf?
Flashtool then flashes the rooted system image and viola, root achieved!
You know, just how Nexus devices have a recovery (factory) image for each partition? Why not make this work?
Ofc just a (probably wayy off) theory, but it seems plausible.
dahod said:
Thank you all for your explanations, I hope that a great mind will find the solution for those who have already unlocked.
Sent from my D5803 using XDA Free mobile app
Click to expand...
Click to collapse
I wouldn't bet on it. The 'issue' has been there since the Xperia Z, the only solution has been to backup the partition before unlocking, else it's gone for good.
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!!