A few things on knox / rooting and bootloaders that need more testing / development

Search This thread
By:
Advanced…
X

xclub_101

Senior Member
Oct 15, 2012
1,252
358
Samsung Galaxy S23 Ultra
ryanbg said:
I've done a bit of reverse engineering, and I've discovered two very important pieces of information.

1. TrustZone appears to not be device specific, you could most likely flash any N3 TZ and possibly even S4/N2, as long as it is signed properly.

2. It appears rollback information is stored in the rpmb. I found a string in TZ.mbn directly indicating so.

Here's my idea; Since the only way to communicate with TrustZone is via TEE (Trusted Execution Environment) or in our case QSEE (Qualcomm Trusted Execution Environment) which is a proprietary stack. The device driver for QSEE is /dev/qseecom. I'm doing some experimenting on whether it'll accept commands or data, but this looks to be the most promising route. If it were possible to rollback the counters to 0, which I know now to be rpmb based so we can most likely reset them, we could flash an old aboot that exists from MHV or MG3 (I might be able to insert the certificates MG3 since it is not signed, but it's 4.2.2 based.) I'm able to see much lower level debug and logging information thanks to @Surge1223. The files in /firmware/image and /system/etc/firmware are elf images of TZ HLOS applications. Another place to start investigating more thoroughly. I would not be surprised to find Knox related things too.
...
Click to expand...
Click to collapse


1. TZ was known not to be device-specific and the overall protocol to talk to code in TZ and enter TEE was described using the privileged SMC instruction, for instance here:

http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html

However it is product-family specific (I would expect Qualcomm to be different than Exynos) and I doubt there are any easy attacks left on the TZ direction itself (that must be crypto signed and so on, and the easy attacks have been already described and presumably patched already).



2. :good: Nice to see that somebody else confirmed that the rollback information is in rpmb - first that was mentioned by the z3x team (the guys selling the Easy-Jtag hardware solution) but since they will be using it for their product I do not think they will want to share anything they have learned about it :rolleyes:



3. Still IMHO attacks on knox could be done in theory easier by "rollback" rather than finding a new major exploit in the current TZ code.



4. Given that you provided the link to that Nokia PDF on TZ - what is IMHO the scenario that seems more credible to me regarding knox flag is that a value (we believe at least 2 bits, possibly more than that but unlikely to be more than 8-16 bits) from the qfuses is combined with the "device secret" mentioned and a one-way computation (hash?) of that is stored somewhere in rpmb. On boot the computation is done again and is compared to the value in rpmb - when there is a match you have knox 0, when there is no match you have knox 1. When something which is considered important is seen (like for instance during boot any kernel or recovery that is not signed by Samsung) the first free bit in the qfuse is blown; this automatically changes the computed value, and since it no longer matches the one in rpmb we see knox 1; when Samsung (or T-Mobile, see the 2 threads above) does a warranty repair they can "restore" knox - but not by "unblowing" the qfuse (which is not possible), but instead they look-up the (public) unique ID of the device, then probably do a look-up for the "device secret" (most likely somewhere at Samsung), calculate the new hash and write that new value in the rpmb, so on the next boot the computed value now matches again the (now different) value in rpmb. In this scenario if we want a solution to reset knox we "only" :rolleyes: need a way to calculate the secret and then a way to write it in rpmb. There is also the possibility that instead of calculating the new value outside the device (in that complex Samsung-involved way) they make a call inside the TZ, but that would be something to break any stupidity records since would by-pass the entire "device secret" effort.



5. One major mystery that remains in the above scenario is why N900W8 does not trigger the knox flag under certain conditions (like having TWRP as custom recovery) - still having the downgrade option is not anything special (probably the rollback restrictions are not added to the rpmb) but the TWRP recovery is certainly not signed by Samsung so at any boot knox should be set; possible explanations could be:
- the W8 boot process does not check recovery/kernel signatures on boot (?)
- the W8 boot process does the check but does not burn any other qfuse either on choice (??) or because they can not as a result of a bug (???) or as a result of already having all the qfuses blown (???? only makes sense if a very low number of bits of qfuses are dedicated to knox, 1 or at most 2).
 
