hello all,
I am interested in locking the bootloader on a sg3, any leads on what steps I may need to accomplish this?
thank you
What carrier are you on?
redusk said:
What carrier are you on?
Click to expand...
Click to collapse
its unlocked, but it would be the canadian variant i747m, also have a intl variant somewhere, i9300 or something
The French Tickl3r said:
hello all,
I am interested in locking the bootloader on a sg3, any leads on what steps I may need to accomplish this?
thank you
Click to expand...
Click to collapse
It's not an easy way. Some eMMC have command to write-protect some areas (temporary, or permanently). But these eMMC commands usually are not presented in source code of kernel because there are no practical reasons to use them (unless you are original manufacturer). So, you need to detect what eMMC chip used in your phone, then find good datasheet to find appropriate command (if any). Then write utility to execute this command (and if you write protect a wrong block then there is no way back).
Thus, you need to be a skilled low-end developer to accomplish this task.
If you mean lock like it's done in phones with locked bootloader - then it's completely different story. In this case, write-protect-till-power-off lock used. So, when such phone boots, whole eMMC is available for writing. And then on the very early stage bootloader executes command write-protect-till-power-off, and you can't write anything to bootloader till you turn power off. If you want to accomplish this behaviour then you have to write your own bootloader, which is not simpler than task above. More over, you won't be able to write your own bootloader because it requires to be signed by private master key, which only Samsung lab has
sorg said:
It's not an easy way. Some eMMC have command to write-protect some areas (temporary, or permanently). But these eMMC commands usually are not presented in source code of kernel because there are no practical reasons to use them (unless you are original manufacturer). So, you need to detect what eMMC chip used in your phone, then find good datasheet to find appropriate command (if any). Then write utility to execute this command (and if you write protect a wrong block then there is no way back).
Thus, you need to be a skilled low-end developer to accomplish this task.
If you mean lock like it's done in phones with locked bootloader - then it's completely different story. In this case, write-protect-till-power-off lock used. So, when such phone boots, whole eMMC is available for writing. And then on the very early stage bootloader executes command write-protect-till-power-off, and you can't write anything to bootloader till you turn power off. If you want to accomplish this behaviour then you have to write your own bootloader, which is not simpler than task above. More over, you won't be able to write your own bootloader because it requires to be signed by private master key, which only Samsung lab has
Click to expand...
Click to collapse
thank you for the detailed response. i shall not pursue this any longer.
best regards, from cloudy montreal
Related
Hi there, I have some questions about Cracking bootloader:
1. Anyone know the way to crack bootloader for Motoroi XT720?
2. If not, so is there any clue?
3. Will my phone brick if I try to override boot partition?
Thanks in advanced!
tiger2wander said:
Hi there, I have some questions about Cracking bootloader:
1. Anyone know the way to crack bootloader for Motoroi XT720?
2. If not, so is there any clue?
3. Will my phone brick if I try to override boot partition?
Thanks in advanced!
Click to expand...
Click to collapse
I don't think you can flash boot partition with images without moto's signature.
How about use `dd` command to write modified raw partition?
I'm amazing it is likely on PC we have BIOS, boot loader and so on, BIOS can write via flash program & boot loader can write directly to boot partition or modify boot sector if you have physical access or root permission through remotely, is it right? please correct me if I'm wrong.
tiger2wander said:
How about use `dd` command to write modified raw partition?
I'm amazing it is likely on PC we have BIOS, boot loader and so on, BIOS can write via flash program & boot loader can write directly to boot partition or modify boot sector if you have physical access or root permission through remotely, is it right? please correct me if I'm wrong.
Click to expand...
Click to collapse
Raw partition might be able to come to reality, but mz still need time to work on it.
It will be great if we can unlock it to get free world!
So, how hard to get it done? is there any block on the road or it is simple need more time to get it stable?
tiger2wander said:
It will be great if we can unlock it to get free world!
So, how hard to get it done? is there any block on the road or it is simple need more time to get it stable?
Click to expand...
Click to collapse
Crack bootloader? not possible. but it seems system's signature can be passed by dump a cg39.smg from the phone, that is means possibility, but needs to testing.
You meant dump then RE it to find any security exploit which can allow us to bypass signature check from bootloader?
BTW, how about progress of existing research about this?
I've just ask Google for this and get some interest articles:
- http://pocketnow.com/thought/efuse-droids-digital-kill-switch
~> is it like this one? if so I will never buy Motorola Phone anymore! it's 2 sh!t to pay money for blocked device...
First of all.
http://droid-developers.org/wiki/Booting_chain
Just read it...
Thanks man, already read it somewhere on Internet
EDITED: but this one have more clear than last one I read!
Hi, I'm receiving my new Moto G this week and I've read that the only way to gain root access at the moment is asking motorola to unlock the bootloader and thus, losing the warranty.
1.Does Motorola keep track of those who unlock the device so, even if you relock it, your warranty is still void?
2.Is there any other possible way to do that so you don't lose warranty?
3. And if so, is anybody working on that? Because if there will be another way I'd rather wait until some awesome developer achieves that.
Yes because you have to submit “fastboot oem get_unlock_data" to Motorola on their website to get the unlock code for the Bootloader secondary there is a qfuse and/or a flag which can not be set to default (at the moment).
At the moment not.
No idea, i'll wait some time, hopefully there will be a workaround someday. But if i remember right there is no way at the moment to revert the changes once the qfuse is broken.
Read more the questions have already been answered.
Much of Qualcomm's security architecture is implemented using QFuses, which are software-programmable fuses that allow one-time configuration of device settings and cryptographic materials such as hashes or keys. Because of their physical nature, once a QFuse has been blown, it is impossible to "unblow" it to revert its original value.
Click to expand...
Click to collapse
Link: Once you REQUEST!!! the unlock code, your warranty will be voided.
Because the the other old Dev thread is getting a bit messy i've created a new thread to continue development of a boot loader unlock for 11 series devices.
Dont post ANYTHING unrelated to development of a way to change toshiba chip's cid!!!
@GeTex says she may be able to get us the firmware / vendor cmds which would be awesome!
===================================JULY 30 UPDATE==================================
Trying to reprogram CID abandoned, looking at alternate methods of unlocking b/l (or getting a custom kernel past QSB/Knox) @GeTex working on writing to memory using the Futex(towelroot) exploit to load some kernel modules.
Relevant links:
http://blog.nativeflow.com/the-futex-vulnerability
http://blog.nativeflow.com/escalating-futex
http://blog.nativeflow.com/pwning-the-kernel-root
====================================Original post====================================
So far we know what Beaups did to get the 15 series chip exploit.
1) Get vendor cmds (we know its cmd26 to reprogram the cid but do not know the args for toshiba chips)
2) Dump eMMC firmware
3) Look through code for how it is programmed
4) Create a tool to use this info and reprogram the CID
We need to
1) Find the args for the command
2) dump toshiba emmc controler's firmware
3) Find how to program CID
4) Modify Beaups tool
Alternatively, If we know what the controller is and the pin map we could manually dump the firmware with existing SD card tools (Wouldn't count on it)
Not sure where you can find it but if you can dump the chip's firmware then we dont need the first step
Relevant docs:
https://drive.google.com/open?id=0BxoK4ISYhlfbbW02TzJ0VlhoV0E
https://drive.google.com/open?id=0BxoK4ISYhlfbdDZvbGxxV2F3OUU
https://github.com/beaups/SamsungCID (read samdunk disclosure)
http://toshiba.semicon-storage.com/us/product/memory/nand-flash/mlc-nand/emmc.html (Our chip is the THGBMHG7C1LBAIL I believe)
http://forum.xda-developers.com/showpost.php?p=37936242&postcount=72
Dumping emmc Ram, Not sure if that helps
deleted
I don't think I can dump the firmware using a JTAG box due to security, can i?
GeTex said:
I don't think I can dump the firmware using a JTAG box due to security, can i?
Click to expand...
Click to collapse
it doesn't look good the JDEC spec says most of those registers are write once read only
what I wanna know is where in the boot process does it check the CID registers and is there anything we can do to manipulate it to read whatever value we feed it
GeTex said:
I don't think I can dump the firmware using a JTAG box due to security, can i?
Click to expand...
Click to collapse
I do not think you can jtag the eMMC chip. and @Legitsu that would involve modifying the bootloader or kernel which we would need an unlocked bl for.
autonomousperson said:
I do not think you can jtag the eMMC chip. and @Legitsu that would involve modifying the bootloader or kernel which we would need an unlocked bl for.
Click to expand...
Click to collapse
maby not what if you modified the locked bootloader.yes it would normally fail the SB and crc checks but its not entirely out
there is also some interesting bits in the cmds uses to read registers
and kernel mods can be done with modules
Legitsu said:
maby not what if you modified the locked bootloader.yes it would normally fail the SB and crc checks but its not entirely out
there is also some interesting bits in the cmds uses to read registers
and kernel mods can be done with modules
Click to expand...
Click to collapse
I think the CID check is before the kernel is even loaded.... Seems to be all with the bootloader
autonomousperson said:
I think the CID check is before the kernel is even loaded.... Seems to be all with the bootloader
Click to expand...
Click to collapse
I would think so as well but may not stop us from doing some tricks such as chainloading exploits
where we boot from the locked aboot patch the cid and somehow make it reset and load the other aboot and feed it that CID
kexec is very very close to being working on the S4 @Surge1223 how up2date is the source for that in your repo ?
honestly I think kexec is going to be the future for all devices its less effort and more viable then finding the rare exploits for actually unlocking the bootloader
I just don't have the time I once did and my skills are rusty AF
Legitsu said:
I would think so as well but may not stop us from doing some tricks such as chainloading exploits
where we boot from the locked aboot patch the cid and somehow make it reset and load the other aboot and feed it that CID
kexec is very very close to being working on the S4 @Surge1223 how up2date is the source for that in your repo ?
honestly I think kexec is going to be the future for all devices its less effort and more viable then finding the rare exploits for actually unlocking the bootloader
I just don't have the time I once did and my skills are rusty AF
Click to expand...
Click to collapse
We can try to get it to go into rescue mode where it boots off sd. Idk how far that will get us as sd boot still needs to be signed (I think). Even if we try to chain load something its only temp and will need to be done every boot and could get messy. Chaining the CID directly is the best option.
autonomousperson said:
We can try to get it to go into rescue mode where it boots off sd. Idk how far that will get us as sd boot still needs to be signed (I think). Even if we try to chain load something its only temp and will need to be done every boot and could get messy. Chaining the CID directly is the best option.
Click to expand...
Click to collapse
see I know the S4 the sdboot no longer works as of NK4 but it works on the S5 ?
recovery mode may show us more info
I wonder what would happen if you imaged a devedtion bootloader and then killed the aboot and let it try from the sdcard (would tell us what it checks when attempting recovery)
messy would be fine as it would provide more info
Legitsu said:
see I know the S4 the sdboot no longer works as of NK4 but it works on the S5 ?
recovery mode may show us more info
I wonder what would happen if you imaged a devedtion bootloader and then killed the aboot and let it try from the sdcard (would tell us what it checks when attempting recovery)
messy would be fine as it would provide more info
Click to expand...
Click to collapse
The dev edition BL on sd would work as its signed BUT it wont display as a dev editon as the CID doesnt match. I think as soon as you touch the sd card bl it will refuse to boot. Unfortunately I no longer have a vzw test device (pulled the samsung eMMC BGA off of it 0/10 would not recommend )
autonomousperson said:
The dev edition BL on sd would work as its signed BUT it wont display as a dev edition as the CID does not match. I think as soon as you touch the sd card bl it will refuse to boot. Unfortunately I no longer have a vzw test device (pulled the samsung eMMC BGA off of it 0/10 would not recommend )
Click to expand...
Click to collapse
I wonder if there is a way to manipulate the CID while its in qualcom-recovery
once you boot it as a DEV edition that opens a lot of doors to do other things
I am still reading the JDEC spec pdf nothing so far
Legitsu said:
I wonder if there is a way to manipulate the CID while its in qualcom-recovery
once you boot it as a DEV edition that opens a lot of doors to do other things
I am still reading the JDEC spec pdf nothing so far
Click to expand...
Click to collapse
Renember that its just a general specification, toshiba has to follow all of it but they can change or add extra features. They said they had some extra security features or something.
http://toshiba.semicon-storage.com/ap-en/product/memory/nand-flash/mlc-nand/emmc.html
THGBMHG7C2LBAIL
Products which applied "Command Queuing" and "Secure Write Protection" functions standardized in JEDEC e・MMC™ Version 5.1 as optional features.
autonomousperson said:
Renember that its just a general specification, toshiba has to follow all of it but they can change or add extra features. They said they had some extra security features or something.
http://toshiba.semicon-storage.com/ap-en/product/memory/nand-flash/mlc-nand/emmc.html
THGBMHG7C2LBAIL
Products which applied "Command Queuing" and "Secure Write Protection" functions standardized in JEDEC e・MMC™ Version 5.1 as optional features.
Click to expand...
Click to collapse
yes but the JDEC spec exists for a reason changing that spec opens you to creating other flaws :>
and neither of those have anything todo with the registers we are interested in
Idk what to do then. The stuff we want (cid) is managed by the eMMC firmware. The bl then reads and compares it to the aboot. We could try a man in the middle thing but we would need it to load before the check happens.
autonomousperson said:
Idk what to do then. The stuff we want (cid) is managed by the eMMC firmware. The bl then reads and compares it to the aboot. We could try a man in the middle thing but we would need it to load before the check happens.
Click to expand...
Click to collapse
read though page 28/29/30/ect of *B51 pdf
look at how they describe the alt operation mode
it says you can set the csd register I wonder what else you can set durning that time (ignore for the moment we don't have a way of setting any registers yet ..(
Legitsu said:
read though page 28/29/30/ect of *B51 pdf
look at how they describe the alt operation mode
it says you can set the csd register I wonder what else you can set durning that time (ignore for the moment we don't have a way of setting any registers yet ..(
Click to expand...
Click to collapse
We would have to find a way to trick it into thinking it is booting. (I think it is first boot, not every boot)
autonomousperson said:
We would have to find a way to trick it into thinking it is booting. (I think it is first boot, not every boot)
Click to expand...
Click to collapse
indeed but progress
Legitsu said:
indeed but progress
Click to expand...
Click to collapse
BUT
We would still need to figure out how to get it to write a new CID (specifically what tf cmd 26 is)
OR
We can use vendor commands like Beaups (would need to find them)
Hi everyone, this question is for developers who have some bases in hexadecimal programming, I would like to know if it is possible to remove the message after unlocking the bootloader, I had an LG V20 H990DS and I had followed the tutorial on this thread and it was working fine, is there a similar solution for the ROG 5.
[Guide][MOD] Hide unlocked Bootloader warning boot screen
. This fix is for those who want to get rid of the annoying Red Corruption warning screen!!. Disclaimer: You apply the fix at your own risk. I'm not responsible for any software or hardware damage it can lead. The only thing i can assure is...
forum.xda-developers.com
zinou213 said:
Hi everyone, this question is for developers who have some bases in hexadecimal programming, I would like to know if it is possible to remove the message after unlocking the bootloader, I had an LG V20 H990DS and I had followed the tutorial on this thread and it was working fine, is there a similar solution for the ROG 5.
Click to expand...
Click to collapse
That depends. I modified a Teclast T30 bootloader (Mediatek garbage) that forced a delay and printed an orange error message about the bootloader being unlocked. A bit of Arm64 reverse-engineering and I shorted the delay to 0ms (none, basically) and just cut the string short (null-byte) and it works fine on my junker tablet. I've just bought an ASUS ROG Phone 5, getting into it, but I'm nervous about touching anything without, say, TWRP or without knowing how to do a full raw backup and restore.
Yuji Saeki said:
That depends. I modified a Teclast T30 bootloader (Mediatek garbage) that forced a delay and printed an orange error message about the bootloader being unlocked. A bit of Arm64 reverse-engineering and I shorted the delay to 0ms (none, basically) and just cut the string short (null-byte) and it works fine on my junker tablet. I've just bought an ASUS ROG Phone 5, getting into it, but I'm nervous about touching anything without, say, TWRP or without knowing how to do a full raw backup and restore.
Click to expand...
Click to collapse
RAW Firmware Collection and Guide
All fastboot / adb commands require using the side USB-C port https://developer.android.com/studio/releases/platform-tools.html#download Make sure you have fastboot installed Add platform tools to PATH (post 2) Make a backup of anything...
forum.xda-developers.com
There ya go. Good luck
twistedumbrella said:
RAW Firmware Collection and Guide
All fastboot / adb commands require using the side USB-C port https://developer.android.com/studio/releases/platform-tools.html#download Make sure you have fastboot installed Add platform tools to PATH (post 2) Make a backup of anything...
forum.xda-developers.com
There ya go. Good luck
Click to expand...
Click to collapse
Thanks. Just waiting to figure out how to do a raw backup and restore, then I can get to it. If TWRP isn't required to do a raw backup and restore, then I can also begin work on porting TWRP. I've some experience, but not the most when it comes to TWRP porting.
*Edit* I'd like to add, reverse-engineering the ASUS Unlock Tool seems to show the limits on unlocking may be artificial by ASUS. Uses a call-home to fetch data to unlock with. The logic though may be in another castle, I mean package. The FOTA app does the same thing.
*Edit* By the way, does anyone have the exact message that displays about the bootloader being unlocked? I might be able to begin work tracking it down to remove as well as any delay (if there is one).
Some mods target the abl.img (possibly Android Boot Loader) so that may be one place to start. I personally never bother with backups, so I didn't really consider that. All of the data for my apps is synced and everything else is installed from Google Play. I guess that would be a bit more difficult if this were my primary phone.
The text for fussing is in tz.img, or at least it is *one location* with it. But since this is a stupid Tencent version, I can't flash anything to test, otherwise I'd have done it by now. Ah well. Sending the Tencent POS back.
OK , So the possible partitions to see deeper are abl.img and tz.img, can anyone help us with some more informations to remove this annoying message, thanks to all for your participation
Use payload_dumper and a hex editor to compare the original to yours.
Still Waiting for help to remove this message, if anyone has the solution
Hi,
While going around this forum, i saw a lot that people where claiming that an unlocked phone had it's data fully secure if it was encrypted. Is it actually the case ?
From what i understand, a phone isn't encrypted with your pin code / password. It first generates keys, encrypts the phone with them, and then cyphers these keys using your code. The keys are then stored in a special partition of the phone's memory.
(And thus, if the phone needs be wiped, either remotely or because of too many failed attempts, it just deletes this partition)
Normally, it would be impossible to brute force a lock screen, since the phone will prevent more than ~ 15 attempts. However, with an unlocked device, couldn't an attacker with sufficient knowledge of the hardware be able to use the ability to flash custom boot images / roms to access these keys, and brute force them, bypassing the lock screen ? A sufficiently powerful computer could be able to brute force a 4, 6 or even 10 digits AES key in hours, if not minutes.
So :
1) Is this correct, and how the android encryption works ?
2) if it is, is there any device specific protections to prevent that ?
3) is there any ways to counterbalance that threat with an unlocked device, other than setting a 10 characters password ?
Thank you.
Short answer:
If phone's bootloader is unlocked, someone could take your phone, flash a malicious ROM that contains keystroke loggers or something, and then return the phone to you and wait for you to type your PIN or decryption password. It'd be better to keep the bootloader locked whenever you don't actually need to flash things via Fastboot.
xXx yYy said:
It'd be better to keep the bootloader locked whenever you don't actually need to flash things via Fastboot.
Click to expand...
Click to collapse
I guess this wanders into device specificness, but, at least for my device, pixel 6a, i read that you should never re-lock a bootloader without a completely stock firmware / boot image. So, how can you protect your bootloader while keeping your phone rooted ?
What has a device's bootloader to do with device's Android OS ? Nothing!
xXx yYy said:
What has a device's bootloader to do with device's Android OS ? Nothing!
Click to expand...
Click to collapse
The lockability of the bootloader depends on the signing of the OS!?
you are right. do not lock bootloader on pixel devices. imagine device is fully stock and locked, now some OTA brick device and recovery mode not able to unbrick by sideloading full OTA image - this is nightmare. google's solution is to RMA device, they do not provide any flash tool other than fastboot or WebUSB flash tool (via adb lol)
on the other hand, encryption is secured against bruteforce by gatekeeper (in TEE). as long as your device is powered off your data remains encrypted, unless you decrypt with credentials (we won't talk about the .dismiss() bug on decrypted devices)