-

[ghost]

[bkerler]

Thx. Seems the device is in streaming, but not edl/firehose mode (pid 0x9008)

[bkerler]

No. it's missing the signing key which is stored on hsm.

[CE1CECL]

ok so only easyjtag or official service center as per service manual Level 1 repair ? Official service center may have an issue with IMEI and regionlocking as it's NA model brought to Europe.

I find it strange that we can't upload XBL in place of firehose programmer, in order to jump directly to Download mode?

Do you know if there is Sub6 5G capability on the PCB ? The service manual seems is not stating it. However many other less reliable sources state Sub6.

I was able to upload SBL1 to my TicWatch and Galaxy Tab E (now without display & battery) and it entered 9006 mode (#375) but would like help for the Pixel 4a

[bkerler]

The samsung devices are locked down. They have crippled firehose loaders that only accept to write specific partitions and forbid to read anything. EDL runs in EL1, so pwning anything there is pretty useless, as you cannot go to EL3. I'm closing this now as this is more for discussions and less for being a real issue I can fix.

[bkerler]

You are mixing stuff. Jtag is a debug interface that is disabled on fused devices. Pbl is the bootrom which is readonly and embedded into the cpu. Most probably your issue is rpmb and secure boot

[CE1CECL]

@bkerler is correct @infr-automation . Even Google Pixel 4a (sunfish) doesn't seem to have JTAG. You would probably be the most luckiest if you download your stock rom and upload either sbl1 or xbl (depending on your generation of device) and see what it does, if your lucky should go to 9006 mode (it did for me, untested on my Pixel b/c I no longer have the 5G phone since it was used for parts after all) On my pixel it just rebooted but its based of UEFI so it could be different nowadays.

[CE1CECL]

@CE1CECL Tried the XBL.elf, always identifies as 9008. Haven't tried bksecapp.mbn yet I think.

edit: tried the bksecapp, didn't work.

send me over your xbl file.

[CE1CECL]

@CE1CECL xbl.elf.SM-N976V_VZW_N976VVRU7GULD_fac.zip

Hmm, do you have discord?

I found something interesting.. It has 2 elf files in that file and a uefi partition at the beginning. wonder if i use either the last elf file or remove the uefi and 2nd elf file will force boot into something, assuming it is still valid. I was unable to get the pkhash of the 2nd elf file since it has no signature but look at this binwalk

DECIMAL HEXADECIMAL DESCRIPTION

0 0x0 ELF, 64-bit LSB executable, version 1 (SYSV)
5288 0x14A8 Certificate in DER format (x509 v3), header length: 4, sequence length: 1087
6379 0x18EB Certificate in DER format (x509 v3), header length: 4, sequence length: 1169
7552 0x1D80 Certificate in DER format (x509 v3), header length: 4, sequence length: 1161
19767 0x4D37 Unix path: /dev/icbcfg/boot
23046 0x5A06 VxWorks symbol table, big endian, first entry: [type: initialized data, code address: 0x6601, symbol address: 0x5F00]
46772 0xB6B4 CRC32 polynomial table, little endian
50048 0xC380 CRC32 polynomial table, little endian
553152 0x870C0 UEFI PI Firmware Volume, volume size: 2359296, header size: 0, revision: 0, EFI Firmware File System v2, GUID: 8C8CE578-8A3D-4F1C-3599-896185C32DD3
810340 0xC5D64 Unix path: /home/dpi/qb5_8814/workspace/P4_1716/nhlos/boot_images/Build/SDM855LA_Core/RELEASE_CLANG40LINUX/AARCH64/QcomPkg/XBLCore/XBLCore/
826448 0xC9C50 gzip compressed data, from Unix, last modified: 1970-01-01 00:00:00 (null date)
2912448 0x2C70C0 ELF, 64-bit LSB executable, version 1 (SYSV)
2913352 0x2C7448 Certificate in DER format (x509 v3), header length: 4, sequence length: 1051
2914407 0x2C7867 Certificate in DER format (x509 v3), header length: 4, sequence length: 1106
2915517 0x2C7CBD Certificate in DER format (x509 v3), header length: 4, sequence length: 1061
3171392 0x306440 SHA256 hash constants, little endian
3329292 0x32CD0C HTML document header
3341150 0x32FB5E HTML document footer
3438280 0x3476C8 XML document, version: "1.0"
3443260 0x348A3C XML document, version: "1.0"
3448220 0x349D9C XML document, version: "1.0"
3453697 0x34B301 XML document, version: "1.0"
3459288 0x34C8D8 XML document, version: "1.0"
3464765 0x34DE3D XML document, version: "1.0"
3473162 0x34FF0A XML document, version: "1.0"
3476600 0x350C78 XML document, version: "1.0"
3479256 0x3516D8 XML document, version: "1.0"
3482737 0x352471 XML document, version: "1.0"
3485347 0x352EA3 XML document, version: "1.0"

[CE1CECL]

Padding_Non-empty_Padding.pad.zip

The same thing is with the pixel xbl's i have, I uploaded the 1st half of the loader for your device still gets identified the same hash as before with fhloaderparser, and let me know how it works. Do edl printgpt if it spams ctrl c and do lsusb and see where its at (and dmesg if it isnt shown) If it freezes up on uploading let me know that too.

[CE1CECL]

new.zip

Not sure what didn't work, you didn't give any info about what did happen or anything, are you on Linux?

[CE1CECL]

I tried on Windows with Firehose_finder and QFIL I also have the Qualcomm tools from t me qualcommmodem can also try with those but it's going to be the same I bet. However since we are in so deep I should really install the USB sniffer.

@bkerler So with the U4 etoken bypass there is damage to RPMB ? What is your opinion about CPU swap from Xiaomi for example ? Will it boot Samsung boot stages with Xiaomi unlocked bootloader ? Please give more info about the specifics.

Can you try using windows with bkerler/edl and run python3 edl --loader=Padding_Non-empty_Padding.pad printgpt with device manager opened. Tell me what happens in the console and what device it ends up as (stuck in 9008, goes to 9006, etc...) Does the console not upload or spam, etc... I need the info in order for me to be able to try to help you and reproduce what I have been able to do.

[CE1CECL]

Actually windows support seems broken for me, use a live DVD of Ubuntu 20.04, install edl as provided in the readme (commands below)

sudo apt install adb fastboot python3-dev python3-pip liblzma-dev git
sudo apt purge modemmanager
sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
sudo apt purge ModemManager
git clone https://github.com/bkerler/edl.git
cd edl
git submodule update --init --recursive
pip3 install -r requirements.txt
sudo cp Drivers/51-edl.rules /etc/udev/rules.d
sudo cp Drivers/50-android.rules /etc/udev/rules.d
python3 setup.py build
sudo python3 setup.py install 

, and run ./edl --loader=Padding_Non-empty_Padding.pad printgpt and in another terminal run dmesg and provide the details and logs.

[CE1CECL]

@bkerler @CE1CECL Could it be one of the programmers or XBLs we tried is the correct one, and the error is in board init such as charging problem ? Because in the elf, there's these functions: https://worthdoingbadly.com/qcomxbl/

In my case I didn't have a battery in my SM-T560NU installed and the eMMC wasn't init'ing and the FH loader wasn't uploading, the SBL1 did, but dmesg showed eMMC errors, meaning there wasn't enough power. If you did the XBL using my comment above, you should see what is going on. I zippped 2 files, so you should try both out, and do a dmesg.

[CE1CECL]

@CE1CECL nope same didn't work - the qcserial gets disconnected however the lsusb shows the 9008 device is still connected?

So no idea what is going on here, I will smash it with a hammer and set it on fire and send that video clip to Samsung to enjoy.

log.txt

[24633.890442] usb 2-5: new high-speed USB device number 7 using xhci_hcd
[24634.047578] usb 2-5: New USB device found, idVendor=05c6, idProduct=9008, bcdDevice= 0.00
[24634.047580] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[24634.047582] usb 2-5: Product: QUSB_BULK_CID:0404_SN:84002E4B
[24634.047582] usb 2-5: Manufacturer: Qualcomm CDMA Technologies MSM
[24634.081008] usbcore: registered new interface driver usbserial_generic
[24634.081020] usbserial: USB Serial support registered for generic
[24634.089455] usbcore: registered new interface driver qcserial
[24634.089468] usbserial: USB Serial support registered for Qualcomm USB modem
[24634.089487] qcserial 2-5:1.0: Qualcomm USB modem converter detected
[24634.089560] usb 2-5: Qualcomm USB modem converter now attached to ttyUSB0
[24734.002548] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[24734.002559] qcserial 2-5:1.0: device disconnected
[24891.388315] usb 2-5: USB disconnect, device number 7
[24902.857749] usb 2-5: new high-speed USB device number 8 using xhci_hcd
[24903.010912] usb 2-5: New USB device found, idVendor=05c6, idProduct=9008, bcdDevice= 0.00
[24903.010916] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[24903.010917] usb 2-5: Product: QUSB_BULK_CID:0404_SN:84002E4B
[24903.010923] usb 2-5: Manufacturer: Qualcomm CDMA Technologies MSM
[24903.012529] qcserial 2-5:1.0: Qualcomm USB modem converter detected
[24903.012571] usb 2-5: Qualcomm USB modem converter now attached to ttyUSB0
[24903.909059] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[24903.909106] qcserial 2-5:1.0: device disconnected
[24904.019901] usb 2-5: USB disconnect, device number 8
[24904.401763] usb 2-5: new high-speed USB device number 9 using xhci_hcd
[24904.555231] usb 2-5: New USB device found, idVendor=05c6, idProduct=9008, bcdDevice= 0.00
[24904.555245] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[24904.555250] usb 2-5: Product: QUSB_BULK_CID:0404_SN:84002E4B
[24904.555255] usb 2-5: Manufacturer: Qualcomm CDMA Technologies MSM
[24904.557796] qcserial 2-5:1.0: Qualcomm USB modem converter detected
[24904.558062] usb 2-5: Qualcomm USB modem converter now attached to ttyUSB0
[24933.375597] qcserial ttyUSB0: Qualcomm USB modem converter now disconnected from ttyUSB0
[24933.375609] qcserial 2-5:1.0: device disconnected

Do the ./edl --loader=Padding_Non-empty_Padding.pad printgpt and with the xbl.elf file ./edl --loader=xbl.elf printgpt and send me logs without debugmode on. Send me the dmesg for both also since you only sent me one. AND, do with the default bkerler loader in ./ed/Loaders/ ./edl printgpt with its dmesg. 7 logs total. Dont cut out the dmesg next time too. Give me a dmesg before anything too.

[CE1CECL]

omg why I did all that but it was the same every time what are we looking for more specifically ?

I should check if I can capture all that with a single command line.

ok fine 1 command (dmesg && ./edl printgpt && ./edl --loader=Padding_Non-empty_Padding.pad printgpt && ./edl --loader=xbl.elf printgpt && dmesg) >LOG.TXT

[CE1CECL]

@infr-automation are you still around? if so, may you try one of these loaders in https://github.com/CE1CECL/v/tree/main/in ? (SM-N976V.mbn or SM-N976V.nbm) and let me know the results. The pkhash matches the xbl you sent earlier. (5bb51bf4b1b24ba83c86584e5be7638fb3c00012667b6bafbc28576b4c5d75b842679b65e061cb6f1005619da974c4ff)

[CE1CECL]

I can try some loaders. @CE1CECL

Hello! Ignore what I said the last time which is crossed out, but anyways, I think, from the wasted 190GB of samsung leaks i had to download (and deal with torrents), I found a private key and cert, for both root and attestation. Yes you heard me right, I grepped through the 3 Part files that you mentioned earlier, and well, found what I needed in part 2. Note though, most keys in part 2 of the leak were (for god sake, what and why SS?) TEST AUTHORITY KEYS/CERTS. But, that means I found only 1 in part 2 that didn't say TA. Here are the hashes (note the files are renamed by me)

f9ecad95bf591e175ccf9f394595eb950375893e8809cd5be803506aa3aebcf0 att.cer
668f3a864bb928f8514fdb42ffd29072367ce894d329f9482ef3bd29d946e44b att.key
57297aa54d6a6074d02acaaf8147f776df373230670d60da6cd9552ef443fafa root.cer
a60268f5c5b052f3a4a3841176d0983ef0f29b98209c0ddc376eeb26ddbd8ed7 root.key

Now what, we got keys right? Yes, now we have to get a unsigned loader, of any kind, (for your soc anyways), which is easy, and convert the private certs to public certs and generate the user cert, since the user cert actually contains info about the whole file. Note that qtestsign wont work, because it doesn't make the user cert, but makes it look like it has any cert, no conversion is being done. What am I going to do next?
Heres what
since my SM-T560NU actually doesn't have a EDL Loader, (yet, lets make that change :)), I am going to use my qcom leak from even older, just a generic qcom leak, no oem stuff, and inject the samsung certs, and generate the prog mbn, and see how that goes, I will keep you updated though. Also on hashes, since these are only private keys, they don't show any kind of pk_hash, remember, the user cert, contains info about the HW_ID, SW_ID, etc.. Once converted, we can get the pkhash, which btw, the hwid is in a xml file, so it can be modified, and the keys could be reused on more soc's, assuming SS uses the same ones the whole time.

[CE1CECL]

Hmm, this is really strange, any fh loading I send it doesn't work, and sbl1 work but without emmc responses?

root@LenovoLegionT5:/# fhloaderparse a b
OEM:Qualcomm     	MODEL:0000	HWID:007060E100000000	SWID:0000000100000000	SWSIZE:00000128	PK_HASH:135673828dd48fb222b9e750d06080773a50996cc6510728b1ba13c7a79f7f19	a/sbl1.mbn	285428	OEMVER:21HHAD12	QCVER:BOOT.BF.3.0.C8-00019	VAR:HAAAANAZA
root@LenovoLegionT5:/# edl --loader=b/007060e100000000_135673828dd48fb2_fhprg.bin 
Qualcomm Sahara / Firehose Client V3.61 (c) B.Kerler 2018-2023.
main - Using loader b/007060e100000000_135673828dd48fb2_fhprg.bin ...
main - Waiting for the device
main - Device detected :)
sahara - Protocol version: 2, Version supported: 1
main - Mode detected: sahara
sahara - 
------------------------
HWID:              0x007060e100000000 (MSM_ID:0x007060e1,OEM_ID:0x0000,MODEL_ID:0x0000)
CPU detected:      "APQ8016"
PK_HASH:           0x98dc3fdde47b651f47f77620e7376d09905fc36d97cba5b560bcfef2f77df06a
Serial:            0x2655760a

