{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
We are proud to announce that the Jetstream is now supported by the HTC Unbrick Project!
Note: This will fix only devices which were bricked by turning S ON. And bricks caused by a damaged hboot via interrupted OTA update/RUU flash on a S-ON device. Any devices bricked with other ways are currently *not* supported.
Prerequisites
a linux box/live cd with automount disabled and without unity
the appropriate package for the device
the latest RUU for your device
a device bricked by writing security flag 3 with an unsigned hboot, or caused by a damaged hboot via interrupted OTA update/RUU flash on a S-ON device
a usb cable
a piece of insulted wire of approx length 10-15cm and with solid core
some basic linux experience
patience
DISCLAIMER: We do NOT guarantee that this method will work for you, or that it is flawless. We are also not responsible if your phone is completely dead after the procedure, or your house burns down because your phone exploded. You are doing this in YOUR OWN RISK.
Instructions
Detailed video on the process. It's displaying the process on a Sensation, but its pretty much the same thing( except for the wire trick). Thanks to kgs1992
Detailed instructions on the wire trick: here. We need ONLY parts 1-3 of that guide, since we need to make contact ONLY ONCE and NOT TWICE!!! Thanks to unlimited.IO for the nice write up
Boot the linux box and download the appropriate package for the device.
Extract the package in the home directory
Open up a terminal
Remove SIM, microSD card and connect the device using the USB cable.
Detect the device using the script provided. Type this in the terminal
Code:
./brickdetect.sh
You should get something like sdX. We are interested on that "X"
Do the wire trick once and unplug the device
Re-plug the device
Backup the hboot currently in the phone by using this command. Plug the device in ONLY when asked to
Code:
sudo ./emmc_recover --backup b_hboot.img --device /dev/sdX12
Replace the "X" with the letter the script gave you
Follow the on-screen instructions from emmc_recover
Hexdump the b_hboot to check the hboot version
Code:
hexdump -C b_hboot.img |less
The output should be like this:
Code:
00000000 05 00 00 00 03 00 00 00 00 00 00 00 00 00 10 40 |[email protected]|
00000010 d8 fc 0f 00 d8 fb 0f 00 d8 fb 1f 40 00 01 00 00 |[email protected]|
00000020 d8 fc 1f 40 00 00 00 00 12 00 00 ea 31 2e 37 38 |[email protected]|
00000030 2e 31 31 31 31 00 00 00 38 32 36 30 20 53 50 4c |.1111...8260 SPL|
00000040 00 00 00 00 00 f0 20 e3 53 48 49 50 00 00 00 00 |...... .SHIP....|
00000050 00 f0 20 e3 00 f0 20 e3 48 42 4f 4f 54 2d 38 32 |.. ... .HBOOT-82|
00000060 36 30 00 00 00 f0 20 e3 39 30 30 31 66 34 63 36 |60.... .9001f4c6|
This is the typical hex of a hboot. We are interested to check if that is the hboot partition and if it is, to get to know the version. In this case it is 1.78
This part of the procedure is to ensure future compatibility with updated hboots. You may as well skip the version detection and flash the 1.78 hboot directly if you S-Off'ed with JuopunutBear
If in the above step you failed to identify the hboot, unplug all devices connected to that pc, reboot and try again
Do the wire trick once and unplug the device
Replug the device
Check again it is the right version, because if you do a mistake here, you won't be able to go back
You can only flash the same version as the one in the device.
!!!!!DO NOT ATTEMPT TO FLASH ANOTHER VERSION OR DOWNGRADE!!!IT HAS BEEN PROVEN FATAL!!!!
Flash the hboot on the device. Replace "V.VV" with hboot version (eg. 1.78) and "X" with the one you got from the detect script. Plug the device in ONLY when asked to
Code:
sudo ./emmc_recover --flash verdV.VV.nb0 --device /dev/sdX12 --backupafter hboot_f.nb0
Follow the on-screen instructions from emmc_recover. A successful flash should have this output:
Code:
511+1 records in
511+1 records out
1047808 bytes(1.0 MB) copied
Do the wire trick once and unplug the device, put SIM, and microSD card in and power on
Congratulations, the device is unbricked.
FLASH THE RUU IMMEDIATELY AFTER RECOVERING!! The device will be unstable after the recovery if you don't flash it.
Notes on the procedure:
If the device doesn't power on, get a copy of the hboot_f.nb0 and b_hboot.img (should be located in the home directory) and contact us
The connection between the device and the pc will be unstable, and will time out. You have to be quick when doing the above, specially while flashing. If the connection times out don't panic, just do the wire trick once, unplug and replug the device
Unity and automount are known to cause issues in ubuntu 11.04 and 11.10. We recommend getting rid of both, or use a 12.04/.10, or 10.04/.10 liveCD
USB3 ports do not work properly. Please plug the device in a USB2 port
USB hubs are also known to cause issues. Avoid using them
The liveCD provided has autoount enabled. please disable it
How to disable automount on ubuntu
Code:
gsettings set org.gnome.desktop.media-handling automount false
Downloads
For Jetstream (Verdilte):
32bit version MD5: 257edd0e4002d0e660ff55ecefa3bb43
64bit version MD5: 2c673a3b0571b52555dfe2299dc993a5
Related
Hello everyone.
With the development of the New ROM, I decided to describe this and that.
-How to Prepare files and packages.
-How to create stable SYS and OEM.
-XIP Porting (Kernel) - if it succeeds.
-Build/Mod. BLDR/BOOT Section
-Change PagePool
-Etc
Small introduction:
Subject shows the structure of folding and unfolding ROM.
Everything described here are doing at your own risk.
I do not answer with any damage to the device.
Please read carefully and proceed with caution.
Topic applies only Toshiba devices Tsunagi: TG01
Execute Image System:
This step tutorial will be further developed.
Once, I'll add this feature in my kitchen.
Add OEM Apps:
OEM - This package is derived from the *. cab file.
It must include:
- The *. dsm guid the value of the name,
- The *. RGU with the same value in the name, it must be in Unicode encoding.
It must also be free, the last line in the content of the text.
- Application *. exe, *. dll, or library
- A shortcut to the program / library - if it is needed. It is not mandatory.
- Content may be more developed (in the files / programs)
Such a package can be easily added to the root of the OEM.
If, of course, is properly filed
Dependence of the Application, the memory devices.:
How can you distinguish the memory which will hit your application / library?
This differs from the rule:
- Module - that is, a file that looks like a directory goes to RAM.
- File - normal-looking, *. exe or *. dll file, going to Storage memory
Porting XIP (Kernel) and insert this file to Image System:
[TUT][UTIL]Remote Porting XIP
Working good in my kitchen for Toshiba TG01
XPR to LZX Compression:
Open the file os.nb.payload in HEX Editor. Find this Lines:
Code:
F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC ř¬,ťăÔ+M˝0‘nŘO1Ü
01 00 00 00 01 00 00 00 01 00 00 00 34 00 00 00 ............4...
08 00 00 00 00 02 00 00 00 10 00 00 58 50 52 00 ............XPR.
And change to:
Code:
F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC ř¬,ťăÔ+M˝0‘nŘO1Ü
01 00 00 00 01 00 00 00 01 00 00 00 34 00 00 00 ............4...
08 00 00 00 00 02 00 00 00 10 00 00 58 50 52 00 ............LZX.
Save this file. Get this library -> cecompr_nt.dll, then insert to TOOLS folder from your Kitchen ROM.
Download cecompr.dll and overwrite it in your XIP. Build XIP, build ROM, see results. Now Image System takes less memory.
Small Support
Changes PagePool:
Use PagePool Changer
Porting/build BLDR/BOOT and insert this file to Image System:
[UTIL][UPG] buildbldr
Build Image System:
This function, have a my Kitchen.
Ultra Kitchen Edition - ROM Builder for Toshiba TG01
Modyfications SYS Directory
Remove TimeBomb:
Open file *.rgu from location ->SYS/Shell/, and remove two keys from this registry:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\DeviceBeta]
"Today"="Beta"
"Expiry"="Expires: %02d/%02d/%04d"
[HKEY_LOCAL_MACHINE\Software\Microsoft\Shell\DeviceBeta]
"About"="- BETA"
Now, Go to location -> SYS/Shell/, open file form module shell32.exe/S000 in HexEditor.
Search string 02 EB 7D 3E, and in both instances 7D change to BB.
from:
Code:
02 EB 7D 3E
to:
Code:
02 EB BB 3E
Remember, this sequence occurs twice
Thanks for Camelio
good idea, may be i'll try to understand something and build an italian version too, even if we are quit lucky with our tg01 'cause it's no brand at all.
Thanks for your great job with developement
Hey Nokser do you create wm6.1 rom for tg01?
Nokserze can you writa Polish version too?
here or in pdaclub forum, but I wont to understand anything, so it's more simple in our's language
Thanks for your job
Yes, of course
When you will to make this tourial? or you can write the tourial for stabil oem's now I want to make a rom but i can't create a stabil oem or a oem that's works... or you can tell me how i must put the oem.
Greats ALcAtRas
I give all my work in this, but first I must port WM6.5.5
Nokser, could we use the information you have gained about our device to port android?
Wm first, then we'll see Android
Nokser said:
Wm first, then we'll see Android
Click to expand...
Click to collapse
You think that is posible?There are a lot of people ho want that.
Everything is possible, but we shall see
Is this guide close to completion or has this been forgotten about?
I not forget.... I must gen. all options build structure ROM
Nokser said:
I not forget.... I must gen. all options build structure ROM
Click to expand...
Click to collapse
MAny of us are waiting for your light...
I know My friend
Small Update Thread
Nokser said:
Small Update Thread
Click to expand...
Click to collapse
Very good: I'm waiting for the next update impatiently. Do you know a good general tutorial, not device specific?
super_sonic said:
Very good: I'm waiting for the next update impatiently. Do you know a good general tutorial, not device specific?
Click to expand...
Click to collapse
You'll see ... if i end this tutorial
@Nokser:Can you help us to unlock t01a .It likes tg01 but it don't have code for unlocking .
Please...
Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Jaskaran498 said:
Hi
I just changed some stuff like images in a kernel using Android Kernel Kitchen 0.3.1.
Now I wanna test my changes.
My questions is->
What are worst case scenarios possible?
I am ready to go for boot loops and etc. but are there any consequences that may cause real hard brick of my phone? (Like---> it will never start again! or you need to take it to service center for repair!)?
Click to expand...
Click to collapse
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Lekensteyn said:
What you can expect are boot loops, inability to get even see the boot splash, non-working wifi/ USB / touch / camera/ anything that needs a driver, random reboots. Personal experience: yesterday I was playing with changing part of the initramfs without changing the whole boot.img. It turns out that I needed to update the header size and checksum. Without this, it would hang for some seconds and then reboot (or not start at all). This was all fixable from recovery.
What can happen if you are not careful is a brick because you flash the wrong partition. Otherwise, you can always enter recovery mode and flash the kernel (for the i9300, it is mmcblk0p5). If you are not sure, look for the magic ANDROID! header:
Code:
# dd bs=64 count=1 if=/dev/block/mmcblk0p5 2>/dev/null | hexdump -C
00000000 41 4e 44 52 4f 49 44 21 80 bc 44 00 00 80 00 40 |[email protected]|
00000010 2e 1e 05 00 00 00 00 41 00 00 00 00 00 00 f0 40 |[email protected]|
00000020 00 01 00 40 00 08 00 00 00 00 00 00 00 00 00 00 |[email protected]|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040
So, the absolute worst-case scenario is when you accidentally flash the wrong partition. If you picked your EFS partition and do not have a backup, then your IMEI and stuff are gone.
Note: be sure not to wipe your recovery partition (mmcblk0p6), that requires you restore the recovery using download mode (I have not experienced this yet).
Click to expand...
Click to collapse
Kk, thanks.
But what do i do if it does not start at all like u said (what i want is that it should at least be able start in recovery or download if possible).
Since its my first time messing with kernel, i am total n00b then
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Lekensteyn said:
If it cannot proceed to the "normal" boot, then get into recovery by holding Volume Up + Power + Home for ten seconds while booting (I usually do that when I see the Samsung logo end release when it has restarted, showing the logo again (about ten seconds).
From there, use Install from zip (if you have a "update zip" that contains boot.img and some metadata) or (what I do) use adb push to put the image in /tmp/. Then use dd to write the boot image. Example (I use Linux):
Code:
laptop$ adb push boot-new.img /tmp/boot.img
laptop$ adb shell
# cat /tmp/boot.img > /dev/block/mmcblk0p5
Just in case of hardware failure, I also verify the md5sum:
Code:
laptop$ md5sum boot-new.img
laptop$ du -b boot-new.img # determine file size, say 1234
(android) # dd if=/dev/block/mmcblk0p5 bs=1234 count=1 | md5sum
The two outputs must match, otherwise something went wrong (unlikely, but still).
Click to expand...
Click to collapse
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Unless you do really stupid things like overwriting /dev/block/mmcblk0 or other partitions on http://cleanimport.xda/index.php?threads/2362743/, you will be safe.
Jaskaran498 said:
I know all this but what i m saying is that can there be conditions where neither i will be able to boot recovery nor download (even by volume+power+home method)?
Click to expand...
Click to collapse
Recovery has it's own kernel. It doesn't use the one you're modifying
-----------------------
Sent via tapatalk.
I do NOT reply to support queries over PM. Please keep support queries to the Q&A section, so that others may benefit
Scroll down for recent updates;
Has anyone ever heard more from h311sdr0id about his post (see here) to get more info about this "state" that allows you to flash MDK over ME7 in Odin? I'm curious to see if we can use that state, maybe in QDL mode to somehow either push an image to the phone or communicate with it using some methods/commands that E:V:A refers to on this page and a few pages after and before. It's also possible that we then might be able to use a modified unbrick.img (see here) to restore an MDK bootloader. So far those are the two ideas that I think have the best chance.
Also in this thread I started with the intention of compiling the entire stock firmware for the Dev edition (OYUAMDK), I mentioned at the bottom that when flashing the stock MDK restore Odin tar on an ME7 phone users usually get a "SW REV. CHECK FAIL: FUSED: 3, Binary: 1" message meaning that your current fuse counter in aboot is set to 3 but the binary your attempting to flash is set to 1 so the flashing attempt will fail and I'm willing to bet if you're on VRUDMI1 and you attempt to flash the MDK restore you will get a similar message but the FUSED: value will be set to 4, you can see the counter upped in this post from jeboo here. However, with flashing the dev OYUAMDK aboot file on S4's with a ME7 bootloader users will receive a "SECURE CHECK FAIL: aboot" message instead, I don't know if we might be able to use dev OYUAMDK aboot file and bypass the fused counter entirely, since the dev edition has an unlocked bootloader and the fuse is an efuse, so software enforced, not a hardware enforced qfuse. If anyone wants to go into more detail, or wants to expand on these ideas we I can expand on this info or we can collaborate ideas in the Dev discussion thread.
Other points to consider:
If you know how to use IDA pro, and can help with the base address of the binaries, that is probably our best bet to find a vulnerability in aboot, you can see jeboo and djrbliss discuss this a bit (here) and you can see Ralekdev show his findings here, also this gives the explanation of why you see the "custom unlock" boot screen that people constantly post about in the Q&A thread. Both of these threads along with djrbliss' blog discussing the S4 aboot vulnerability that lead to Loki (here), and exploiting the TrustZone (tz.mbn) on Moto's bootloaders (here) are good starting points in trying to find a new vulnerability.
If you know how to hexedit, then hexedit aboot.mbn from MDK, ME7, OYUAMDK, and MI1. You can see ME7 and MI1 are similar in both size and content, while MDK and OYUAMDK are more similar to each other in size and content. Obviously OYUAMDK differs from the others in the way it checks the recovery and boot partitions, (in djrbliss' blog on the S4 exploit he says "This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.") but we are able to flash all bootloader partitions from the OYUAMDK firmware restore Odin file I made except aboot, so if you have any ideas on how we might be able to exploit any of that, please feel free to share.
If you do hexedit a dd'ed partition (if you copy mmcblk0p6 from your phone to your pc) you will see that its padded with zeroes at the end. You have to cut the padded zeros from the dd'ed image in order for the partition to be registered as a signed partition in Odin, etc. To do this, use Linux, open a terminal and type
Code:
sudo apt-get install hexedit
then enter your password and hit enter. Then go to the folder that contains the partitions you want to hexedit (for instance type cd /home/Your user name folder/Desktop/S4partitionbackups/" where "your user name folder" is whatever your username is and "S4partitionbackups" is a folder you create on your desktop containing a backup of your partitions) If you don't have a back up of your partitions you can create them using something like the command below, substituting mmcblk0p6 and aboot.mbn with the partition(s) you are interested in.
Code:
adb shell su -c 'dd if=/dev/block/mmcblk0p6 of=/sdcard/backup/aboot.mbn'
then
Code:
adb pull /sdcard/backup/aboot.mbn /home/Your user name folder/Desktop/S4partitionbackups/
then
Code:
cd /home/Your user name folder/Desktop/S4partitionbackups/
Code:
hexedit aboot.mbn
Quick guide on Hexedit controls/keys
shift+> will take you to the end of the hex file
shift+< will take you to the beginning
page up/page down it will take you up a page and down a page respectively
ctrl+c you will exit the hex file without saving any changes
esc+t you will truncate the file at the current location
ctrl+x you will save the file with all changes you have done.
This is an example of a padded aboot.mbn, before hexediting, and prior to truncating the file a at the first "0" in the string "00 01" found between the end of the actual file and the padded zero's and repeating F's
View attachment 2353922
This is an example of a properly signed aboot.mbn after hexediting
View attachment 2353923
How to find start addresses
First you have to open the selected bootloader with a hex file editor and look at the header, converting for little endian you can find the start addresses and offsets
Code:
[B]sbl1.mbn = 0x2a000000[/B]
00000000 D1 DC 4B 84 34 10 D7 73 15 00 00 00 FF FF FF FF ..K.4..s........
00000010 FF FF FF FF 50 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] 40 72 01 00 ....P......*@r..
00000020 40 41 01 00 40 41 01 2A 00 01 00 00 40 42 01 2A @[email protected]*[email protected]*
00000030 00 30 00 00 01 00 00 00 04 00 00 00 FF FF FF FF .0..............
[B] sbl2.mbn = 0x2e000000[/B]
00000000 16 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2E[/COLOR] ................
00000010 40 51 02 00 40 20 02 00 40 20 02 2E 00 01 00 00 @[email protected] [email protected] ......
00000020 40 21 02 2E 00 30 00 00 12 00 00 EA 5F 00 00 EA @!...0......_...
00000030 62 00 00 EA 65 00 00 EA 68 00 00 EA 6B 00 00 EA b...e...h...k...
[B] sbl3.mbn = 0x8ff00000[/B]
00000000 18 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 F0 8F[/COLOR] ................
00000010 20 20 04 00 20 EF 03 00 20 EF F3 8F 00 01 00 00 .. ... .......
00000020 20 F0 F3 8F 00 30 00 00 D3 F0 21 E3 D3 F0 21 E3 ....0....!...!.
00000030 00 70 A0 E1 09 02 A0 E3 00 D0 A0 E1 DB F0 21 E3 .p............!.
[B] aboot.mbn = 0x88e00000 offset = 0x285[/B]
00000000 05 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 E0 88 [/COLOR] ................
00000010 10 56 14 00 10 25 14 00 10 25 F4 88 00 01 00 00 .V...%...%......
00000020 10 26 F4 88 00 30 00 00 06 00 00 EA F0 38 00 EA .&...0.......8..
00000030 F6 38 00 EA FC 38 00 EA 02 39 00 EA 08 39 00 EA .8...8...9...9..
[B] tz.mbn = 0x2a000000[/B]
00000000 19 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] ...............*
00000010 C4 3A 03 00 C4 09 03 00 C4 09 03 2A 00 01 00 00 .:.........*....
00000020 C4 0A 03 2A 00 30 00 00 09 00 00 EA 90 F2 9F E5 ...*.0..........
00000030 90 F2 9F E5 90 F2 9F E5 90 F2 9F E5 84 F2 9F E5 ................
[B] rpm.mbn = 0x00020000[/B]
00000000 17 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red] 00 00 02 00[/COLOR] ................
00000010 38 57 02 00 38 26 02 00 38 26 04 00 00 01 00 00 8W..8&..8&......
00000020 38 27 04 00 00 30 00 00 06 00 00 EA 1E 00 00 EA 8'...0..........
00000030 2C 00 00 EA 39 00 00 EA 46 00 00 EA 53 00 00 EA ,...9...F...S...
EDIT: 2/01/2014 - Updated OP to include where we're at
2/01/2014
1. Figuring out what Hellsdroid's method was - Unfortunately this seems unlikely as of now (figuring out what he did that is) On the other hand, @TMcGrath50 and I discussed a method we thought to be similar to his starting around here and then I learned how to use ida better as time went on and recently disassembled that I9505 S4 USB repair tool. I have not done a thorough analysis of the pseudocode yet though. But even so, this method has never been done before (as far as I know) and
in addition to assuming the information in the pic below is true, and we can in fact reset the emmc on our devices with Secure Boot 3.0 (would this be a way of getting around having to reset the Secure Boot bit in the pbl to "0"?) I still think this idea needs to be refined a bit before its worth exploring because some questions remain in regards to if it would even work in the first place. For example, when a JTAG solution was tested previously, the VRUAMDK aboot.mbn didn't flash on a device with VRUAME7 after all the partitions were wrote over with VRUAMDK partitions via JTAG, why? @jeboo may be able to help answer that.
Also, it was previously questioned whether or not the flash programmer (8064 hex) would need to be signed or not. As I have two S4's one thats working and one in QDL QHSUSB dload mode, in doing some recent testing through usb (S4 to S4) I was able to get some info back about my bricked S4, namely that I had sent it the wrong hex file ( see the last line here) because the dmesg and last_kmsg logs say something to the effect of "the the cpu clocks cannot start because its configured for the wrong device" and the last line from the my pastebin post says "8660" among other things as well.
Status - Unknown - More Research Required
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
2. Using a Developer edition S4 to unlock a retail S4 - So here's what we know, the dev kernel (boot.img) is flashable and will work with retail S4's, but the recovery.img and aboot will not. Flashing the dev recovery.img will succeed in Odin/Heimdall, but if you try to boot into recovery it will inform you that your device is "tampered" and and will void your warranty by setting the Knox warranty bit to 0x1. Before I discuss why aboot.mbn wont flash consider this; neither the Developer edition of the GS4 nor the Developer edition of the Note 3 has every received an OTA or a factory Odin tar. This is not by random chance. Every Developer edition owner has a unique MD5 for their aboot. If you couple this with the fact that Dev edition devices have retail stickers under their dev stickers, you will probably come to the conclusion that Samsung/Verizon/AT&T haven't released updates to dev devices because they would have to do it on a 'per device' basis, that or risk handing us a method to convert retail devices into developer edition devices. If the method by which Samsung uses device specific info to sign developer edition aboot partitions were discovered this may work, or if their method to determine if a device is a developer edition or consumer retail edition is similar to what Dan R (djrbliss) took advantage of then this could be a possibility.
3,4,5,6, coming up....updating...this will be a long post...advance warning.
Status - Possibly - More Research Required
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
Man... Samsung's really cracking down...
Sent from my SCH-I545 using XDA Premium 4 mobile app
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
WOW, this is news to me! It explains why I haven't seen him update his VS3 rom in awhile.
@Nicgraner
Sarcastic joke, or are you serious?
I noticed in the note 3 part of the forum a member started a petition to unlock the boot loader. Can someone start one or combine with the note 3 page?
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Surge1223 said:
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Click to expand...
Click to collapse
On that note, I thank you for developing the OYUAMDK FW. I have not tried it yet just waiting for another guinea pig or at least have a backup device to swap SIMs so that I can have something to use.
Samsung has their first Dev Conference today in San Francisco and hopefully there will be Devs there to get better insight on Samsungs position on ROMs and bootloaders etc...
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
jeboo said:
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
Click to expand...
Click to collapse
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Surge1223 said:
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Click to expand...
Click to collapse
So does this mean if I flash your OUYAMDK ODIN image my Dev Ed phone will think its OOB without custom unlock?
Theres a post in that thread where a dev owner achieved those results as well he only flashed a couple partitions, you can get more details there
Sent from my XT912 using xda app-developers app
thread cleaned of selling and or trading and the ensuing discussion.
Use Swappa.com for that.
neh4pres said:
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've always known Samsung to be like Google when it comes to consumer development. Google supports and encourages the freedom to modify Android, it being open source in the first place. Samsung doesnt mind, themselves; it's carrier security teams that require companies like Samsung to create their own methods of locking down the device for the average user. I'm quite impressed with the Knox bootloader and secure VM app. It may not be done anytime soon, but it can always be cracked. But, the fact that this code is so hard to modify, thanks to carriers, is actually a good thing.
Hey guys I am totally supporting this thread. Unfortunately i have no experience in this kinda stuff or else i would help. Good luck!
Much like most of us. Still out there Surge?
Sent from my SCH-I545 using xda app-developers app
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Surge1223 said:
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
No doubt... can't believe i left my G-Nex for this locked down thing... unfortunately i had to craigslist an upgrade and couldn't snag one of these when they first came out.
i am also in full support of this thread! running stock MJ7 never rooted my phone once, i have taken all the OTAs i'm really crossing my fingers that someone can break this thing so i can finally root and install a stock google rom, i hate TW so much! with all the headache with safestrap and junk on the MI1 i was not wanting to root my device just to have a half assed recovery.
Does it mean anything that my S4 is still showing unlocked and custom? Should it still show that even if it is in fact locked?
In the spirit of the old TriangleAway here is how you can make the "FC N" disappear from your unlocked bootloader screen. The N is a number that gets bumped every time you "fastboot flash". This method requires a root shell, if you have busybox installed (e.g. from the Magisk module) it can done 100% on phone. Could help you out if you ever need warrantee service, or just don't like seeing the bootloader count how many times you've messed with the phone.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -g 1 param.dd > param.xxd
Now use an editor (vim, nano, whatever) to look for this line in the file:
Code:
00003420: 00 00 00 00 01 00 00 00 01 00 00 00 17 00 00 00 ................
The flash counter is stored in the first non-zero bytes. Change them to zero like this:
Code:
00003420: 00 00 00 00 00 00 00 00 01 00 00 00 17 00 00 00 ................
Finally, flash the partition back, and voila, the "FC" line is gone from the bootloader. Note, these steps would have to be repeated every time you fastboot flash something.
Code:
OnePlus7TProNR:/sdcard # dd if=/dev/block/by-name/param of=param.dd
2048+0 records in
2048+0 records out
1048576 bytes (1.0 M) copied, 0.017794 s, 56 M/s
# xxd -r param.xxd > param-0.dd
# dd if=param-0.dd of=/dev/block/by-name/param
Wait....so does this get rid of the unlocked bootloader screen altogether?
lendawg said:
Wait....so does this get rid of the unlocked bootloader screen altogether?
Click to expand...
Click to collapse
No. Once you've used a "fastboot flash" command, you'll see a line on the bootloader/fastboot screen that says "FC 1".
If you fastboot flash something else, it increases to "FC 2" and so on. I think it persists even if you re-lock the bootloader as an indicator to the manufacturer and carrier that you've messed with your phone, and how many times.
This technique will make that counter go away, making it easier to re-lock the bootloader and make the phone appear unmodified, in case you ever need warrantee service.
There used to be a tool called "Triangle Away" that did something similar a few years ago, but it isn't supported anymore. But this technique does the same thing, you can read more about it here:
https://forum.xda-developers.com/galaxy-s2/orig-development/2014-01-15-triangleaway-v3-26-t1494114
This is just to remove the counter . Any warranty work will probably still be denied seeing you phone is on record as unlocked bootloader when you submit for the unlock.bin. And I'm sure the well I got the unlock.bin but never used it line will not work lol
Hello,
I was wondering if anyone has managed to get this working on the Realme GT as I wanted to look at the carrier policy for my phone, as i've edited the oneplus one successfully.
But was having issues on this one, doesn't seem to recognise the phone to connect to EFS.
Yes. I got it working (on c15 eu). I was testing the same method I used on my poco f3 and it works the same way.
I'm assuming you're rooted.
If so, while usb debugging and usb transfer files mode are on , use the commands:
adb shell
su
setprop sys.usb.config diag,diag_mdm,adb
This should create two new entries in device manager with a yellow icon (faulty driver). You now need to update the driver. The best way of explaining this is to link to a youtube video. It's in turkish and for the mi10t but it works for other phones. Here it is at the correct timestamp. But written in steps it's:
Right click on the device and update driver.
Browse my computer for drivers.
Pick from a list of available drivers from my computer.
Ports (COM and LPT)
"qualcomm incorporated" and "qualcomm hs-usb android diag 9022".
Do this for both entries. They should now both be named something like "qualcomm hs usb diag 9022 (COM6)" in the ports (COM & LTP) section in device manager (each has a different port number for me).
Anyway, after that, the phone shows up in qpst.
Good luck.
Awesome, will give that a go!
joebrit said:
Yes. I got it working (on c15 eu). I was testing the same method I used on my poco f3 and it works the same way.
I'm assuming you're rooted.
If so, while usb debugging and usb transfer files mode are on , use the commands:
adb shell
su
setprop sys.usb.config diag,diag_mdm,adb
This should create two new entries in device manager with a yellow icon (faulty driver). You now need to update the driver. The best way of explaining this is to link to a youtube video. It's in turkish and for the mi10t but it works for other phones. Here it is at the correct timestamp. But written in steps it's:
Right click on the device and update driver.
Browse my computer for drivers.
Pick from a list of available drivers from my computer.
Ports (COM and LPT)
"qualcomm incorporated" and "qualcomm hs-usb android diag 9022".
Do this for both entries. They should now both be named something like "qualcomm hs usb diag 9022 (COM6)" in the ports (COM & LTP) section in device manager (each has a different port number for me).
Anyway, after that, the phone shows up in qpst.
Good luck.
Click to expand...
Click to collapse
Worked perfectly. Thanks. Have you played about to unlock any bands?
unparalleled82 said:
Worked perfectly. Thanks. Have you played about to unlock any bands?
Click to expand...
Click to collapse
No. I haven't tried anything qpst wise with my gt yet. I'm not an expert but I thought you could only activate new bands if the hardware shipped with them enabled but there's an artificial carrier based policy/limitation that qpst could change. I think there's guides out there...
My interest was in locking my phone to a certain tower (pci) for better speeds. Unfortunately, I tried this on my poco f3 a while ago but it didn't work. I used these instructions.
I basically created a file in efs explorer (nv/item_files/modem/lte/rrc/csp/pci_lock)
with the pci hex code inside but it didn't have the right effect. I think that nv item might be outdated.
Yeah the only PCI band locking apps, I've seen are really expensive paid ones, so it can be done somehow.
Network signal guru does band locking and PCI locking on the paid version of the app.
Would be interested in knowing if you actually get it working.
unparalleled82 said:
Would be interested in knowing if you actually get it working.
Click to expand...
Click to collapse
Use the following at your own risk. Make a backup of your efs in qpst (start clients, software download, backup). Having said that, I've used this method successfully to lock the pci and earfcn. It relies on an nv item file:
/nv/item_files/modem/lte/rrc/efs/cell_restrict_opt_params
Navigate to:
/nv/item_files/modem/lte/rrc/efs/
If there is already a file called cell_restrict_opt_params you can make a backup and delete it as we will be replacing it.
Note down your desired earfcn and pci. I'll use earfcn = 500 and pci = 600 as an example.
Go to this hex converter and convert the earfcn and pci values (earfcn = 01F4 and pci = 0258).
Now create a hex file called cell_restrict_opt_params (you can use this program) in the following format:
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 F4 01 00 00 58 02 00 00 00 00 00 00
00 00 00 00
It should be 36 bytes. The 21st and 22nd byte should be the earfcn hex (backwards) with the 25th and 26th bytes being the pci hex (backwards). You can then transfer the file from your pc to the efs folder.
If you want to lock the earfcn only, it's the following format:
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 F4 01 00 00
F4 01 00 00
You will probably have to restart for the changes to take effect. Delete the file if you want to go back to the original state.
Good Luck.