Last edited:
  • Like
Reactions: mhannah3333 and tropazr
R

ryanbg

Inactive Recognized Developer
Jan 3, 2008
858
1,739
movr0.com
xclub_101 said:
1. TZ was known not to be device-specific and the overall protocol to talk to code in TZ and enter TEE was described using the privileged SMC instruction, for instance here:

http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html

However it is product-family specific (I would expect Qualcomm to be different than Exynos) and I doubt there are any easy attacks left on the TZ direction itself (that must be crypto signed and so on, and the easy attacks have been already described and presumably patched already).



2. :good: Nice to see that somebody else confirmed that the rollback information is in rpmb - first that was mentioned by the z3x team (the guys selling the Easy-Jtag hardware solution) but since they will be using it for their product I do not think they will want to share anything they have learned about it :rolleyes:



3. Still IMHO attacks on knox could be done in theory easier by "rollback" rather than finding a new major exploit in the current TZ code.



4. Given that you provided the link to that Nokia PDF on TZ - what is IMHO the scenario that seems more credible to me regarding knox flag is that a value (we believe at least 2 bits, possibly more than that but unlikely to be more than 8-16 bits) from the qfuses is combined with the "device secret" mentioned and a one-way computation (hash?) of that is stored somewhere in rpmb. On boot the computation is done again and is compared to the value in rpmb - when there is a match you have knox 0, when there is no match you have knox 1. When something which is considered important is seen (like for instance during boot any kernel or recovery that is not signed by Samsung) the first free bit in the qfuse is blown; this automatically changes the computed value, and since it no longer matches the one in rpmb we see knox 1; when Samsung (or T-Mobile, see the 2 threads above) does a warranty repair they can "restore" knox - but not by "unblowing" the qfuse (which is not possible), but instead they look-up the (public) unique ID of the device, then probably do a look-up for the "device secret" (most likely somewhere at Samsung), calculate the new hash and write that new value in the rpmb, so on the next boot the computed value now matches again the (now different) value in rpmb. In this scenario if we want a solution to reset knox we "only" :rolleyes: need a way to calculate the secret and then a way to write it in rpmb. There is also the possibility that instead of calculating the new value outside the device (in that complex Samsung-involved way) they make a call inside the TZ, but that would be something to break any stupidity records since would by-pass the entire "device secret" effort.



5. One major mystery that remains in the above scenario is why N900W8 does not trigger the knox flag under certain conditions (like having TWRP as custom recovery) - still having the downgrade option is not anything special (probably the rollback restrictions are not added to the rpmb) but the TWRP recovery is certainly not signed by Samsung so at any boot knox should be set; possible explanations could be:
- the W8 boot process does not check recovery/kernel signatures on boot (?)
- the W8 boot process does the check but does not burn any other qfuse either on choice (??) or because they can not as a result of a bug (???) or as a result of already having all the qfuses blown (???? only makes sense if a very low number of bits of qfuses are dedicated to knox, 1 or at most 2).
Click to expand...
Click to collapse

I found a very interesting log file on my device that was hidden pretty deep...

init_ddi_data: usable ddi data.
<LP> ODIN MODE
<LP> PRODUCT NAME: SM-N900V
<LP> CURRENT BINARY: Samsung Official
<LP> SYSTEM STATUS: Official
KL: API Status 0x0
KNOX KERNEL LOCK: 0x0
<LP> KNOX KERNEL LOCK: 0x0
WV: API Status 0x0
KNOX WARRANTY VOID: 0x0
<LP> KNOX WARRANTY VOID: 0x0
QFPROM oem_config1: 0x00000f03
<LP> QUALCOMM SECUREBOOT: ENABLE (CSB)
anti_en 0xf
QFPROM_RAW_AP_ANTI_ROLLBACK_ROW0_LSB: 0x10001
QFPROM_RAW_AP_ANTI_ROLLBACK_ROW1_LSB: 0x3
QFPROM_RAW_SPARE_REG19_ROW0_LSB: 0x0
<LP> RP SWREV: S1, T1, R1, A2, P0
<LP> WRITE PROTECTION: Enable
odin3_init()
udc_start()
Click to expand...
Click to collapse
 
  • Like