sahara - Protocol version: 2, Version supported: 1
sahara - Uploading loader b/007060e100000000_135673828dd48fb2_fhprg.bin ...
sahara - 32-Bit mode detected.
sahara - Firehose mode detected, uploading...
sahara - Loader successfully uploaded.
root@LenovoLegionT5:/# 

From the look of that console, you see 2 hashes, 98dc3fdde47b651f47f77620e7376d09905fc36d97cba5b560bcfef2f77df06a (device) and 135673828dd48fb222b9e750d06080773a50996cc6510728b1ba13c7a79f7f19 (stock sbl1), what? They don't match, meaning no secure boot, just like the ticwatch, there only need some cert to upload. I even resigned with my leak certs, and clearly I don't have secure boot, note the signer from qcom removes old certs for you, you just need a sbl1, or fh loader that works on the soc the most likely.

[CE1CECL]

And before you ask, none of the certs start with 98dc, I mean, look:

root@LenovoLegionT5:/b# binwalk 007060e100000000_135673828dd48fb2_fhprg.bin -D='.*' --run-as=root 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ELF, 32-bit LSB executable, ARM, version 1 (SYSV)
4648          0x1228          Certificate in DER format (x509 v3), header length: 4, sequence length: 1273
5925          0x1725          Certificate in DER format (x509 v3), header length: 4, sequence length: 1077
7006          0x1B5E          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
8045          0x1F6D          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
9084          0x237C          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
10123         0x278B          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
11162         0x2B9A          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
12201         0x2FA9          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
13240         0x33B8          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
14279         0x37C7          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
15318         0x3BD6          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
16357         0x3FE5          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
17396         0x43F4          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
18435         0x4803          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
19474         0x4C12          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
20513         0x5021          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
21552         0x5430          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
22591         0x583F          Certificate in DER format (x509 v3), header length: 4, sequence length: 1035
210052        0x33484         Unix path: /dev/icbcfg/boot
211444        0x339F4         Unix path: /dev/icbcfg/boot
211944        0x33BE8         Unix path: /dev/icbcfg/boot
249832        0x3CFE8         CRC32 polynomial table, little endian

