UPDATE: New Jailbreak here: http://forum.xda-developers.com/showthread.php?t=2118348
Here's the bottom line up-front
Samsung has inserted code to blacklist our baseline and mitigate our exploits in the bootloader patch they began pushing out last night. You will need to flash the updated bootloader baseline and stock pit in order to restore your device to operational status. The How-To Unlock your Bootloader thread is invalid at this time.
Going Forward
I need your help with CASUAL. In order to mitigate this problem, I began working on a CASUAL update system on January 13. If you feel inconvienced now, contribute to the Casual Update System beta by testing it. Currently, CASUAL is dumb. If there is a problem you won't know until after you flash. The idea behind the Update System is to either update the CASUAL to work again, or kill-switch it and automatically bring you to a thread like this one. Obviously it's infinitely more helpful than a simple failure and I need testing on Windows, Linux, Mac and firewalls.
The CASUAL Unlock method will be updated when we figure it out and it will be possible to auto-update or do a helpful kill-switch in the next version.
Addressing Security Patches:
Recognized Developer Ralekdev has began work on a new exploit. It's not going to be as simple as it was before.
Bootloader Blacklisting
You can view the updated code here: http://pastie.org/private/zzfhwlrgeeuzweiccjdpvg#22
Previously, Odin Mode would accept any SBOOT with the proper signature. Samsung has implemented a blacklist which causes properly signed flashes to fail if they are contained in the blacklist.
The old bootloader contained random ARM hex data "CD D2 04 85 63 83 52 7C C9 8A 97 1A CD 30 78 FB".. The new one contains an identifier "EXYNOS_4412 1220". The new bootloader is also programmed to not be able to flash itself.
Non-Header Code Execution
You can view the updated code here: http://pastie.org/private/ryxaraypnnhbmtt6nswvq
Previously, if the ANDROID header was missing from the kernel, SBOOT would execute the partition as raw ARM code. This allowed Ralekdev's exploit to jump into the SBOOT.bin and execute download mode without security checks. However the code has been replaced..
So obviously, this execution of arbitrary code exploit has been patched.
Conclusion
We are working to bring a new exploit and make it easier that the last one. Ralekdev will be analyzing and working on a new exploit. I will work on deployment techniques. For now if youre having problems, flash back to stock and root your device.
Here's the bottom line up-front
Samsung has inserted code to blacklist our baseline and mitigate our exploits in the bootloader patch they began pushing out last night. You will need to flash the updated bootloader baseline and stock pit in order to restore your device to operational status. The How-To Unlock your Bootloader thread is invalid at this time.
Going Forward
I need your help with CASUAL. In order to mitigate this problem, I began working on a CASUAL update system on January 13. If you feel inconvienced now, contribute to the Casual Update System beta by testing it. Currently, CASUAL is dumb. If there is a problem you won't know until after you flash. The idea behind the Update System is to either update the CASUAL to work again, or kill-switch it and automatically bring you to a thread like this one. Obviously it's infinitely more helpful than a simple failure and I need testing on Windows, Linux, Mac and firewalls.
The CASUAL Unlock method will be updated when we figure it out and it will be possible to auto-update or do a helpful kill-switch in the next version.
Addressing Security Patches:
Recognized Developer Ralekdev has began work on a new exploit. It's not going to be as simple as it was before.
Bootloader Blacklisting
You can view the updated code here: http://pastie.org/private/zzfhwlrgeeuzweiccjdpvg#22
Previously, Odin Mode would accept any SBOOT with the proper signature. Samsung has implemented a blacklist which causes properly signed flashes to fail if they are contained in the blacklist.
Code:
bytes_to_hexstr(BL1_blacklist_str, base_addr + 0x1BF0, 16);
if ( !strcmp(BL1_blacklist_str, BL1_blacklists[i]) )
{
sub_43E03A00("BL1 of the blacklist - %s\n", BL1_blacklists[i]);
return -1;
}Non-Header Code Execution
You can view the updated code here: http://pastie.org/private/ryxaraypnnhbmtt6nswvq
Previously, if the ANDROID header was missing from the kernel, SBOOT would execute the partition as raw ARM code. This allowed Ralekdev's exploit to jump into the SBOOT.bin and execute download mode without security checks. However the code has been replaced..
Code:
if ( !memcmp(v5, "ANDROID!", 8) )
{
*** DO NORMAL SECURE BOOT ****
}
else
{
dprintf("Could not do normal boot. (invalid magic)\n");// this is where we exploited it last time to load my code
s5p_start_download_mode(v9);
}
return 0;
}Conclusion
We are working to bring a new exploit and make it easier that the last one. Ralekdev will be analyzing and working on a new exploit. I will work on deployment techniques. For now if youre having problems, flash back to stock and root your device.
Last edited:
