Yesterday i brick my phone when try flash this beta TSS ROM in my X02T
http://forum.xda-developers.com/showthread.php?t=657694&page=3
Soo after fail i try with anothers ROMS too, like Mod-TG01TSS01.7z, Mod-TG01TSS02.7z (flash error, say invalid file), TG01TSS01.7z, TG01TSS02.7z (flash error, say invalid file), T01A_to_SP50_wm65.tsd, T01A_to_SP50_wm65-theduyet.enc and TG01WP-WM6.5-Orange-UK (flash error, say invalid file).
I still can use the SD downloader, i can flash "any" ROM whith pin method,
Before i brick my phone i make a RAW file of my phone and there is here:
http://cid-5bf4bd469b8aef18.skydrive.live.com/browse.aspx/X02T
txt is here:
------------------------------------------------------------------------------------
9.63M (0x9a0000) DSK1:
| 9.62M (0x99f000) Part00
423.00M (0x1a700000) DSK2:
| 1.62M (0x19f000) Part00
| 3.75M (0x3c0000) Part01
| 159.88M (0x9fe0000) Part02
| 257.75M (0x101c0000) Part03
7.42G (0x1daf80000) DSK3:
| 7.42G (0x1dab80000) Part00
STRG handles:
handle#0 8dda3d4a 7.42G (0x1dab80000)
handle#1 6e1e7b2e 257.75M (0x101c0000)
handle#2 ee1ed89e 159.88M (0x9fe0000)
handle#3 4e1ed87a 3.75M (0x3c0000)
handle#4 4e1ed832 1.62M (0x19f000)
handle#5 ee4ac72e 9.62M (0x99f000)
disk 8dda3d4a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 6e1e7b2e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk ee1ed89e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 4e1ed87a
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk 4e1ed832
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
disk ee4ac72e
0 partitions, 0 binary partitions
customerid=00000000 uniqueid= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------------------------------------------------------------
Please someone could help me Revive my phone !!!
Thanks alot
Toshiba make a new update for X02T, a small update i think with SMS, this file is X02T_from_SP00_to_01_000.tis, soo is TIS file, maybe this file have the key for revive my phone.
link is here:
http://toshibamobile.com/cgi-bin/softbank/x02t/update/uprom.cgi?sp=00
or
http://update.toshibamobile.com/update/x02t/sp00/X02T_from_SP00_to_01_000.tis
You flashed TG01TSS01.7z, don't you?
Your situation is the same as "xandetonetti".
Please the following Pin method.(from Orange in T01A case)
--------------------------------------------
This Pin method is short Pin 1 and Pin 2.
And, You can The power button pushed with the state maintained.
Then, Your T01A screen displays your ROM after five seconds.
--------------------------------------------
Did it work? If not, can you try as naxt.
We now know that the TSS Encryption Key of X02T is 44460046.
However, The Encryption of your device is tsw,
because you flashed tsw bootloader ROM into your X02T,
You can try the following ROM.
*Official Orange UK ROM
http://www.toshiba-europe.com/mobile/Images/TG01WP-WM6.5-Orange-UK.zip
[TG01WP_5005000176.tsw → TG01.tsw]
*Official docomo JP ROM (T01A_to_SP50_wm65.tsd is extracted by zip. )
http://update.toshibamobile.com/update/t01a/wm65/T01A_to_SP50_wm65.exe
--------------------------------------------------
tgtool -t01a -sp T01A_to_SP50_wm65.tsd os.nb.payload
tgtool -t01a -mp os.nb.payload T01A_to_SP50_wm65.tsd T01A_to_SP50_wm65.bin
--------------------------------------------------
You can download TSW TOOLS by cotulla from
this URL(http://cotulla.pp.ru/Misc.html), and
convert bin to tsw by this tool in TG01 mode.
[T01A_to_SP50_wm65.tsw → TG01.enc]
You can flash those ROM, maybe.
yamadori said:
You flashed TG01TSS01.7z, don't you?
Your situation is the same as "xandetonetti".
Please the following Pin method.(from Orange in T01A case)
--------------------------------------------
This Pin method is short Pin 1 and Pin 2.
And, You can The power button pushed with the state maintained.
Then, Your T01A screen displays your ROM after five seconds.
--------------------------------------------
Did it work? If not, can you try as naxt.
Click to expand...
Click to collapse
Thanks for you quick reply friend. i have 2 news!!
1 - The good news, is the short Pin 1 and 2 work!!! phone is alive again thanks very much friend..
2 - Bad news, my last try i flash the T01A ROM, soo my phone is DOCOMO now, but in english, and the TG01TSS01.7z dont flash anymore, say File is invalid!!!
I un7zip and rename for TG01.enc, after copy to PRG folder (this work in first time, but dont work more, maybe because i flash T01A for last)
But i need short the pin 1 and 2 any time when reset right? Soo how i can puth the SIM card, without revome the batery and Short pins 1 and 2?
1
I finaly able to insert the SIM card to phone after short pin 1 and 2, but now WM ask me for a Password for unlock my SIM? have you any idea what is this? or any way for flash the TG01TSS01.7z again?
2 - Bad news, my last try i flash the T01A ROM, soo my phone is DOCOMO now, but in english, and the TG01TSS01.7z dont flash anymore, say File is invalid!!!
Click to expand...
Click to collapse
Is the bootlogo of your X02T docomo?
If yes, the Encryption of your device is tsd,
You can flash tsd ROM and can not flash tss ROM.
You can try T01A_to_SP50_wm65-theduyet.tsd ROM.(rename to TG01.enc)
And, is the Pin method both Docomo and Orange ROMs necessary for
your X02T?
If yes, We can not do anything. Because we only have bootloder of
TG01 and T01A, not have X02T.
Sorry.
I finaly able to insert the SIM card to phone after short pin 1 and 2, but now WM ask me for a Password for unlock my SIM? have you any idea what is this? or any way for flash the TG01TSS01.7z again?
Click to expand...
Click to collapse
You must be use SoftBank SIM, or delete SIMUnlockP.exe in windows folder.
yamadori said:
Is the bootlogo of your X02T docomo?
If yes, the Encryption of your device is tsd,
You can flash tsd ROM and can not flash tss ROM.
You can try T01A_to_SP50_wm65-theduyet.tsd ROM.(rename to TG01.enc)
And, is the Pin method both Docomo and Orange ROMs necessary for
your X02T?
If yes, We can not do anything. Because we only have bootloder of
TG01 and T01A, not have X02T.
Sorry.
You must be use SoftBank SIM, or delete SIMUnlockP.exe in windows folder.
Click to expand...
Click to collapse
Yes the bootlogo is DOCOMO and the T01A ROM work good, but i only can flash ROM with .tsd, when i try with .enc say invalid file.
i will try delete this file for skip the password.
i cant find SIMUnlockP.exe in windows folder, have another way for evade the password?
With my Hermer i have a program called "Connection Setup" for easy config the phone, i just choise japan and Vodafone, you know where i can find this program or another like this?
and if my phone now is tsd Encryption, why o still need short pin? if i rename the TSS file for tsd i can turn she back to SoftBank?
Thanks very mush...
eekthecat said:
i cant find SIMUnlockP.exe in windows folder, have another way for evade the password?
With my Hermer i have a program called "Connection Setup" for easy config the phone, i just choise japan and Vodafone, you know where i can find this program or another like this?
and if my phone now is tsd Encryption, why o still need short pin? if i rename the TSS file for tsd i can turn she back to SoftBank?
Thanks very mush...
Click to expand...
Click to collapse
It seems that you have flashed a english rom on X02T sucessfully.
Congratulations！
i cant find SIMUnlockP.exe in windows folder, have another way for evade the password?
Click to expand...
Click to collapse
Your X02T can use only softbank SIM, because we do not find
the method of X02T SIM unlock as well as T01A.
and if my phone now is tsd Encryption, why o still need short pin? if i rename the TSS file for tsd i can turn she back to SoftBank?
Click to expand...
Click to collapse
No. The bootloader of X02T is not the same as T01A it.
There is no ROM of X02T bootloader yet. Therefore, method of PIN(1&2) is needed in ROM of T01A and TG01 bootloader.
By the way,
I will pass you this ROM, because your device bootloader is docomo.
http://www.mediafire.com/?qmznk0ygzxj
This ROM might be able to use "X02T_from_SP00_to_01_000.tis", or not.
Please enjoy it.
Thanks very much friend, but i think the file is corrupted, i try download 3 times, and get a error when try un7zip. Could you upload the ROM again plz
Thanks very much friend, but i think the file is corrupted, i try download 3 times, and get a error when try un7zip. Could you upload the ROM again plz
Click to expand...
Click to collapse
Please delete Cash and do download again.
And, please do unzip by this tool http://www.7-zip.org/.
I can not upload it because I can't use Broadband today.
yamadori said:
Please delete Cash and do download again.
And, please do unzip by this tool http://www.7-zip.org/.
I can not upload it because I can't use Broadband today.
Click to expand...
Click to collapse
Cash is deleted, i try with another with IE, firefox and Freedownload manager, also use 7zip for unzip, but the file is realy corrupted.
Don't worry if you cant upload again today, i will wait thanks alot.
upload again.
http://www.mediafire.com/?rwnm2wzjrnj
yamadori said:
upload again.
http://www.mediafire.com/?rwnm2wzjrnj
Click to expand...
Click to collapse
Thanks for upload friend, now work fine, but i cant flash this ROM. SD Downloader say : File Open Error!!!
I copy to prg folder, and try with .enc and .tsd, but both get the same error.
I still can flash ROM's like " [ROM][ENG] 6.5.5 (23563)+Sense 2.5(2011) v0.012.2 (26/04/10) Radio 5005.1600.05" but my SIM Card is SoftBank and i think the ROM Radio another, because i cant connect with SoftBank services.
OBS: I use the Convetion too for convert TG01 rom to T01A ROM
Now i able to flash you ROM, just rename the file for TG01WP_00.tsd, this is with Docome bootlogo, with my SoftBank Japanese Windows, but my i still can't use my SIM Softbank, windows report a SIM error and the Windows power off after seconds.
If i start the phone without my SoftBank SIM, widows work fine (in japanese, and with DOCOMO bootlogo) but if i start with SIM card, windows report something about SIMUnlockP and dont connect, after secs power off.
If i can only flash ROMS with TSD, is because my bootloader is Docomo now right? this make my phone only work with DOCOMO SIM'S?
hi,eecat, I have the same problem as you. I flashed a chinese rom to x02t, with pin 1 and 2 shorted method, I can boot the phone, otherwise, green light sparkle once then off. after the Chinese wm65 started, I inserted the softbank sim card, no signal. I am wondering have you solved that problem or do you have any idea to flash back to official softbank rom that I can use softbank sim card as normal? your Prompt reply will be highly appriciated.
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?
I think it's time to get this party started.
There is hope ->> Initial Analysis
I have built a spreadsheet that takes a hexdump of the GPT tables and decodes them.
This provides the means of generating the Partition.xml and Rawprogram.xml.
Also one can learn alot by analyzing the GPT.
With the ability to generate the partition.xml it can then be converted to partitions.txt that the Dragon-Board db_boot_tools (mksdcard) can be used to burn the SD Card.
The ability to build the rawprogram.xml also provides us the opportunity to build EDL roms and flash them using the emmcdl.exe or the QDL download tool for dragonboard.
This means we can build unbrick roms / anything we want and flash it in edl mode unrestricted.
Currently there is available the Factory Samsung EDL Recovery Files for Boot Loader Rev 2.
https://www.needrom.com/download/unbrick-samsung-qualcom-9008-files/
I have looked at them and they are legitimate.
Analyzing the GPT tables included in the EDL package I can determine that these are Standard Qualcomm Bootloaders that operate on a Standard QC partition table.
My theory is that being standard Qualcomm Images the bootloader is unlockable by standard Qualcomm method.
The board_info partition. As seen here.
https://alephsecurity.com/2018/01/22/qualcomm-edl-2/
Another great resource is everything for the dragonboard 820c. Its the same chipset.
A ton of available source code is at our disposal.
In a nutshell because i dont have a lot of time to get into details at the moment.
I ran my first SD Card Test.
Simply burned the Dragonboard 820c SD Rescue image to a sd card.
https://www.96boards.org/documentat...board820c/installation/board-recovery.md.html
To my surprise if you insert this SD Card into the device and boot into download mode.
You will see FRP=OFF.
This proves my theory that the possibility of booting a full system on a sd card is real.
The sd card is read early in the boot chain.
I have to investigate and see exactly how this is setting frp off.
This partition table has the FRP partition.
The note 8 uses the persist partition for the frp switch.
So how the sd card is turing FRP off is the question I am working on answering at the moment.
I can conclude.
The device is definitely reading partitions off the SD Card.
It is beating the FRP lock out of the box.
This means either the stock bootloaders have functionality built in to look for the FRP partition that normally is not present on our devices. Meaning the stock bootloaders can read other partitions of the sd card.
Or somewhere in the boot chain one or more of the dragonboard bootloaders are executing off the sd card.
If that is the case Hope is very Great for us. Dragonboard has available the LK source code that we can modify and build.
Dragonboard also has pre-compiled bootloaders specifically for booting on sd card that we can use.
Also the samsung bootloaders in the EDL files are very promising.
If we can build the aosp system to go with the edl bootloaders ( If they are unlockable ) were golden.
If the Dragonboard Bootloaders are executing on the sd card were even more golden.
If this is the case we can even use the dragonboard 820c AOSP build ( includes sources )
All we really should need to change would relate to hardware differences.
Seems crazy but there is no rational explanation as to how the sd card turns FRP off other than the possibility of somewhere in the boot chain the drangonboard BL is executed on the sdcard.
Unless like i said the samsung bootloaders have the stock qualcomm functionality as well.
Either way you look at it. We defeated the FRP protection by flashing a sdcard and booting with the sdcard in the device. That is enough proof in itself that there is hope.
It would be superb if some of the other Samsung Devs, Like the samfail team would climb on board to work on some of this. I am very skilled in some aspects and in other aspects i could use some help.
Either way give me a couple months and we will be there.
My only question is has anyone ever been actually paid by Samsung for finding Exploits?
From what ive read on there site it says $200,000 K or more for a bootloader unlock.
Makes me wonder if I should be sharing this information with anyone.
But money aside...thats what samsung wants. There using greed against us. They don't want us to work together.
I will be getting into some very deep presentations of my work as time provides.
That way the community can learn and help on this exciting journey.
Damm I still can't believe it turned FRP off. :silly:
Just goes to show ya. Don't doubt it till you try it no matter how far out it may seem. :highfive:
Always follow A String Theory
No pun intended.
A lot can be determined by running the strings command on a elf file. It's sorta google for developers.
Lets take a quick Look.
From the xbl.elf in the edl package.
This is our boot sequence.
SEC Image Loaded, Delta
XBLRamDump Image Loaded, Delta
PMIC Image Loaded, Delta
APDP Image Loaded, Delta
QSEE Dev Config Image Loaded, Delta
QSEE Image Loaded, Delta
QHEE Image Loaded, Delta
RPM Image Loaded, Delta
STI Image Loaded, Delta
ABL Image Loaded, Delta
APPSBL Image Loaded, Delta
DDR Training Image Loaded, Delta
What can we boot from.
/home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_pbl_v2.c
PBL, Start
bootable_media_detect_entry, Start
bootable_media_detect_success, Start
/home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_hash.c
DDR Frequency, %d MHz
PBL Patch Ver: %d
Core 0 Frequency, %d MHz
Boot Interface:
NAND
eMMC
SDCARD
None
Unknown
Locked or Unlocked
/home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/QcomPkg/XBLLoader/boot_logger.c
Secure Boot:
%s @ 0x%08x = 0x%016llx
%s @ 0x%08x = 0x%08x
Boot Config
JTAG ID
OEM ID
Serial Number
OEM Config Row 0
OEM Config Row 1
Feature Config Row 0
Feature Config Row 1
Raw PTE Row 3
Raw PTE Row 0
Load addresses. Re-Base if you have an IDA.
/home/dpi/qb5_8814/workspace/GREATQLTE_USA_SINGLE/nhlos/boot_images/Build/Msm8998LA_Core/RELEASE_CLANG38LINUX/AARCH64/QcomPkg/XBLCore/XBLCore/DEBUG/Sec.dll
[Config]
Version = 3
MaxMemoryRegions = 64
[MemoryMap]
# EFI_RESOURCE_ EFI_RESOURCE_ATTRIBUTE_ EFI_MEMORY_TYPE ARM_REGION_ATTRIBUTE_
#MemBase, MemSize, MemLabel(32 Char.), BuildHob, ResourceType, ResourceAttribute, MemoryType, CacheAttributes
#--------------------- DDR -----
0x80000000, 0x05800000, "Kernel", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
0x86000000, 0x00200000, "SMEM", AddMem, MEM_RES, UNCACHEABLE, Reserv, UNCACHED_UNBUFFERED_XN
0x94000000, 0x09400000, "DXE Heap", AddMem, SYS_MEM, SYS_MEM_CAP, Conv, WRITE_BACK_XN
0x9D400000, 0x02400000, "Display Reserved", AddMem, MEM_RES, SYS_MEM_CAP, MaxMem, WRITE_BACK_XN
0x9F800000, 0x00200000, "FV Region", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FA00000, 0x00200000, "ABOOT FV", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
0x9FC00000, 0x00300000, "UEFI FD", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
0x9FF00000, 0x0008C000, "SEC Heap", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FF8C000, 0x00001000, "CPU Vectors", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
0x9FF8D000, 0x00003000, "MMU PageTables", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FF90000, 0x00040000, "UEFI Stack", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FFD0000, 0x00027000, "DBI Dump", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
0x9FFF7000, 0x00008000, "Log Buffer", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
0x9FFFF000, 0x00001000, "Info Blk", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
[RegisterMap]
#--------------------- Other -----
0x14680000, 0x00040000, "IMEM Base", NoHob, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
0x146BF000, 0x00001000, "IMEM Cookie Base", AddDev, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
0x16000000, 0x01000000, "QDSS_STM", AddDev, MMAP_IO, INITIALIZED, Conv, NS_DEVICE
#--------------------- Register --
0x00620000, 0x00020000, "UFS_RUMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x00070000, 0x00010000, "BOOT_CONFIG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x00100000, 0x000B0000, "GCC CLK CTL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x00778000, 0x00008000, "RPM MSG RAM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x00780000, 0x00007000, "SECURITY CONTROL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x00790000, 0x00010000, "PRNG_CFG_PRNG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010A3000, 0x00001000, "MPM2_SLP_CNTR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010AA000, 0x00001000, "MPM2_TSENS0", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010AB000, 0x00001000, "MPM2_TSENS0_TM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010AC000, 0x00001000, "MPM2_PSHOLD", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010AD000, 0x00001000, "MPM2_TSENS1", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x010AE000, 0x00001000, "MPM2_TSENS1_TM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x01C00000, 0x00007000, "PCIE WRAPPER AHB", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x01DA0000, 0x00020000, "UFS UFS REGS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x01DC0000, 0x00040000, "CRYPTO0 CRYPTO", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x01FC0000, 0x00026000, "TCSR_TCSR_REGS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x03400000, 0x00C00000, "TLMM CSR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x08000000, 0x02800000, "PMIC ARB SPMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x05065000, 0x00009000, "GPUCC", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x06000000, 0x00100000, "QDSS_QDSS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x06400000, 0x00200000, "HMSS_QLL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0A800000, 0x0011B000, "USB30_PRIM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0A920000, 0x00010000, "USB_RUMI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0C000000, 0x00200000, "PERIPH_SS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0C800000, 0x00800000, "MMSS", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x17900000, 0x00030000, "QTIMER", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x17A00000, 0x00010000, "APCS_GIC500_GICD", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x17B00000, 0x00100000, "APCS_GIC500_GICR", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x17800000, 0x00100000, "APCS_CC", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x1B000000, 0x01000000, "PCIE WRAPPER AXI", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0502A000, 0x00002000, "GPMU_BLOCK0", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x05026000, 0x00002000, "GPMU_DRAM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x05030000, 0x00002000, "GPU_ISENSE", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
[ConfigParameters]
# Update count if more than default 30 entries #
ConfigParameterCount = 52
So at a minimum we can see that this bootloader can boot from sd-card. The address table shows where things are loading in memory. This is good for disassembling the elf files.
I really think the sd card can get us a way in.
The Goal
In the end this is the boot sequence we would like to see.
If you looked at the strings in the previous post you will recognize some of the information here.
================================================================================
Successful boot sequence
================================================================================
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00301
S - IMAGE_VARIANT_STRING=M8996LAB
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu68
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00076044 = 0x000001c9
S - JTAG ID @ 0x000760f4 = 0x4003e0e1
S - OEM ID @ 0x000760f8 = 0x00000000
S - Serial Number @ 0x00074138 = 0x2e8844ce
S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff
S - Core 0 Frequency, 1228 MHz
B - 0 - PBL, Start
B - 10412 - bootable_media_detect_entry, Start
B - 47480 - bootable_media_detect_success, Start
B - 47481 - elf_loader_entry, Start
B - 49027 - auth_hash_seg_entry, Start
B - 49129 - auth_hash_seg_exit, Start
B - 82403 - elf_segs_hash_verify_entry, Start
B - 84905 - PBL, End
B - 86955 - SBL1, Start
B - 182969 - usb: hs_phy_nondrive_start
B - 183305 - usb: PLL lock success - 0x3
B - 186294 - usb: hs_phy_nondrive_finish
B - 190442 - boot_flash_init, Start
D - 30 - boot_flash_init, Delta
B - 197548 - sbl1_ddr_set_default_params, Start
D - 30 - sbl1_ddr_set_default_params, Delta
B - 205509 - boot_config_data_table_init, Start
D - 200659 - boot_config_data_table_init, Delta - (60 Bytes)
B - 410713 - CDT Version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:0
B - 415410 - Image Load, Start
D - 22570 - PMIC Image Loaded, Delta - (37272 Bytes)
B - 437980 - pm_device_init, Start
B - 443744 - PON REASONM0:0x200000061 PM1:0x200000021
B - 480161 - PM_SET_VAL:Skip
D - 40016 - pm_device_init, Delta
B - 482083 - pm_driver_init, Start
D - 2928 - pm_driver_init, Delta
B - 488671 - pm_sbl_chg_init, Start
D - 91 - pm_sbl_chg_init, Delta
B - 495442 - vsense_init, Start
D - 0 - vsense_init, Delta
B - 505171 - Pre_DDR_clock_init, Start
D - 396 - Pre_DDR_clock_init, Delta
B - 509045 - ddr_initialize_device, Start
B - 512766 - 8996 v3.x detected, Max frequency = 1.8 GHz
B - 522373 - ddr_initialize_device, Delta
B - 522404 - DDR ID, Rank 0, Rank 1, 0x6, 0x300, 0x300
B - 526247 - Basic DDR tests done
B - 594994 - clock_init, Start
D - 274 - clock_init, Delta
B - 598349 - Image Load, Start
D - 4331 - QSEE Dev Config Image Loaded, Delta - (46008 Bytes)
B - 603808 - Image Load, Start
D - 5338 - APDP Image Loaded, Delta - (0 Bytes)
B - 612409 - usb: UFS Serial - 2f490ecf
B - 616801 - usb: fedl, vbus_low
B - 620431 - Image Load, Start
D - 55418 - QSEE Image Loaded, Delta - (1640572 Bytes)
B - 675849 - Image Load, Start
D - 2013 - SEC Image Loaded, Delta - (4096 Bytes)
B - 683413 - sbl1_efs_handle_cookies, Start
D - 457 - sbl1_efs_handle_cookies, Delta
B - 691892 - Image Load, Start
D - 14396 - QHEE Image Loaded, Delta - (254184 Bytes)
B - 706319 - Image Load, Start
D - 14061 - RPM Image Loaded, Delta - (223900 Bytes)
B - 721111 - Image Load, Start
D - 3233 - STI Image Loaded, Delta - (0 Bytes)
B - 727913 - Image Load, Start
D - 34709 - APPSBL Image Loaded, Delta - (748716 Bytes)
B - 762713 - SBL1, End
D - 680028 - SBL1, Delta
S - Flash Throughput, 94000 KB/s (2959024 Bytes, 31250 us)
S - DDR Frequency, 1017 MHz
Android Bootloader - UART_DM Initialized!!!
[0] BUILD_VERSION=
[0] BUILD_DATE=16:07:51 - Nov 17 2017
[0] welcome to lk
[10] platform_init()
[10] target_init()
[10] RPM GLink Init
[10] Opening RPM Glink Port success
[10] Opening SSR Glink Port success
[20] Glink Connection between APPS and RPM established
[20] Glink Connection between APPS and RPM established
[40] UFS init success
[80] Qseecom Init Done in Appsbl
[80] secure app region addr=0x86600000 size=0x2200000[90] TZ App region notif returned with status:0 addr:86600000 size:35651584
[100] TZ App log region register returned with status:0 addr:916d4000 size:4096
[100] Qseecom TZ Init Done in Appsbl
[120] Loading cmnlib done
[120] qseecom_start_app: Loading app keymaster for the first time
[150] <8>keymaster: ""KEYMASTER Init ""
[160] Selected panel: none
Skip panel configuration
[160] pm8x41_get_is_cold_boot: cold boot
[170] boot_verifier: Device is in ORANGE boot state.
[180] Device is unlocked! Skipping verification...
[180] Loading (boot) image (348160): start
[190] Loading (boot) image (348160): done
[190] use_signed_kernel=1, is_unlocked=1, is_tampered=0.
[200] Your device has been unlocked and cant be trusted.
Wait for 5 seconds before proceeding
[5200] mdtp: mdtp_img loaded
[5210] mdtp: is_test_mode: test mode is set to 1
[5210] mdtp: read_metadata: SUCCESS
[5230] LK SEC APP Handle: 0x1
[5230] Return value from recv_data: 14
[5240] Return value from recv_data: 14
[5250] Return value from recv_data: 14
[5260] DTB Total entry: 1, DTB version: 3
[5260] Using DTB entry 0x00000123/00000000/0x00000018/0 for device 0x00000123/00030001/0x00010018/0
[5270] cmdline: androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=orange androidboot.veritymode=enforcing androidboot.serialno=2f490ecf androidboot.baseband=apq mdss_mdp.panel=0
[5290] Updating device tree: start
[5290] Updating device tree: done
[5290] Return value from recv_data: 14
[5300] RPM GLINK UnInit
[5300] Qseecom De-Init Done in Appsbl
[5300] booting linux @ 0x80080000, ramdisk @ 0x82200000 (0), tags/device tree @ 0x82000000
[5310] Jumping to kernel via monitor
U-Boot 2017.11-00145-ge895117 (Nov 29 2017 - 10:04:06 +0100)
Qualcomm-DragonBoard 820C
DRAM: 3 GiB
PSCI: v1.0
MMC: [email protected]: 0
In: [email protected]
Out: [email protected]
Err: [email protected]
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
433 bytes read in 71 ms (5.9 KiB/s)
1: nfs root
Retrieving file: /uImage
19397184 bytes read in 2024 ms (9.1 MiB/s)
append: root=/dev/nfs rw nfsroot=192.168.1.2:/db820c/rootfs,v3,tcp rootwait ip=dhcp consoleblank=0 console=tty0 console=ttyMSM0,115200n8 earlyprintk earlycon=msm_serial_dm,0x75b0000 androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=orange androidboot.ver0
Retrieving file: /apq8096-db820c.dtb
38134 bytes read in 37 ms (1005.9 KiB/s)
## Booting kernel from Legacy Image at 95000000 ...
Image Name: Dragonboard820c
Image Type: AArch64 Linux Kernel Image (uncompressed)
Data Size: 19397120 Bytes = 18.5 MiB
Load Address: 80080000
Entry Point: 80080000
Specifically what we want to accomplish.
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00301
S - IMAGE_VARIANT_STRING=M8996LAB
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu68
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00076044 = 0x000001c9
S - JTAG ID @ 0x000760f4 = 0x4003e0e1
S - OEM ID @ 0x000760f8 = 0x00000000
S - Serial Number @ 0x00074138 = 0x2e8844ce
S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff
S - Core 0 Frequency, 1228 MHz
B - 0 - PBL, Start
B - 10412 - bootable_media_detect_entry, Start
B - 47480 - bootable_media_detect_success, Start
If we can set this the bootloader is unlocked.
Boot Config @ 0x00076044 = 0x000001c9
From our xbl.elf strings.
Secure Boot:
%s @ 0x%08x = 0x%016llx
%s @ 0x%08x = 0x%08x
Boot Config
JTAG ID
OEM ID
Serial Number
OEM Config Row 0
OEM Config Row 1
Feature Config Row 0
Feature Config Row 1
0x00070000, 0x00010000, "BOOT_CONFIG", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
BigCountry907 said:
This partition table has the FRP partition.
Click to expand...
Click to collapse
The actual FRP partition in this SD recovery image is empty. And so are a bunch of other ones; they all seem to be blanked out with 00s. Maybe they are used for mounting the images? But in that case, what would be responsible for mounting them? I think one of the partitions that actually has an ELF header might be worth looking at.
The sdcard image is for the dragonboard to boot into fastboot mode.
So you are correct. Most of the partitions are empty.
The bootloaders are present on the sdcard.
I havent determined if they are running or not.
The only byte that matters on the FRP partition is the last byte.
00 = FRP Lock Off
01= FRP Lock On.
If you install Liveboot then the log files on bootup are saved.
Looking in that log I can see the sdcard partitions are being mounted.
If you
cat /proc/mounts
You will see many are mounted.
This was just an initial test to see if the sd card would get read on boot.
It does so now im working on building a card with the V2 samfail installed.
My hope is to boot a full system off of the sdcard.
Then development can be done without touching the UFS.
If we can get the bootloaders to run off the sdcard as well this will open a huge door for us.
I will let you know how it goes with my next test.
The thing that is significant thus far is the fact that booting with the sdcard IS SETTING frp LOCK TO OFF.
The normal Samsung Note 8 partition scheme uses Persist and Persistent partition for setting the FRP on or off.
If both persist and persistent are ZERO then FRP = off.
So the stock bootloader will read partitions that are (whitelisted) and verified to be Qualcomm Unique GUID Type.
Possibly even boot a bootloader that is not signed by Samsung but signed by Qualcomm.
If Qualcomm signed bootloaders will run then we can actually compile sign and boot our own bootloader.
Here is how.
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard820c/guides/
Building the SD rescue image
The scripts to build the SD rescue image can be found here:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader-dragonboard820c.yaml,
where we defined the script parameters and variables
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard820c/builders.sh:
where the actual commands are being executed.
Same Chip so we can use the source code.
I will attach here the first revision of my GPT Decoder Spreadsheet.
It takes the GPT which is the UFS Partition Table and decodes it.
Once the GPT is decoded we can use it to make the following.
Rawprogram.xml >> used for flashing in EDL Mode like emmcdl.exe or dragonboard "QDL"
Partition.xml >> used for making GPT files and the Rawprogram.xml and is used by qualcomm tools like Ptool.py Msp.py ext.
Partitions.txt >> used for flashing sd cards or writable devices using mksdcard script.
So essentially the GPT is the foundation of everything. The GPT is what the samsung .PIT files write.
You can pull the GPT off the device using the shell.
Here are the commands.
The MAIN GPT. Tables
The main GPT is the first 24kb of each device block on the UFS (ie sda, sdb, sdc, sdd)
Code:
adb shell
su
dd if=/dev/block/sda of=/sdcard/gpt_main0.bin bs=1024 count=24
dd if=/dev/block/sdb of=/sdcard/gpt_main1.bin bs=1024 count=24
dd if=/dev/block/sdc of=/sdcard/gpt_main2.bin bs=1024 count=24
dd if=/dev/block/sdd of=/sdcard/gpt_main3.bin bs=1024 count=24
The BACKUP GPT. Tables
The backup GPT is the last 20kb of each device block on the UFS (ie sda, sdb, sdc, sdd)
So the start address of the backup gpt is total size in kb of disk - 20kb.
To get the skip= number you have to take the total kb of the disk and subtract 20 kb from it.
This is for the U2 bootloader.
Code:
adb shell
su
dd if=/dev/block/sda of=/sdcard/backup-sda-gpt.bin bs=1 skip=63916978176
dd if=/dev/block/sdb of=/sdcard/backup-sdb-gpt.bin bs=1 skip=4173824
dd if=/dev/block/sdc of=/sdcard/backup-sdc-gpt.bin bs=1 skip=4173824
dd if=/dev/block/sdd of=/sdcard/backup-sdd-gpt.bin bs=1 skip=62894080
We will be needing someone to pull the GPT tables from all the bootloader versions except for U2.
I am on U2 and this spreadsheet is for U2.
I will need the other GPT tables to build the unbrick for other bootloader versions.
Look at the spreadsheet and the different sheets in it.
You will get an Idea of how it works.
I use formulas and link to the pasted GPT tables to decode them.
This spreadsheet still needs work so some of the data is manually edited at this time.
But for U2 bootloader rev this spreadsheet is correct.
Use open office to use or look at this spreadsheet. << ITS FREE
Use 7z to unzip the files
NEW possibly very Exciting Discovery.
Don't get too excited because i need to verify but from what i see.
In the AP_N950USQS2BQK2_CL12461033_QB15680825_REV00_user_low_ship_MULTI_CERT_meta
There is a folder called meta-data.
In that folder there is a password protected zip called FOTA.
The password is fotatest1234
I see everything in there is to sign files.
Now what im thinking is related to my first ever android hack several years back.
By generating my own .pk8 and .pem keypair I figured out how to dump the publick key into the keyform used to verify the signature of ota zip packages to flash in a stock recovery.
By taking the key dump and replacing it in the recovery /res/keys.
The group of files in the above mentioned zip file is for signing packages and boot and recovery image.
I believe if I can find where the publick half of the keypair for verifying the boot signature I can replace it and sign my boot and recovery with my own keys. The bootloader still verifies the signature but it passes because its verifying my public half of the keypair against a file signed by my keypair.
I might know already where the certificate is. I need to pull out a old tool.
I wrote this shell script years ago for this very purpose. I think its broken slightly. I was working on it and never finished.
But if you know shell code the errors are easy enough to fix.
The setup will work. Its posted here.
https://drive.google.com/file/d/0B8jitdIyh2NtMHo4Q1ZLbFk3aEE/view
There are a couple of threads I wrote about it.
https://androidforums.com/threads/root-rom-recovery-r-d.975147/
Quick Ho to
make a folder in the home dir called auto-key
unzip the file in there
Signing the zip will work with this.
Just use the keys i sent along in the package.
Only thing is if the recovery.img is alot newer you might have to use the new boot tools.
I havent written them in the software yet.
Under the folder boot in auto-key
Put your recovery.img in the boot folder
cd ~/auto-key/boot
type
./mkboot recovery.img new-ramdisk
that will unpack the recovery.
open the new-ramdisk folder
go to /res in the new-ramdisk
there is a file called keys
delete it
go to the the keys folder in auto-key
~./auto-key2/keys/factorykey/res/e-0x3
copy the keys file to the
new-ramdisk/res folder
cd
cd ~/auto-key/boot
type
./mkboot new-ramdisk patched-recovery.img
it will repack the recovery
Then you have to flash patched-recovery.img to the recovery mmcblk of your device.
You will have to use the dd command in adb if you can.
Not sure what type of access you have with the bootloop.
example command may work for you
just make sure that the patched-recovery.img is in the dir that shell is cd to.
then type
adb push patched-recovery.img /storage/sdcard0
or
adb push patched-recovery.img /storage/sdcard1
whichever one is your sd card.
then type
adb shell
su
dd if=/storage/sdcard0/patched-recovery.img of=/dev/block/mmcblk0p?? "make after the p your correct partition for recovery"
To sign files put them in the tosign folder in the auto-key folder
only 1 file ata a time can be in that folder
run akey.sh
select sign files
select option 1 in the sign files menu.
You will find the signed zip in /auto-key/output.
If you need more help let me know
Now Im not saying do all of that. But im saying Im pretty sure I might be able to use this same process to self sign our boot and recovery images. Then we don't need a bootloader unlock.
Our custom boot and recovery will be certified samsung official.
Just a lot to work on now. The sdcard and now the signing project.
Now were starting to have some real fun.
Sorry to be off topic i hope the sanfail team is on board with u
One more writeup about the recovery signature hack
What happens is that the stock recovery checks the public part of the key pair against a file in the recovery.img ram disk. Usually /res/keys. You can locate this call in one of the recovery log files located in the /cache. When you get your device the /res/keys that is in the ramdisk is generated by the manufacture keyset therefore limiting the update.zip to be signed with the manufacturer keys.
So I have tested and found a way to change that. Like I said I have tested and it works. If you pull your stock recovery image or get it from a factory update.
Take that recovery.img and split it into the seperate kernel and ramdisk.
Extract or mount the ramdisk -cpio.
Generate your own set of private keys using the same public exponent as the factory rom.
Example and probably most common: Exponent: 3 (0x3)
Example: Releasekey.x509.pem and Releaseke.pk8 generated with Exponent: 3 (0x3)
Take the new keys and use DumpPublicKey.jar to create a new keys file.
Replace the /res/keys file with the one created from your keys.
Repack the ramdisk.
Repack the recovery.img using the correct offsets.
Either flash the new recovery.img to the device or use fastboot to boot it.
Example: fastboot boot recovery.img
Now take an update.zip and edit the updaterscript so that it will fail at an assert / unless you actually want to flash the update.
Sign the update zip using your .x509.pem and .pk8 keypair. You have to use the signapk.jar with the -w option else it wont work.
It will pass the signature verification of the recovery for sure.
We just did the same thing that the manufacturer does with there keys.
I dont anticipate any problems with the bootloader because the new recovery.img is identical to the original recovery.img except for the /res/key is your key.
The boot loader isn't checking that key "that i know of" so it doesn't know anything is different.
And that is how to load any update you want. You sign it with your own key. You make the recovery.img /res/keys with the matching keys.
Now if you are a developer you could probably figure out how to do all of the above.
Otherwise there is a lot more to it than it seems.
Even if you were able to flash system images, would they still not have to be stock(ish)? Would you not still have to go through the whole rigamarole of obtaining combo bootloaders and disabling dm-verity? What about rebuilding a kernel that is kexec enabled and flashing over the recovery partition to chainload another kernel? Would the bootloader not check the signature since it's already been 'signed'?
BigCountry907 said:
My only question is has anyone ever been actually paid by Samsung for finding Exploits?
From what ive read on there site it says $200,000 K or more for a bootloader unlock.
Makes me wonder if I should be sharing this information with anyone.
But money aside...thats what samsung wants. There using greed against us. They don't want us to work together.
I will be getting into some very deep presentations of my work as time provides.
That way the community can learn and help on this exciting journey.
Damm I still can't believe it turned FRP off. :silly:
Just goes to show ya. Don't doubt it till you try it no matter how far out it may seem. :highfive:
Click to expand...
Click to collapse
i just got paid for a exploit i reported to samsung back in may lol.. it was rated a high vuln.. it was for msm8998 chipsets on 7.0 (only tested on vzw tab s3)
I was listed on sept. security bulletin even lol.. i got 2500$ (1950$ after korea n us taxes n fees n w.e else.)
The exploit (without going into details) allowed flashing a modified partition and executing scripts/commands in init context.. the patch basically said they blocked or removed all init scripts lol
i never reported SamPWND.. it wouldnt be elig anyways bcuz it uses leaked eng firmware with the exploits
if ur sdcard trick does disable frp you cant report it now since u already posted publicly lol
BigCountry907 said:
The thing that is significant thus far is the fact that booting with the sdcard IS SETTING frp LOCK TO OFF.
The normal Samsung Note 8 partition scheme uses Persist and Persistent partition for setting the FRP on or off.
If both persist and persistent are ZERO then FRP = off.
So the stock bootloader will read partitions that are (whitelisted) and verified to be Qualcomm Unique GUID Type.
Possibly even boot a bootloader that is not signed by Samsung but signed by Qualcomm.
If Qualcomm signed bootloaders will run then we can actually compile sign and boot our own bootloader.
Here is how.
https://www.96boards.org/documentation/consumer/dragonboard/dragonboard820c/guides/
Building the SD rescue image
The scripts to build the SD rescue image can be found here:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader-dragonboard820c.yaml,
where we defined the script parameters and variables
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard820c/builders.sh:
where the actual commands are being executed.
Same Chip so we can use the source code.
Click to expand...
Click to collapse
isnt the note 8 msm8998? the dragonboard strings u posted are for the older msm8996 chipset as well as they are for lab purposes.. theres quite a few differences even without taking into consideration the chipsets are different...
one being samsung.. samsung takes qualcomms firmware/source and customizes the crap out of it.. disabling/removing fastboot, implementing the odin protocol etc etc
i dont think the sdcard approach is viable.. secure boot is enabled and the partitions u speak of flashed to an sdcard are not signed appropriately so the device wouldnot boot up if it was in fact trying to run off the sdcard..
even in edl, edl doesnt per say let the phone boot unsigned firmware.. its merely a flashing mechanism.. so it will allow you to flash just about anything if using signed programmers and everything else is proper but if that firmware is not signed the device will not boot due to secure boot..
the private key is burned into hardware at the factory..
with that being said, i would look at the non volatile partitions that arent required to be signed and see if theres anything there that we can modify to help in unlocking the bl.. partitions like param, or steady or misc etc etc that we could modify and flash in edl and still boot as its not checked for integrity if that makes sense lol
partitions like misc.. on combo you can do in shell "setprop sys.boot_mode ffbm" and itll write ffbm-01 to the misc partition then boot into a special diagnostic mode which you can even see it in the last kmsg/boot logs.. maybe theres a boot mode or somethin similar that turns boot from sdcard on?
dunno bout newer devices but s7 and s6 etc. the unlockable sd variants use crom.apk (their bls have a crom lock)... pushing req libs with root and running logcat while running crom it writes a "KIWIBIRD" flag to the steady partition then when device boots it reads it and bl is unlocked..
On newer locked sd devices theres an eng mode.. theres an eng cert that gets flashed in odin that i believe writes to stead or param, not sure lol but u get the point..
just trying to say theres other routes to look at that i think would be more viable.
i spent close to a year messin with edl on msm8998 (s8+ g955u), it is a viable way in if u can figure it out.. unsigned firmware like boot.img, recovery.img and the usual partitions never booted for me.. always secure check fail even when flashing with edl..
theres an old read but decent and somewhat related to sdcard.. samsung devices used to have an option in odin called t. flash that was supposed to flash the stuff in odin to an sdcard in the device.. i think he crafted a boot.img then tflashed stock or somethin like that lol.. it was yearsago so surely patched unless sammy goofed and quitely re-enabled it lol
to add after reviewing further, the dragonboard 820c is closest to snapdragon 820 which was in the S7 devices.. or similar to msm8996.. note 8 was msm8998 or closer to snapdragon 830? if that exists lol
Rip
dazemc said:
Even if you were able to flash system images, would they still not have to be stock(ish)? Would you not still have to go through the whole rigamarole of obtaining combo bootloaders and disabling dm-verity? What about rebuilding a kernel that is kexec enabled and flashing over the recovery partition to chainload another kernel? Would the bootloader not check the signature since it's already been 'signed'?
Click to expand...
Click to collapse
I'm not saying to do the recovery.img mod.
I'm saying use that as a template to be able to sign our own boot and recovery images.
First
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
Code:
# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
Second
Signing the boot image
Using the BootSignature.jar file sign the boot image using the keys generated above
If we look in that fota.zip
the path is /fota/OTA/tools
We have a boot_signer.sh and BootSignature.jar
Looking in the boot signer script we see.
#! /bin/sh
# Start-up script for BootSigner
BOOTSIGNER_HOME=`dirname "$0"`
BOOTSIGNER_HOME=`dirname "$BOOTSIGNER_HOME"`
java -Xmx512M -jar "$BOOTSIGNER_HOME"/framework/BootSignature.jar "[email protected]"
So to sign the boot image our command would be.
Code:
java -Xmx512M -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
To check the signature
Code:
java -jar BootSignature.jar -verify boot_signed.img
Now if we had Samsungs .pk8 and samsungs .x509.der things would be easy.
The .x509.der we can get off the device its got to be in the ramdisk.
But the .pk8 is the private key and usually we can't get that.
The thing is maybe we can.
The variable "[email protected]" has to be these keys and if the boot.img is getting signed on the device after a patch or update then its hiding somwhere. If we can find that we can sign our own boot.img and the device will say there samsung official.
The other option is where I was talking about what I did to the recovery image.
Some Where there is the KEY used to verify to boot.img signature.
In the case of the recovery and flashing update zips it it the /res/keys found in the ramdisk.
The /res/keys is a dumped form of the keypair made by using dumpkey.jar also found in the /fota/OTA/tools.
By running dumpkey.jar against our custom signing keys we get the form of the key used in /res/keys.
If the boot.img signature scheme used the same method all we need to know is where the equivalent /res/keys is at and replace it with ours.
It could very well be in the ramdisk.
For me to make this work what i need to know is where is the KEY that is used to verify the boot.img signature.
Or if we can get the "[email protected]" variable output in the boot_signer script then we will have both keys.
I highly doubt but it could be possible there hard coded in the BootSignature.jar thats in the fota folder.
It would be helpful if I had a copy of any OTA Update that someone pulled off a device before they installed the update. Preferably a full update from one android version to the next like going from N to O
MY Questions are.
Anyone out there have a copy of a OTA Update?
Anyone know the location of the KEY used to verify the Boot signature?
Has anyone installed an update and seen the update package unpack / repack and sign the boot.img or any log refering to the verification of the boot signature.
If the update unpacked the boot then it had to sign it.
Hopefully you understand now what direction I am headed in with Auto-Key script.
All the code to manipulate the keys I have written in the akey.sh already.
If we can sign our own boot and recovery we don't need to unlock the bootloader.
My final question is
Is the Kernel signed also? Or since the DM-Verity days are they only relying on the boot.img signature.
elliwigy said:
i just got paid for a exploit i reported to samsung back in may lol.. it was rated a high vuln.. it was for msm8998 chipsets on 7.0 (only tested on vzw tab s3)
I was listed on sept. security bulletin even lol.. i got 2500$ (1950$ after korea n us taxes n fees n w.e else.)
The exploit (without going into details) allowed flashing a modified partition and executing scripts/commands in init context.. the patch basically said they blocked or removed all init scripts lol
i never reported SamPWND.. it wouldnt be elig anyways bcuz it uses leaked eng firmware with the exploits
if ur sdcard trick does disable frp you cant report it now since u already posted publicly lol
Click to expand...
Click to collapse
I wasn't thinking of reporting the FRP trick.
There are a ton of ways to accomplish the same thing.
If you
Code:
dd if=/dev/zero /dev/block/sda5
and
Code:
dd if=/dev/zero /dev/block/sda12
Well FRP lock = off.
I just hate the Idea of someone using my work to profit from samsung.
I love for people to use my work and to contribute to it to help everyone.
So screw the money I just want to help.
Cool to know that you did get paid though.
elliwigy said:
isnt the note 8 msm8998? the dragonboard strings u posted are for the older msm8996 chipset as well as they are for lab purposes.. theres quite a few differences even without taking into consideration the chipsets are different...
Click to expand...
Click to collapse
This is the main reason I like the Samsung EDL Bootloaders.
one being samsung.. samsung takes qualcomms firmware/source and customizes the crap out of it.. disabling/removing fastboot, implementing the odin protocol etc etc
Click to expand...
Click to collapse
The EDL package is QUALCOMM. It lacks the Samsung Customization.
If it is possible to take those bootloaders that are signed and build the rest of the android system its hard to tell what we could end up with. Maybe the bootloaders in the EDL have the ability to be unlocked by the normal Qualcomm method that utilizez the DEVINFO partition that is present on our devices.
Have you looked at that yet?
Code:
greatqlte:/ # hexdump -C -v /sdcard/devinfo.img
00000000 41 4e 44 52 4f 49 44 2d 42 4f 4f 54 21 01 01 00 |ANDROID-BOOT!...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Looks Pretty Familiar.
Bootloader Unlocking
For some devices, such as several Xiaomi ones, partition flashing is sufficient for being able to unlock the Android Bootloader (which disables the verification of the rest of the chain):
[Primary Bootloader (PBL)]
|
`---NORMAL BOOT---.
[Secondary Bootloader (SBL)]
|-.
| [Applications Bootloader (ABOOT)]
| `-.
| [boot.img]
| |-- Linux Kernel
| `-- initramfs
| `-.
| [system.img]
|
`-[TrustZone]
The bootloader locking bit of such devices is held in the devinfo partition, parsed by the Android Bootloader.
Attackers can simply flip the lock bit, to load an arbitrary boot image. This will not cause any factory reset.
Reading devinfo using our framework prior to the attack yields the following output:
> hexdump devinfo.bin
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 41 4E 44 52 4F 49 44 2D 42 4F 4F 54 21 00 00 00 ANDROID-BOOT!...
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Setting 1 at offsets 0x10, 0x18, and flashing the modified devinfo will unlock the bootloader:
No im not saying that Ive tested this yet. But it is a possibility.
My guess is that the EDL bootloaders that Lack Samsung Customization including KNOX might and I say again Might read the devinfo partition.
It is there for some reason. So the Question is Why??? What does it do.
That is the reason for my interest in the EDL Firmware.
Code:
i dont think the sdcard approach is viable.. secure boot is enabled and the partitions u speak of flashed to an sdcard are not signed appropriately so the device wouldnot boot up if it was in fact trying to run off the sdcard.
Again this is misinterpretation.
I'm not saying we are going to run the dragonboard firmware on our devices.
If you know the dragonboard tools some of them are very useful.
It is proven already the sd card can indeed influence the devices operation.
Basically I am utilizing some dragonboard tools to replicate what odin does to the sdcard when you use T-FLASH.
The sd card is very viable and a great means of testing. BUT also a lot of work.
Dragonboard 820 is as close to the actual source code we are going to get right now.
If you dig down in the bootloaders you will find many reference to msm8996 source code.
The msm8996 and msm8998 share a lot.
And Little Kernel is Little Kernel.
Liarno has good source trees that are for building LK with different functions.
If we can unlock the bootloader and run our own LK thats sure where id start.
Also for understanding how LK works and the different functions what better of a source than a very well documented one.
I actually have quite a bit of Leaked Qualcomm Source Code. Its a bit older but still very viable.
More than enough to understand how the security mechanisms work if you really dig into it.
partitions like misc.. on combo you can do in shell "setprop sys.boot_mode ffbm" and itll write ffbm-01 to the misc partition then boot into a special diagnostic mode which you can even see it in the last kmsg/boot logs.. maybe theres a boot mode or somethin similar that turns boot from sdcard on?
Click to expand...
Click to collapse
Thank You very much for pointing this out.
There are uses for that for sure.
The sd card working or not working to accomplish anything all depends on how the samsung and the EDL bootloaders are written.
THEY DO SUPPORT THE SD.
I'm just looking for that one quirk that gets us a way in.
Its like looking for a needle in a haystack.
Its never expected to be there and found entirely by mistake. After you step on it.
If you don't play in the haystack you will never step on the needle.
Thank you again for your insight. If you have any other knowledge of things like that it all helps.
Maybe that is a way to trigger the SD.
The process of debating always leads to something.
Like setprop sys.boot_mode ffbm.
If everyone shares there finds eventually putting them all together gets something accomplished.
pbedard said:
Rip
Click to expand...
Click to collapse
RIP what?
This party is just getting started.
Pay attention.....you might be surprised how much you can learn.