root@LenovoLegionT5:/b# sha256sum _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/*
062f978374971a3b0fe58ea94b3435a1297f824d3c089d790d18607f3a0bfd9d  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/0
033866606e05159f3e32444d254f6e9421d67493415393f3f16a0f6a2d85ff85  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/1228
b71f416976cb83efb531ed9a5336dd9e4f1fbf200cdf4038588704e52a08f693  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/1725
135673828dd48fb222b9e750d06080773a50996cc6510728b1ba13c7a79f7f19  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/1B5E
89b68c659fdd67a31997e76c04df63c9412dfd5101cd388385c46a1804ea6e6f  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/1F6D
050d70b5c3574bf4e86ed37b1bb8ff6edf9a7a64842a9a0f1e5fb5f774a7810c  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/237C
b1ea246e672f5b55f8bef0846b9d6b7ec77a4f1cfb6263650786b6aa29ec8e8a  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/278B
4987f6857d79cb9ae623ec32769d7a8e8256d98a04621070a401f2909b0fa79f  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/2B9A
9e10d25bc032b12d69ae8b9719e41bb0019804c4a511228c7a26896ced5389aa  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/2FA9
d07ffb0dbf916047ae7baf168b0aff78e4c1bdc8f15360b323f4265b2dd6d4a5  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/33484
39792a9af34232b2308b237177ed5ef6675b8941a6d186f3d4c10b19526e4f24  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/339F4
bd5c4700ff46d958856dd052108c0084325d1f87b0a4db5a054c3831558fd7b0  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/33B8
524d749b7fe54092b1fb02fce555e4545e686609f7f102d3f0abadbdf987bcc9  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/33BE8
8aa2c23ea4157be101752d11254f1e9a49f2eb6d897d755c8c5903e9412c7565  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/37C7
0c48b65a47f8c72f9e78a9e15cc10f3cab3d668897ac41df852d8a00a9e2a042  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/3BD6
f5a4fa9ed406c48597c6f0c7bbdb15a2534e6587eb548d4bef326968e81c4f74  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/3CFE8
77ab49d21b1dacb74c434e7da37a02b6906ad9f563d79ab4d83a3cf1125462a1  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/3FE5
78c8e0d8b6d13724f03f4de446099bd9801153233351b8e40f0490a0800a27a0  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/43F4
b47434d5558ff4ef86645383d56c4e3f6405c8af750a35b6eb192afe1479fbf1  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/4803
d109641a9056c6b1e543fb28358d92871a654387b17a8c826c6ee1342cac2767  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/4C12
2336cd9824e101d51269438bd1faa4f3daff6da5d90f252958cfe504eab9435c  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/5021
bdf94ddf20db573d5812844d8256c1bdddf6cd7f79b1e7cc246220d18e38a9b3  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/5430
85fb61f690815b0f28e82e9e6dbb1ab34b78657532a5030eedac15f95f1556af  _007060e100000000_135673828dd48fb2_fhprg.bin.extracted/583F
root@LenovoLegionT5:/b# 