Reactions: mhannah3333, tropazr, Neva Eva Forget 1984 and 2 others
A

ant456

Senior Member
Apr 16, 2013
71
86
Where did you find that bootloader log file I've only had my phone for a week so I still have the 14 day warranty so I can just exchange it at the store if you have any tests you want me to do
 
A

ant456

Senior Member
Apr 16, 2013
71
86
This forum went underground too? Sounded like you guys were making some progress.
 
R

ryanbg

Inactive Recognized Developer
Jan 3, 2008
858
1,739
movr0.com
Mjoelnir77 said:
Would be interesting to know whether https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor could be used to access stuff on knox devices (and patch the system that way) that Samsung would us not want to do ...
Click to expand...
Click to collapse

I've been looking into it the past couple of days. It may be possible to use an older modem and a hacked-together ServiceMode.apk to issue AT/DM/FTM commands directly to the modem. Decompile HiddenMenu.apk, there's all sorts of goodies in there. It's a little more complicated than I'd like to think, but it seems plausible. They have their own custom firmware/RIL library though, we don't have the luxury of using that to take advantage of the exploit, so we'll have to find another way.
 
E:V:A

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
ryanbg said:
I found a very interesting log file on my device that was hidden pretty deep...
Click to expand...
Click to collapse

And where is that? (Do you know what wrote it?)

ryanbg said:
I've been looking into it the past couple of days. It may be possible to use an older modem and a hacked-together ServiceMode.apk to issue AT/DM/FTM commands directly to the modem. Decompile HiddenMenu.apk, there's all sorts of goodies in there. It's a little more complicated than I'd like to think, but it seems plausible. They have their own custom firmware/RIL library though, we don't have the luxury of using that to take advantage of the exploit, so we'll have to find another way.
Click to expand...
Click to collapse

Any progress? I did something similar for the SGS3, found tons of goodies. I'd like to see what you have if anything new.
 
R

ryanbg

Inactive Recognized Developer
Jan 3, 2008
858
1,739
movr0.com
E:V:A said:
And where is that? (Do you know what wrote it?)



Any progress? I did something similar for the SGS3, found tons of goodies. I'd like to see what you have if anything new.
Click to expand...
Click to collapse

Rollback protection information isn't stored in 'actual' QFPROM, but rather the RPMB. Both on Snapdragon and Exynos devices. The warranty bit is controlled by an actual hardware fuse in the MCU, while the Exynos warranty bit is also stored in the RPMB. I believe the RPMB may serve as a shadow register for all fuses also. I'm looking into the patches and ioctl for RPMB. I was dissecting an old unsigned RPMB from a Note 3 engineering build and found an 'SSD Keystore Encryption Key' and 'SSD Auth Key' within the TrustZone blob. Note I have a 160 bit key for both in plaintext, not a .key file. I'm not exactly sure if SSD is referring to the RPMB or the NAND chip itself, but it may be possible to send authenticated messages to TZ kernel/keystore. I can explain more in-depth via gtalk. We've got several theories.
 
  • Like
Reactions: TTLayland, Product F(RED), RuggedHunter and 3 others
david515

david515

Member
May 18, 2013
26
14
Ames
Don't know if this helps anybody wth MJE to MI9...

