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

[david515]

I'm still

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.

I'm thinking factory mode is without any protection. gives us full freedom to do with almost anything without security? Just thinking.

---------- Post added at 10:24 AM ---------- Previous post was at 10:14 AM ----------

This is encouraging check this post -- Evilpotatomans post http://forum.xda-developers.com/showthread.php?t=2721505
I hope this helps you guys out.
Thank you!!

That sucks it was yanked.

 

[GermanBrot]

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.

Nice... did you notice the SHA256certkey.txt? Think that is all we need?

 

[FauxPasIII]

Nice... did you notice the SHA256certkey.txt? Think that is all we need?

It's there.

 

[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.

 

[RaluSiCris]

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. 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.

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

 

[ryanbg]

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

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

 

[E:V:A]

I just got a long shot theory, that need investigation.

It could work for Qualcomm based QFUSE Knox'ing.

The idea is this:

When QFUSE is written, it has to go through a special high-current/voltage power rail, triggered by the qfuse code (we already have). What we can do is to prevent enough power to reach the chip the qfuse is located on, by either on-the-fly patching the qfuse code, or by putting a resistive load, detected and timed exactly when this write happens. This would hopefully cause the QFPROM write to fail within a few attempts or timeout. It should be easily constructed by using standard tools like BusPirate, Arduino or RasberryPi. In the best case scenario, we might just have to solder a resistor somewhere. In the worst, the qfuse code goes into an infinite loop, completely blocking the device.

Please look at the code to determine feasibility for this HW hack.

 

[Product F(RED)]

I just got a long shot theory, that need investigation.

It could work for Qualcomm based QFUSE Knox'ing.

The idea is this:

When QFUSE is written, it has to go through a special high-current/voltage power rail, triggered by the qfuse code (we already have). What we can do is to prevent enough power to reach the chip the qfuse is located on, by either on-the-fly patching the qfuse code, or by putting a resistive load, detected and timed exactly when this write happens. This would hopefully cause the QFPROM write to fail within a few attempts or timeout. It should be easily constructed by using standard tools like BusPirate, Arduino or RasberryPi. In the best case scenario, we might just have to solder a resistor somewhere. In the worst, the qfuse code goes into an infinite loop, completely blocking the device.

Please look at the code to determine feasibility for this HW hack.

Very good way of looking at it. Proactive instead of reactive; forget trying to reset the eFuses (which is impossible), and prevent them from being tripped/blown to begin with. :good:

 

[david515]

Very good way of looking at it. Proactive instead of reactive; forget trying to reset the eFuses (which is impossible), and prevent them from being tripped/blown to begin with. :good:

At first I was think there might be a way of a bypass but I am lost on this and realize this whole bootloader is way more complex then I once thought, and on other thoughts someone very well could custom write and custom designed a whole bootloader and that would be the fix to this dilemma.I don't have all the knowledge or time to do such a feat.

@Eva I think your Idea is good and worth looking into for sure.Thanks for your help.

I am burned out on this Knox bootloader at this point. I'm going to sell my retail SM-N900V and get a different carrier different gn3 phone that isn't locked
maybe tmobile.

 

[Product F(RED)]

At first I was think there might be a way of a bypass but I am lost on this and realize this whole bootloader is way more complex then I once thought, and on other thoughts someone very well could custom write and custom designed a whole bootloader and that would be the fix to this dilemma.I don't have all the knowledge or time to do such a feat.

@Eva I think your Idea is good and worth looking into for sure.Thanks for your help.

I am burned out on this Knox bootloader at this point. I'm going to sell my retail SM-N900V and get a different carrier different gn3 phone that isn't locked
maybe tmobile.

If you're not on Verizon (as in you're currently using a Verizon model on a different carrier), the T-Mobile version is your only option as far as unlocked bootloaders go (for GSM). You could get the Sprint model and hack-unlock it for domestic GSM (it blocks US SIM cards even when unlocked by default). Or you could get the SM-900V Dev Edition which is rare and expensive. I recommend the T-Mobile model. I have it and it's the easiest to deal with.

Sent from my SM-N900T using Tapatalk

 

[E:V:A]

Looong shot number two. (Qualcomm)

This is regarding a quasi-SW hack.

I think it would be extremely useful if someone could start charting out the exact chain of events, leading up to a qfuse write. I'd like to see a chart, kind of what we had for the SecureBoot2 stuff in the 8960... But I'm totally not up-to-date on the current Knox research status, so perhaps this has been done already?