And the HWID matches on both, which I can fake, and it would do the same, at this point i have no secure boot. Now I need to test with you then, but the signer is from 2016, and doesn't support your platform (sm8150) in which ill look for the same tool for it online. BTW its called Qualcomm SecTools/SecImage

[CE1CECL]

@CE1CECL xbl.elf.SM-N976V_VZW_N976VVRU7GULD_fac.zip

Hello! Can you go ahead and try to see if these resigned images, based off of the XBL will work. "Work", as in doing the same thing as your no-modded cert, XBL.

$ edl printgpt
Qualcomm Sahara / Firehose Client V3.60 (c) B.Kerler 2018-2022.
main - Trying with no loader given ...
main - Waiting for the device
main - Device detected :)
sahara - Protocol version: 2, Version supported: 1
main - Mode detected: sahara
sahara - 
------------------------
HWID:              0x000a50e100200000 (MSM_ID:0x000a50e1,OEM_ID:0x0020,MODEL_ID:0x0000)
CPU detected:      "SM8150"
PK_HASH:           0x5bb51bf4b1b24ba83c86584e5be7638fb3c00012667b6bafbc28576b4c5d75b842679b65e061cb6f1005619da974c4ff
Serial:            0x84002e4b

sahara - Trying loader: /samsung/000a50e100200000_3b0b67354f55dde5_fhprg.bin
sahara - Protocol version: 2, Version supported: 1
sahara - Uploading loader /samsung/000a50e100200000_3b0b67354f55dde5_fhprg.bin ...
sahara - 64-Bit mode detected.
sahara - Firehose mode detected, uploading...
DeviceClass - USBError(19, 'No such device (it may have been disconnected)')
sahara
sahara - [LIB]: Unknown response received on uploading loader.