ryanbg said:
Downgrading is limited to the flag fuse counter values. On MJE, I can downgrade to MI9 boot image and recovery. I was able to downgrade to some pre-release engineering SBL1, RPM, and TZ because they're signed and fuse counter is only 1 for those 3. It's very benign and basic to downgrade. Just use heimdall and try downgrading an individual image. If I figure out what P is, I'll be able to test if I can flash anything related to that flag. For some reason, I can downgrade to MI9 boot and recovery, but not the system.img. I'm just starting to learn a lot about the flags/fuse counters after dissecting aboot further. If you've got any more specific questions, feel free to PM me :)
Click to expand...
Click to collapse
I was able to flash from MJE Modem down to MI9, but system Image still on MJE but ever thing else says MI9- ( don't know if that helps anyone)
 
david515

david515

Member
May 18, 2013
26
14
Ames
I'm planning on investing in JTAG...

ryanbg said:
The modem actually has rollback protection, but all modems seem to be '1' value.
Click to expand...
Click to collapse
I may be of some better help after I get a Jtag set up hopefully this next week. Thank you everyone for your efforts. J TAG has been something I've been meaning to invest in for a while.
 
S

siraltus

Senior Member
Jan 26, 2010
1,997
1,734
ryanbg said:
Rollback protection information isn't stored in 'actual' QFPROM, but rather the RPMB. Both on Snapdragon and Exynos devices. The warranty bit is controlled by an actual hardware fuse in the MCU, while the Exynos warranty bit is also stored in the RPMB. I believe the RPMB may serve as a shadow register for all fuses also. I'm looking into the patches and ioctl for RPMB. I was dissecting an old unsigned RPMB from a Note 3 engineering build and found an 'SSD Keystore Encryption Key' and 'SSD Auth Key' within the TrustZone blob. Note I have a 160 bit key for both in plaintext, not a .key file. I'm not exactly sure if SSD is referring to the RPMB or the NAND chip itself, but it may be possible to send authenticated messages to TZ kernel/keystore. I can explain more in-depth via gtalk. We've got several theories.
Click to expand...
Click to collapse

SSD could stand for System Software Debug, part of the JTAG specification.
 
  • Like
Reactions: HEXC
evilpotatoman

evilpotatoman

Senior Member
Jan 29, 2010
136
656
Charlotte
Samsung Galaxy Note 20 Ultra
ryanbg said:
Rollback protection information isn't stored in 'actual' QFPROM, but rather the RPMB. Both on Snapdragon and Exynos devices. The warranty bit is controlled by an actual hardware fuse in the MCU, while the Exynos warranty bit is also stored in the RPMB. I believe the RPMB may serve as a shadow register for all fuses also. I'm looking into the patches and ioctl for RPMB. I was dissecting an old unsigned RPMB from a Note 3 engineering build and found an 'SSD Keystore Encryption Key' and 'SSD Auth Key' within the TrustZone blob. Note I have a 160 bit key for both in plaintext, not a .key file. I'm not exactly sure if SSD is referring to the RPMB or the NAND chip itself, but it may be possible to send authenticated messages to TZ kernel/keystore. I can explain more in-depth via gtalk. We've got several theories.
Click to expand...
Click to collapse

Create folder /sdcard/ks.license and place key files there.

May need to invoke factory mode (here's how I did it):

Boot into safe strap
advanced->terminal command
navigate to /dev/block/platform/msm_sdcc.1/by-name
open terminal
mount ./efs /efs
echo OFF > /efs/FactoryApp/factorymode
echo OFF > /efs/FactoryApp/keystr
mount ./system /system
sed -i 's/build.type=user/build.type=eng/g' /system/build.prop
sed -i 's/ship=true/ship=false/g' /system/build.prop
 
  • Like
Reactions: TTLayland, Surge1223 and E:V:A
R

ryanbg

Inactive Recognized Developer
Jan 3, 2008
858
1,739
movr0.com
evilpotatoman said:
Create folder /sdcard/ks.license and place key files there.

May need to invoke factory mode (here's how I did it):

Boot into safe strap
advanced->terminal command
navigate to /dev/block/platform/msm_sdcc.1/by-name
open terminal
mount ./efs /efs
echo OFF > /efs/FactoryApp/factorymode
echo OFF > /efs/FactoryApp/keystr
mount ./system /system
sed -i 's/build.type=user/build.type=eng/g' /system/build.prop
sed -i 's/ship=true/ship=false/g' /system/build.prop
Click to expand...
Click to collapse

Where did you get this ks.license business? You can't tell me all this without giving me more clues ;)
Should I just paste plaintext key and save as .key? Also, why factory mode? There's an easier way to get into it too.

update: Not quite sure what I'm looking for or doing.
 
Last edited:
david515

david515

Member
May 18, 2013
26
14
Ames
ryanbg said:
Where did you get this ks.license business? You can't tell me all this without giving me more clues ;)
Should I just paste plaintext key and save as .key? Also, why factory mode? There's an easier way to get into it too.

update: Not quite sure what I'm looking for or doing.
Click to expand...
Click to collapse

This is encouraging check this post -- Evilpotatomans post http://xdaforums.com/showthread.php?t=2721505
I hope this helps you guys out.
Thank you!!
 
Last edited:
  • Like
Reactions: RuggedHunter
E:V:A

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
david515 said:
This is encouraging check this post -- Evilpotatomans post http://xdaforums.com/showthread.php?t=2721505
I hope this helps you guys out. Thank you!!
Click to expand...
Click to collapse

That thread was DMCA yanked faster than you can say "yank".

evilpotatoman said:
May need to invoke factory mode (here's how I did it):

Boot into safe strap
advanced->terminal command
navigate to /dev/block/platform/msm_sdcc.1/by-name
open terminal
mount ./efs /efs
echo OFF > /efs/FactoryApp/factorymode
echo OFF > /efs/FactoryApp/keystr
mount ./system /system
sed -i 's/build.type=user/build.type=eng/g' /system/build.prop
sed -i 's/ship=true/ship=false/g' /system/build.prop
Click to expand...
Click to collapse

This is weird. Any idea what this does?
It surely seem like you turn OFF Factory Mode and turn ON Engineering mode,
but I always though they'd be the same. I wonder what is different.
 
Grompy

Grompy

Senior Member
Oct 30, 2009
500
190
Noblesville, IN
E:V:A said:
That thread was DMCA yanked faster than you can say "yank".



This is weird. Any idea what this does?
It surely seem like you turn OFF Factory Mode and turn ON Engineering mode,
but I always though they'd be the same. I wonder what is different.
Click to expand...
Click to collapse


FYI google has the cached version before it was mod editted and all the stuff is still in his google drive account available for download.
 
You must log in or register to reply here.

Similar threads

Da_G
Knox/Kernel/Bootloader Development SM-900A
Replies
47
Views
41K
fire3element
fire3element
hsbadr
[KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP]
Replies
128
Views
63K
RuggedHunter
RuggedHunter
C
How do you compile a boot.img from a kernel source?
Replies
4
Views
15K
S
sansari123
FeralFire
Trying to solve the Hong Kong N9005 woes using PIT
Replies
12
Views
24K
attari13
attari13
S
Research on finding root exploit for N900V 4.4.4 (NJ6)
Replies
6
Views
4K
yenkoPR
yenkoPR

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 102
    R
    ruchirtrehan
    (Knox had been triggered on the the tested device already), This has been tested & working on Note 3 N900/Exynos on KitKat ND1 firmware which was on official status without root but Knox triggered, The file was flashed using Odin and after flashing I went into download mode and to my surprise Knox was been reset from 0x1 to 0 but the device status had turned custom (was official before flashing the Knox reset), however I will re-flash the firmware and see if Knox remains 0 and device status turns to official, also there are some different stuff in download mode which I hadn't ever seen before like EMMC PIN, Binary Sboot Version and all. I'll be attaching the screenshots for the same kindly find in attachments.

    Edit/Update 1 : After re-flashing the firmware stuff like EMMC PIN and Binary Sboot Version has disappeared Current Binary has turned to official and the Knox has remained to 0 however System Status still appears to be Custom...

    Edit/Update 2 : (Refers to previous updates regarding System Status being Custom and not turning to Official.) After trying to flash the firmware several times nothing really worked (nothing to do with Knox and Current Binary only referred to System Status being Custom) hence I went to stock recovery and wiped Data/Factory Reset and Cache Partition and then re-flashed the firmware (ND1 KitKat) and VOILA! Binary/System Status are now Official and now Knox is 0, seems a great success for the Exynos users, I also do have an snapdragon version so will be looking forward to it, screenshots attached....

    Edit/Update 3 : The steps for resetting Knox (Exynos Note 3 ONLY!) :

    1 - Download the bootloader.zip and extract bootloader from it (find in attachments)

    2 - Open Odin and put device in download mode.

    3 - Select AP/PDA (depending on Odin version you have) and select the bootloader (which was downloaded during step 1) don't select any other option in odin except F reset time and auto reboot (are selected by default).

    4 - After the file is flashed go to download mode and check if the Knox has turned back to 0.

    5 - Flash official firmware from sammobile and after flashing is done let the device reboot and boot up to device set-up screen, don't proceed the set-up for setting up device and turn of it off.

    6 - Reboot to stock recovery (power + vol up + home) and wipe data/cache and flash the firmware again, once flashing the firmware is completed enter download mode and check if current binary and system status has turned to official if not follow steps number 5 and 6 again.

    And that's pretty much it ;), you have successfully been able to reset Knox and regain warranty by this.

    PS : I had done all this steps on ND1 firmware, and this will not keep root access, to root Knox has to be tripped or keep Knox 0 but Current Binary or System Status will be custom wit Knox being 0. Also to note this might get (patched) in future updates (bootloaders) if we look at Samsung's history of patching stuff :p, though not sure about it...

    This will not work on any variant other than Exynos (Note 3) due to different processors and the boot system of both Exynos and Snapdragon. (the bootloader for (Exynos) contains Sboot which is only for the Exynos variant which cannot be used on Snapdragon as it uses Aboot). So this is by no way meant to work on SD variant or any other Samsung device ie S5/S4/Note 2 etc. and hence requested NOT TO USE IT on any other model than Exynos Note 3.

    Edit/Update 4 : Downgrading Note 3 N900/N9000/Exynos from 4.4.2 to 4,3 has been successful, check out this post by me to be updated on steps regarding the same.

    I'll be testing some work around's for the N9005 (Snapdragon) to reset Knox/Firmware Downgrade once I get that device as I have given mine to a friend, and have been saving money to buy a new or used N9005.
    View
    28
    R
    ryanbg
    WARNING:
    This is very dangerous. I have been able to reproduce and recover every time, but there is a HUGE inherent risk of permabricking. I am able to manually put my device into QHSUSB_BULK mode by overwriting SDI/DBI with SBL1. The screen will go black immediately, and your device will be recognized as a QHSUSB_BULK device. You can recover by making a 256MB (arbitrary number, has to be over like 128MB) unbrick image. This can be made by pulling the first 256MB from mmcblk0. Then flash to SD card using DD or Win32DiskImager. Do this before flashing SBL1 to DBI/SDI. Pop it in and it should boot right back normally, so ODIN and flash SDI again to fix. This can be useful for various purposes, of which the right people are already aware.
    View
    26
    R
    ruchirtrehan
    xclub_101 said:
    Quick question to have a more complete view on where things are - I do not have the N900 and I know little about it so the question might already not be a problem there but it certainly is on N9005 - can you also downgrade the firmware after you write the knox-reset piece?
    Click to expand...
    Click to collapse

    I'll test it!

    Edit/Update 1 : Wowzer guys, I have some good news for you all, I have been successfully able to downgrade from 4.4.2 to 4.3 without any issues, The firmware I downgraded to is MI3 and Knox is not present in download mode will post steps soon and guide you through steps for a safe downgrade, PS : this is only for SM-N900/N9000/Exynos for now, screenshots attached..

    Edit/Update 2 : Steps to Downgrade (Note 3 Exynos only!)

    1 - Download the bootloader.zip and extract then flash in Odin. (Find in attachments) (don't select any other option in odin except F reset time and auto reboot) (are selected by default).

    2 - Download any 4.3 JellyBean Firmware from sammobile.

    3 - After flashing the bootlaoder reboot into stock recovery (power+ home+ vol up) and wipe data/factory reset and cache partition

    4 - Turn off the device and reboot into download mode and flash the 4.3 Firmware in Odin.

    5 - After flashing completed let the device boot till boot screen and pull out the battery and turn it off then turn it on again and reboot into recovery (power+ home+ vol up) and wipe data/factory reset and cache partition once again and reboot and let the device boot up.

    That's pretty much it, you've safely downgraded to Android 4.3 from 4.4

    This is only for Note 3 Exynos!

    I'll be testing some work around's for the N9005 (Snapdragon) to reset Knox/Firmware Downgrade once I get that device as I have given mine to a friend, and have been saving money to buy a new or used N9005.
    View
    25
    X
    xclub_101
    I never had the time (and the devices) to properly research this but there are a few things that other people might want to test (or already know the answers) and I think it might come very handy to the Note 3 community. There is a somehow similar thread for the S4 community here.




    0) SUCCESS WITH KNOX / DOWNGRADING ON N900 !!!

    On N900 (Exynos) there is now a solution (unfortunately for the moment only for Exynos models) - a special firmware leaked originally here:

    http://sxtpdevelopers.com/samsung-note-3-knox-fix-qualcomm/

    (it looks like a firmware reset/update for the EMMC, which results in the erase of the RPMB where Knox flag and downgrade restrictions are stored).

    In this thread details on some of the people testing it can be found in those posts:

    http://xdaforums.com/showthread.php?p=52329946#post52329946

    http://xdaforums.com/showthread.php?p=52408318#post52408318

    If the original site is taken down by Samsung you need to search after a file called BL_HA3GZS_CLEAR_WARRANTY_BIT.tar - the one I saw was 2334801 bytes in length (might be shown as a 2.23MB download in some chinese sites). There might be a problem finding it since Samsung might go after anybody hosting and distributing it.


    1) Just rooting should not trip knox

    The problem with rooting that makes knox 0x1 - originally Root De La Vega was developed for the AT&T very locked structure, and as such it was doing the rooting in a pretty convoluted way. However on other Note 3 versions the knox warranty flag is very clearly linked to just kernel and recovery, and not to system itself. In other words it SHOULD be possible (even after MJ3) to root and keep knox 0x0 on devices that are not "bootloader locked" by not touching kernel and recovery and only touching system - that is probably NOT going to work on AT&T (N900A) but it seems to work on N900W8 and IMHO it could also work on N9005 (and possibly N9000, but I know much less about that). If you want more proof look into the posts about N900W8 + different version (of more or less) stock-based ROMs (like xnote, but stock kernel and recovery).

    So the bottom line on this is to verify on a knox 0x0 device with firmware MJ3 (or newer) that just writing a pre-rooted system would be allowed in download mode and would keep knox 0x0. And we would need a more clear confirmation for both N900W8 and N9005 (or any other models) - of course with some description of what was written and how ;)

    EDIT: some W8 users have provided extra details and so far it looks it might be more the bootloader itself and not so much in how/what is written, but more information is needed.
    EDIT2: there is a thread with that kind of talk here:
    http://xdaforums.com/showthread.php?t=2627996



    2) We should really test the "portability" of various bootloaders since this could solve a lot of things

    First - here are two external (non-xda) pages with some very good development information regarding "bootloader hacking":

    http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html

    http://blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html

    On bootloader-confused devices (for instance Hong-Kong versions that got the KitKat bootloader from Polish/XEO KK and have to wait for Hong-Kong KitKat, or any device that seems to be bricked in the bootloader) it might be also interesting (for somebody VERY daring - remember that it could brick your phone even worse) to try to write the bootloader files (all 5 of them?) from the N900W8 and see if those are accepted (since once that would be the case downgrading would also become a possibility).

    EDIT: the N900W8 is also reported (see here) to let you have a custom recovery and not trip knox, which is kind of weird but maybe this is the knox breakthrough that we were expecting :)



    3) More info on STRAP flags (those listed in download mode)

    STRAP flags - there are a number of places where the values listed in download mode are discussed, for instance:

    http://xdaforums.com/showthread.php?t=2567165

    It seems that the values for S T R A and P flags could be versions of the 5 main bootloader-related files used in Qualcomm-based Note 3 devices, most likely:

    S - SBL1

    T - TZ

    R - RPM

    A - ABOOT

    P - SDI (?)


    My EU N9005 (I believe with MI7 or so bootloader) was something like S1, T1, R1, A1, P1 and also SECUREBOOT: ENABLE (CSB) (as it can be seen in the thread above) but is now P2 (which is very strange since I had all automatic and security updates disabled, but might be related to the fact that at some point I activated the reactivation flag linked to the Samsung account - disabling it does not return P back to 1 so this might not be it).

    Also if you look around the values seem to be somehow consistent - with post-MJ3 bootloader most flags become 2 and with KitKat bootloader at least the A flag becomes 3.

    It remains to be seen if this is the case and if it is any way relevant to hacking the bootloader system or knox (or is just for debug purposes - like when we see people with A3 complaining that they can't return to stock MJ7 or MK2).


    4) More info on "microSD debricking and if this could let us re-write different bootloader files (and maybe we should encourage people to have their "debricking image" made in advance "just in case")

    When the bootloader files become "bad" and you can not go in download mode (but probably sbl1 is still valid) it is still possible to recover things by forcing the boot process from microSD. That seems to require no extra hardware on Qualcomm models and one small contact for Exynos devices (where that is even documented in Samsung original documents like 13-58_SM-N900_Boot_Recovery_Guide_rev1.0.pdf).

    There is a thread on this at:

    http://xdaforums.com/showthread.php?t=2625332



    5) More info on how Samsung CAN reset knox

    There are already two threads with something more than 5-6 first-hand reports from people that went with a Note 3 knox 0x1 into service and left with the same device (and motherboard and IMEI and in some cases all their programs and even their normal/old firmware) but with knox 0x0!

    One thread in T-Mobile Note 3 forum:

    http://xdaforums.com/showthread.php?t=2637718

    And a much larger one in International Note 3 forum:

    http://xdaforums.com/showthread.php?t=2504258

    There is also already a "hardware+software solution" (expensive, aimed at specialized phone shops that also do phone unlocking and similar stuff) which claims to be able to reset the knox flag on Exynos devices:

    http://forum.gsmhosting.com/vbb/f67...olution-solution-repair-rebuild-emmc-1769456/
    http://forum.gsmhosting.com/vbb/f67...bit-0-solution-inside-first-ih-world-1776265/
    http://forum.gsmhosting.com/vbb/f672/regarding-knox-s4-1775213/




    6) Pre-production bootloaders before knox?

    Here is an interesting thread apparently about a N9005 with no knox:

    http://xdaforums.com/showthread.php?t=2657631
    View
    23
    R
    ryanbg
    RaluSiCris said:
    it can be made a how to in order to be useful for all of us? It would be really appreciated.
    Thanks

    Sent from my SM-N9005 using xda app-developers app
    Click to expand...
    Click to collapse

    If you don't know how it can be useful, this is probably not the best place for you to be posting.
    View

New posts