Anyway, the idea is as follows. If at any point the Knox detection mechanism is using code from the modem Hexagon processor, I can almost bet my behind that there could be a hidden proprietary function in the Modem code, that could disable Knox flag. Knowing Qualcomm has their 80 MB blobs of Hexagon RTOS code, this would be some crazy feat to accomplish, but certainly not impossible. (Most of it is redundant anyway, often having ~3 copies of modem binaries, for example.) So if this is possible, I would assume there could be some hidden AT commands accessible from modem terminal shell that temporarily disables Knox fuse.

Where to look? We would need to reverse all the AT command functions using IDA Pro and the Hexagon plugins, and look for code that is related to Qfuse burning. (There is probably a lot of this code, since the recent discovery show that many RF variables are now also using qfuses.) That's why we need to make the chart above...

But given the low RoE (Return of Effort), I actually do not recommend spending too much time on this, unless Knox is starting to cause real trouble to people.

 

[Surge1223]

Looong shot number two. (Qualcomm)

This is regarding a quasi-SW hack.

I think it would be extremely useful if someone could start charting out the exact chain of events, leading up to a qfuse write. I'd like to see a chart, kind of what we had for the SecureBoot2 stuff in the 8960... But I'm totally not up-to-date on the current Knox research status, so perhaps this has been done already?

Anyway, the idea is as follows. If at any point the Knox detection mechanism is using code from the modem Hexagon processor, I can almost bet my behind that there could be a hidden proprietary function in the Modem code, that could disable Knox flag. Knowing Qualcomm has their 80 MB blobs of Hexagon RTOS code, this would be some crazy feat to accomplish, but certainly not impossible. (Most of it is redundant anyway, often having ~3 copies of modem binaries, for example.) So if this is possible, I would assume there could be some hidden AT commands accessible from modem terminal shell that temporarily disables Knox fuse.

Where to look? We would need to reverse all the AT command functions using IDA Pro and the Hexagon plugins, and look for code that is related to Qfuse burning. (There is probably a lot of this code, since the recent discovery show that many RF variables are now also using qfuses.) That's why we need to make the chart above...

But given the low RoE (Return of Effort), I actually do not recommend spending too much time on this, unless Knox is starting to cause real trouble to people.

I looked into the command to set the knox flag/fuse/warranty bit and the underlying function. And you may be right about hexagon since hlos has the strings in it that say "device is tampered!" etc...and a secure monitor call to set the warranty void flag goes to an address in tz memory. I think itd take a while to figure out the who, what, where, just by examining assembly without a kernel, TrustZone, or hexagom vulnerability...plus its a mix of arm/thumb/random blobs.

Sent from my SCH-I545 using XDA Premium 4 mobile app

 

[david515]

I found this and wondered if this may hlp

I looked into the command to set the knox flag/fuse/warranty bit and the underlying function. And you may be right about hexagon since hlos has the strings in it that say "device is tampered!" etc...and a secure monitor call to set the warranty void flag goes to an address in tz memory. I think itd take a while to figure out the who, what, where, just by examining assembly without a kernel, TrustZone, or hexagom vulnerability...plus its a mix of arm/thumb/random blobs.

Sent from my SCH-I545 using XDA Premium 4 mobile app

I found this link on a knox reset .I don't know if this is reliable as of yet? but interesting if it is for real.
http://sxtpdevelopers.com/samsung-note-3-knox-fix-qualcomm/

 

[stash9123]

I found this link on a knox reset .I don't know if this is reliable as of yet? but interesting if it is for real.
http://sxtpdevelopers.com/samsung-note-3-knox-fix-qualcomm/

took the plunge and tried flashing just the param.bin no harm was done to my device how ever knox is still 0x1

 

[swnt]

This is on their site:

so next is Quallcomm…

 

[RuchRha]

(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 , 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.

 

[xclub_101]

...
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 file for resetting Knox (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.

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?

 

[RuchRha]

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?

That's a pretty interesting question, I hadn't really thought about it but I guess to give it a shot pretty soon, I am out of town atm so will try and do it asap and let you know if it could be possible to do so..

 

[haybill]

Hello @RuchRha--I saw you on another thread and tracked you down to this one--it has been reported that flashing Root using CF-Root, to a Canadian N900W8, was possible to do without compromising KNOX warranty counter-- do you know whether the same applies to SM N900 variant?

Apologies if this has been asked./answered but couldn't find reference to the answer.

 

[smeet.somaiya]

That's a pretty interesting question, I hadn't really thought about it but I guess to give it a shot pretty soon, I am out of town atm so will try and do it asap and let you know if it could be possible to do so..

Attempting to downgrade is worth trying. If it succeeds it would be great. If it fails with "Firmware Upgrade encountered issue" no worries just flash stock recovery back and the phone would be up again.

Sent from my Galaxy S5 GT-N7100