OEM:Samsung MODEL:0000 HWID:000A50E100200000 SWID:0000000000000000 SWSIZE: PK_HASH:5bb51bf4b1b24ba83c86584e5be7638fb3c00012667b6bafbc28576b4c5d75b842679b65e061cb6f1005619da974c4ff a/xbl.elf 4194304
Looking at both of those, you can see the HWID and PKHASH match on both, meaning secure boot is more-likely, on (in your case it for sure is). The Image I will send you, has to be on the same exact device, as your OP S/N, since it was added.
Though, keep in mind, it may, or may not work, it turns out the PKHASH is different, but I diff'ed the 2 different certs, and they only change like 2 lines, Here is the hash of my gen: OEM:Samsung MODEL:0000 HWID:000A50E100200000 SWID:0000000000000000 SWSIZE: PK_HASH:46e206b07d915e0402c8267f98dc15c4929de5fb8bbeb6ce34cca01d5af491b07f6417dafd0c6d87532ba3811f3b8b02 secimage_output/sm8150/xbl/xbl.elf 3779856
And i was wrong about the public and private keys, it seems it adds the same cert, with the matching key (tried with different cert non-matching key, failed) and generates one more, for the info. Also, on the T560NU, it only uploaded for me the new generated and original sbl1, since i didn't have a battery, and so the emmc, doesn't seem to work without battery, so then firehose wont upload if the emmc is known, dead. I tried to use my edl cable, but cant force reset without display and my home button is gone, which is needed to force reset.

[CE1CECL]

secimage_output.zip
Note I also had to get a different newer sectools package, i was lucky to find it on github, and not anywhere else, though it is very incomplete, and I did have to patch it a slight to get it going, unlike my 8909W source it contains the AOSP as well inside of it, that go with it.
Let me know if it "works", if it does I'll make the actually loader and have you try that, later.

[CE1CECL]

Ok, updates:
It turns out the SMT560NU IS ACTUALLY SECURE BOOT ENABLED. But, differently, it has 16 ROOT CERTS, all with different public keys (18 in total, assertation, and user). But even if i said "it worked for me", I seem it have uploaded the same sbl1 from rom, figuring it out later. Remember that 98 Hash, well, its there, you just have to merge all of the root certs together and nothing else, sha256sum it and it will say it, meaning the calculated hash fhloaderparse was wrong (as in calculating only one root cert). Note it seems QC also did support this in sectools. Now I need to find a) how are the private keys made from outer space for a device? (even possible tho?) b) Does samsung keep all keys in a DB, one by one, or C) If not, how do you make a "keygroup" to one private key, if you get what I mean. I wouldnt be surprised if the last file doesnt work, since the pk hash actually does need to match (The whole hash, not the first 16), it just a little confusing how the files are named by HWID and Hash, when the HWID doesnt always work, and can be reused by different devices, or companies even.

So, what I need to really find next:

1. Whats HSM_OEM.py, and does it gen keys compatible for the cert? (shows in both the 190GB leak and my QC generic leak, though unsure if any files are touched by samsung as of now.
2. If the tool in 1 is nothing at all, how do we even get the keys? Do we have to wait for the 100TB DB leak that will never come true, or do we have what we need and not know.

also, the TA, now i see it means "Trusted Authority", as in person, there are test certs, from the keys, though idk if the keys could be generated by the java file with another file only samsung has or what. I did openssl all the files that contain the word "PRIVATE KEY" and sadly found nothing for both of our devices (you only have 3 certs total, though the other 3/6 are for the elf, which are signed by QC, we need only the top Samsung files).

Short Explanation: We have the certs, in XBL, We have the useless Public Keys, We need to generate/(find another leak) for the Private key and sign the ELF, we have also the signing tool, already. We are only missing OEM keys. Thats it

[CE1CECL]

Well it seems to be the general enterprise practice to protect private keys in an so called Hardware Security Module, which cryptographically guarantees who can access what and when. The HSM used in corporate space is a 1U box with hardware protections up the wazoo covering all possible attack scenarios. Including kidnapping. This is in theory. In practice - the private key is generated outside the HSM and then put in the HSM so you can imagine some vectors there probably.

The devil is in the details what makes a think successful is the details.

I am not for many decades into contact with the talented reverse engineers, however if someone has something theoretically they could be asked to grep their loot for something. However I don't know where to begin on that.

It is a good skill to be able to guarantee private key security so at least we are learning something.

Hmm not seeing any real keys for either of our certs. But I did see on some google searches that you can extract the keys from TrustZone with some CVE's. Since you did send all the partitions of my t560nu, I did find 1 private key in image 0.apnhlos.fat
Here is its possible info

Private-Key: (2048 bit, 2 primes)
modulus:
    00:a7:00:36:60:65:dc:bd:54:5a:2a:40:b4:e1:15:
    94:58:11:4f:94:58:dd:de:a7:1f:3c:2c:e0:88:09:
    29:61:57:67:5e:56:7e:ee:27:8f:59:34:9a:2a:aa:
    9d:b4:4e:fa:a7:6a:d4:c9:7a:53:c1:4e:9f:e3:34:
    f7:3d:b7:c9:10:47:4f:28:da:3f:ce:31:7b:fd:06:
    10:eb:f7:be:92:f9:af:fb:3e:68:da:ee:1a:64:4c:
    f3:29:f2:73:9e:39:d8:f6:6f:d8:b2:80:82:71:8e:
    b5:a4:f2:c2:3e:cd:0a:ca:b6:04:cd:9a:13:8b:54:
    73:54:25:54:8c:be:98:7a:67:ad:da:b3:4e:b3:fa:
    82:a8:4a:67:98:56:57:54:71:cd:12:7f:ed:a3:01:
    c0:6a:8b:24:03:96:88:be:97:66:2a:bc:53:c9:83:
    06:51:5a:88:65:13:18:e4:3a:ed:6b:f1:61:5b:4c:
    c8:1e:f4:c2:ae:08:5e:2d:5f:f8:12:7f:a2:fc:bb:
    21:18:30:da:fe:40:fb:01:ca:2e:37:0e:ce:dd:76:
    87:82:46:0b:3a:77:8f:c0:72:07:2c:7f:9d:1e:86:
    5b:ed:27:29:df:03:97:62:ef:44:d3:5b:3d:db:9c:
    5e:1b:7b:39:b4:0b:6d:04:6b:bb:bb:2c:5f:cf:b3:
    7a:05
publicExponent: 65537 (0x10001)
privateExponent:
    5e:79:65:49:a5:76:79:f9:05:45:0f:f4:03:bd:a4:
    7d:29:d5:de:33:63:d8:b8:ac:97:eb:3f:5e:55:e8:
    7d:f3:e7:3b:5c:2d:54:67:36:d6:1d:46:f5:ca:2d:
    8b:3a:7e:dc:45:38:79:7e:65:71:5f:1c:5e:79:b1:
    40:cd:fe:c5:e1:c1:6b:78:04:4e:8e:79:f9:0a:fc:
    79:b1:5e:b3:60:e3:68:7b:c6:ef:cb:71:4c:ba:a7:
    79:5c:7a:81:d1:71:e7:00:21:13:e2:55:69:0e:75:
    be:09:c3:4f:a9:c9:68:22:0e:97:8d:89:6e:f1:e8:
    88:7a:d1:d9:09:5d:d3:28:78:25:0b:1c:47:73:25:
    cc:21:b6:da:c6:24:5a:d0:37:14:46:c7:94:69:e4:
    43:6f:47:de:00:33:4d:8f:95:72:fa:68:71:17:66:
    12:1a:87:27:f7:ef:7e:e0:35:58:f2:4d:6f:35:01:
    aa:96:e2:3d:51:13:86:9c:79:d0:b7:b6:64:e8:86:
    65:50:bf:cc:27:53:1f:51:d4:ca:be:f5:dd:77:70:
    98:0f:ee:a8:96:07:5f:45:6a:7a:0d:03:9c:4f:29:
    f6:06:f3:5d:58:6c:47:d0:96:a9:03:17:bb:4e:c9:
    21:e0:ac:cd:78:78:b2:fe:81:b2:51:53:a6:1f:98:
    45
prime1:
    00:cf:73:8c:be:6d:45:2d:0c:0b:5d:5c:6c:75:78:
    cc:35:48:b6:98:f1:b9:64:60:8c:43:eb:85:ab:04:
    b6:7d:1b:71:75:06:e2:da:84:68:2e:7f:4c:e3:73:
    b4:de:51:4b:b6:51:86:7b:d0:e6:4d:f3:d1:cf:1a:
    fe:7f:3a:83:ba:b3:e1:ff:54:13:93:d7:9c:27:80:
    b7:1e:64:9e:f7:32:2b:46:29:f7:f8:18:6c:f7:4a:
    be:4b:ee:96:90:8f:a2:16:22:6a:cc:48:06:74:63:
    43:7f:27:22:44:3c:2d:3b:62:f1:1c:b4:27:33:85:
    26:60:48:16:cb:ef:f8:cd:37
prime2:
    00:ce:15:43:6e:4b:0f:f9:3f:87:c3:41:45:97:b1:
    49:c2:19:23:87:e4:24:1c:64:e5:28:cb:43:10:14:
    14:0e:19:cb:bb:db:fd:11:9d:17:68:78:6d:61:70:
    63:3a:a1:b3:f3:a7:5b:0e:ff:b7:61:11:54:91:99:
    e5:91:32:2d:eb:3f:d8:3e:f7:d4:cb:d2:a3:41:c1:
    ee:c6:92:13:eb:7f:42:58:f4:d0:b2:74:1d:8e:87:
    46:cd:14:b8:16:ad:b5:bd:0d:6c:95:5a:16:bf:e9:
    53:da:fb:ed:83:51:67:a9:55:ab:54:02:95:20:a6:
    68:17:53:a8:ea:43:e5:b0:a3
exponent1:
    67:9c:32:83:39:57:ff:73:b0:89:64:8b:d6:f0:0a:
    2d:e2:af:30:1c:2a:97:f3:90:9a:ab:9b:0b:1b:43:
    79:a0:a7:3d:e7:be:8d:9c:eb:db:ad:40:dd:a9:00:
    80:b8:e1:b3:a1:6c:25:92:e4:33:b2:be:eb:4d:74:
    26:5f:37:43:9c:6c:17:76:0a:81:20:82:a1:48:2c:
    2d:45:dc:0f:62:43:32:bb:eb:59:41:f9:ca:58:ce:
    4a:66:53:54:c8:28:10:1e:08:71:16:d8:02:71:41:
    58:d4:56:cc:f5:b1:31:a3:ed:00:85:09:bf:35:95:
    41:29:40:19:83:35:24:69
exponent2:
    55:10:0b:cc:3b:a9:75:3d:16:e1:ae:50:76:63:94:
    49:4c:ad:10:cb:47:68:7c:f0:e5:dc:b8:6a:ab:8e:
    f7:9f:08:2c:1b:8a:a2:b9:8f:ce:ec:5e:61:a8:cd:
    1c:87:60:4a:c3:1a:5f:df:87:26:c6:cb:7c:69:e4:
    8b:01:06:59:22:fa:34:4b:81:87:3c:03:6d:02:0a:
    77:e6:15:d8:cf:a7:68:26:6c:fa:2b:d9:83:5a:2d:
    0c:3b:70:1c:d4:48:be:a7:0a:d9:be:dc:c3:0c:21:
    33:b3:66:ff:1c:1b:c8:96:76:e8:6f:44:74:bc:9b:
    1c:7d:c8:ac:21:a8:6e:37
coefficient:
    2c:7c:ad:1e:75:f6:69:1d:e7:a6:ca:74:7d:67:c8:
    65:28:66:c4:43:a6:bd:40:57:ae:b7:65:2c:52:f9:
    e4:c7:81:7b:56:a3:d2:0d:e8:33:70:cf:06:84:b3:
    4e:44:50:75:61:96:86:4b:b6:2b:ad:f0:ad:57:d0:
    37:0d:1d:35:50:cb:69:22:39:29:b9:3a:d3:29:23:
    02:60:f7:ab:30:40:da:8e:4d:45:70:26:f4:a2:0d:
    d0:64:5d:47:3c:18:f4:d4:52:95:00:ae:84:6b:47:
    b2:3c:82:d3:72:53:de:72:2c:f7:c1:22:36:d9:18:
    56:fe:39:28:33:e0:db:03
Modulus=A700366065DCBD545A2A40B4E1159458114F9458DDDEA71F3C2CE08809296157675E567EEE278F59349A2AAA9DB44EFAA76AD4C97A53C14E9FE334F73DB7C910474F28DA3FCE317BFD0610EBF7BE92F9AFFB3E68DAEE1A644CF329F2739E39D8F66FD8B28082718EB5A4F2C23ECD0ACAB604CD9A138B54735425548CBE987A67ADDAB34EB3FA82A84A679856575471CD127FEDA301C06A8B24039688BE97662ABC53C98306515A88651318E43AED6BF1615B4CC81EF4C2AE085E2D5FF8127FA2FCBB211830DAFE40FB01CA2E370ECEDD768782460B3A778FC072072C7F9D1E865BED2729DF039762EF44D35B3DDB9C5E1B7B39B40B6D046BBBBB2C5FCFB37A05
writing RSA key
-----BEGIN PRIVATE KEY-----
MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCnADZgZdy9VFoq
QLThFZRYEU+UWN3epx88LOCICSlhV2deVn7uJ49ZNJoqqp20TvqnatTJelPBTp/j
NPc9t8kQR08o2j/OMXv9BhDr976S+a/7Pmja7hpkTPMp8nOeOdj2b9iygIJxjrWk
8sI+zQrKtgTNmhOLVHNUJVSMvph6Z63as06z+oKoSmeYVldUcc0Sf+2jAcBqiyQD
loi+l2YqvFPJgwZRWohlExjkOu1r8WFbTMge9MKuCF4tX/gSf6L8uyEYMNr+QPsB
yi43Ds7ddoeCRgs6d4/Acgcsf50ehlvtJynfA5di70TTWz3bnF4bezm0C20Ea7u7
LF/Ps3oFAgMBAAECggEAXnllSaV2efkFRQ/0A72kfSnV3jNj2Lisl+s/XlXoffPn
O1wtVGc21h1G9cotizp+3EU4eX5lcV8cXnmxQM3+xeHBa3gETo55+Qr8ebFes2Dj
aHvG78txTLqneVx6gdFx5wAhE+JVaQ51vgnDT6nJaCIOl42JbvHoiHrR2Qld0yh4
JQscR3MlzCG22sYkWtA3FEbHlGnkQ29H3gAzTY+VcvpocRdmEhqHJ/fvfuA1WPJN
bzUBqpbiPVEThpx50Le2ZOiGZVC/zCdTH1HUyr713XdwmA/uqJYHX0Vqeg0DnE8p
9gbzXVhsR9CWqQMXu07JIeCszXh4sv6BslFTph+YRQKBgQDPc4y+bUUtDAtdXGx1
eMw1SLaY8blkYIxD64WrBLZ9G3F1BuLahGguf0zjc7TeUUu2UYZ70OZN89HPGv5/
OoO6s+H/VBOT15wngLceZJ73MitGKff4GGz3Sr5L7paQj6IWImrMSAZ0Y0N/JyJE
PC07YvEctCczhSZgSBbL7/jNNwKBgQDOFUNuSw/5P4fDQUWXsUnCGSOH5CQcZOUo
y0MQFBQOGcu72/0RnRdoeG1hcGM6obPzp1sO/7dhEVSRmeWRMi3rP9g+99TL0qNB
we7GkhPrf0JY9NCydB2Oh0bNFLgWrbW9DWyVWha/6VPa++2DUWepVatUApUgpmgX
U6jqQ+WwowKBgGecMoM5V/9zsIlki9bwCi3irzAcKpfzkJqrmwsbQ3mgpz3nvo2c
69utQN2pAIC44bOhbCWS5DOyvutNdCZfN0OcbBd2CoEggqFILC1F3A9iQzK761lB
+cpYzkpmU1TIKBAeCHEW2AJxQVjUVsz1sTGj7QCFCb81lUEpQBmDNSRpAoGAVRAL
zDupdT0W4a5QdmOUSUytEMtHaHzw5dy4aquO958ILBuKormPzuxeYajNHIdgSsMa
X9+HJsbLfGnkiwEGWSL6NEuBhzwDbQIKd+YV2M+naCZs+ivZg1otDDtwHNRIvqcK
2b7cwwwhM7Nm/xwbyJZ26G9EdLybHH3IrCGobjcCgYAsfK0edfZpHeemynR9Z8hl
KGbEQ6a9QFeut2UsUvnkx4F7VqPSDegzcM8GhLNORFB1YZaGS7YrrfCtV9A3DR01
UMtpIjkpuTrTKSMCYPerMEDajk1FcCb0og3QZF1HPBj01FKVAK6Ea0eyPILTclPe
ciz3wSI22RhW/jkoM+DbAw==
-----END PRIVATE KEY-----

It sadly doesn't match the assertation cert, but the 16 root certs, still remains unknown, because they are all separate certs. (it doesnt match the single ones either). Wonder if it a generic key now, put the key into grep for the SS source, and i see some QSEE related stuff that seem random. Do you @infr-automation by any chance have a partition dump of your device model? I now have to find a tool to extract the keys from, idk, whatever there is left. The EFUSE wont help, since it keeps the hash, pbl isnt modded, so its gotta be in TZ or img files.

[CE1CECL]

Seems like the hash of A700366065DCBD545A2A40B4E1159458114F9458DDDEA71F3C2CE08809296157675E567EEE278F59349A2AAA9DB44EFAA76AD4C97A53C14E9FE334F73DB7C910474F28DA3FCE317BFD0610EBF7BE92F9AFFB3E68DAEE1A644CF329F2739E39D8F66FD8B28082718EB5A4F2C23ECD0ACAB604CD9A138B54735425548CBE987A67ADDAB34EB3FA82A84A679856575471CD127FEDA301C06A8B24039688BE97662ABC53C98306515A88651318E43AED6BF1615B4CC81EF4C2AE085E2D5FF8127FA2FCBB211830DAFE40FB01CA2E370ECEDD768782460B3A778FC072072C7F9D1E865BED2729DF039762EF44D35B3DDB9C5E1B7B39B40B6D046BBBBB2C5FCFB37A05 was also found in your FW, however, I, uhh, found a match for your root and assetation keys. It only took me a chown, chmod, and dos2unix to find it but it matched, however, i didnt know it would, since the cert in the same directory, actually seems like a "Genericly signed cert" but we have everything for you i think.
Edit: Nope, its from NON-HLOS.bin that was

[CE1CECL]

@infr-automation I just talked to samsung over the live chat, and they said they may be able to give it to us ("it" == SSBK ? SAK), however the person i talked to couldn't help me out and gave me a phone number to call to get the info we need (they said they don't have the key themselves, only the Knox team does). Here's their info
KNOX support team 1.855.567.5669 Monday - Friday: 8am - 8pm CST Note:The KNOX team agents are the only agents responsible for troubleshooting and ticket creation. If KNOX team agents receive any non-KNOX calls, they should transfer them to the correct department immediately.

Note: Do not ask, if you are going to call, about firehose or prebuilt images, but rather save it for later. The SS loaders they provide are limited loader from what I've seen, so it needs a regular loader with their key. SSBK Is also known as "Samsung Secure Boot Key" and SAK is "Samsung Attestation Key". No idea which one we need but ask for both if you decide to call. (Attestation Key also b/c Attestation has info about root, and isn't ever changed. SSBK I assume is "root cert/key" in SS Language) Also if you do let me know the results.

More info: https://docs.samsungknox.com/admin/whitepaper/kpe/hardware-backed-root-of-trust.htm

[CE1CECL]

ok I request SSKB, SAK, and at the end, a "emergency download" loader ?

No you only ask for SBBK and SAK, ill say when to ask for firehose (later day)

[CE1CECL]

@infr-automation I got the message that they can't give SSBK or any boot keys from samsung knox. I need to look for a good RSA-2048 factoring tool, that accepts, well big numbers, 617 digits.

[CE1CECL]

@CE1CECL @bkerler

Unlocktool has N976V Bit8 "Debug Emergency"

Is it going to work with Bit7 ?

It should but it would set 7 to 8, also can you extract the loader from the tool and use this tool instead? Can you share a link of unlocktool, i found another tool with this phone but i couldn't extract it (a while ago)

[CE1CECL]

https://unlocktool.net/models/?q=note10# shows otherwise
https://octoplusbox.com/en/news/octoplus-samsung-tool-software-v-4-2-8-is-out/ shows it does have it (which is what i looked at)
You can see the leaked samsung loaders here: https://github.com/Alephgsm/SAMSUNG-EDL-Loaders

[chiteroman]

Is it possible to extract from TrustZone Google attestation certificates using this tool?

[alltern]

Thx. Seems the device is in streaming, but not edl/firehose mode (pid 0x9008)

Since this is closed and the account is deleted Did he have a fix that could help me cause I also have the issue?