FORUMS
Remove All Ads from XDA

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

1,240 posts
Thanks Meter: 359
 
By xclub_101, Senior Member on 9th February 2014, 04:08 PM
Post Reply Email Thread
19th May 2014, 10:27 AM |#101  
Member
Flag London
Thanks Meter: 137
 
More
Quote:
Originally Posted by RuchRha

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.

Great Job there !!!

I have a N9005 with me reactivation lock = on and knox 0x0 if you have some news we can test on this one.

I can vois the knox on propose and test any solution on it.
19th May 2014, 02:20 PM |#102  
Inactive Recognized Developer
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by E:V:A

No, I think you misunderstood, or so did the other guy. If there is really FW for the EMMC chip controller itself, that is completely different from any normal partitions.

On 4.3 releases of VZW Note 3, in /sbin there is an exectuable called ffu (firmware update utility) built for eMMC FW. It appears it was released by Samsung. It's a small command line tool with options to update FW via (ffu -u). Perhaps this is a place to start, although I will not be attempting anything of the sort without JTAG. It's almost a sure-fire way of getting a permanent brick, one you would need an eMMC adaptor to reprogram entirely. Even Riff Box is not capable of this yet. I believe Z3x could do it, but who knows about firmware..
The Following 6 Users Say Thank You to ryanbg For This Useful Post: [ View ] Gift ryanbg Ad-Free
19th May 2014, 06:40 PM |#103  
A.S._id's Avatar
Inactive Recognized Developer
Thanks Meter: 2,586
 
Donate to Me
More
Quote:
Originally Posted by E:V:A

Hmm, that is interesting. How is that EMMC FW file written?
Can you provide that file? It need to be reversed!
This could be another step towards resolving the Qualcomm
case, as long as they use the same EMMCs.

you can find the same file into testing bootloader package in param.bin. Rename .bin to .tar and extract this. you'll see some images and file 'emmc_fw.bin_enc' - and this is a updating memories file...
The Following 4 Users Say Thank You to A.S._id For This Useful Post: [ View ] Gift A.S._id Ad-Free
20th May 2014, 12:55 PM |#104  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,216
 
More
Quote:
Originally Posted by ryanbg

On 4.3 releases of VZW Note 3, in /sbin there is an exectuable called ffu (firmware update utility) built for eMMC FW. It appears it was released by Samsung. It's a small command line tool with options to update FW via (ffu -u). Perhaps this is a place to start, although I will not be attempting anything of the sort without JTAG. It's almost a sure-fire way of getting a permanent brick, one you would need an eMMC adaptor to reprogram entirely. Even Riff Box is not capable of this yet. I believe Z3x could do it, but who knows about firmware..

The "ffu" stand for: Field Firmware Update, as i documented in THIS post some time ago.

This is very interesting! The Samsung EMMC's are usually based on a Cortex-M3 microcontroller. The cool thing about Cortex-M3's, are that they are easy to program, understand and very well documented. Furthermore:

Code:
The Debug Host Interface

Currently Cortex-M3 systems support two types of debug host interface: 
The first one is the well-known JTAG interface, and the second one is 
a new interface protocol called Serial-Wire (SW). The SW interface 
reduces the number of signals to two. Several types of debug host 
interface modules (called Debug Port, or DP) are available from ARM. 
The debugger hardware is connected to one side of a DP, and the other 
side is connected to the DAP interface on the processor.

The Cortex-M3 is targeted at the low-cost microcontroller market in 
which most devices have very low pin counts. For example, some of the 
low-end versions are in 28-pin packages. Despite the fact that JTAG is 
a very popular protocol, using four pins to debug is a lot for a 
28-pin device. Therefore, SW is an attractive solution because it can 
reduce the number of debug pins to two.
(Excerpt from "The Definitive Guide to the ARM Cortex-M3".)

This means that there is a 2+1 pin serial interface available on all EMMCs that we should be able to access and use just like JTAG (which is overkill).

Quote:
Originally Posted by A.S._id

you can find the same file into testing bootloader package in param.bin. Rename .bin to .tar and extract this. you'll see some images and file 'emmc_fw.bin_enc' - and this is a updating memories file...

The name of that file seem to suggest it's either "encoded" or "encrypted", in either case. we should be able to find out how, by reversing or close inspection of the "ffu" program. Actually, now that I think about it, I think it is part of the source code. I remember some of these FW blobs from an old thread about EMMC sudden death due to faulty EMMC FW, in an old SGS3 thread (above). They were distributed in ./drivers/mmc/ffu/fw.h but have probably been encrypted since out posts extracted them. (We can probably still read ram or make a ram dump.)

BTW. EMMC CMD62 can be used to read/write EMMC FW/RAM.
The Following 12 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
20th May 2014, 04:18 PM |#105  
Inactive Recognized Developer
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by E:V:A

The "ffu" stand for: Field Firmware Update, as i documented in THIS post some time ago.

This is very interesting! The Samsung EMMC's are usually based on a Cortex-M3 microcontroller. The cool thing about Cortex-M3's, are that they are easy to program, understand and very well documented. Furthermore:

Code:
The Debug Host Interface

Currently Cortex-M3 systems support two types of debug host interface: 
The first one is the well-known JTAG interface, and the second one is 
a new interface protocol called Serial-Wire (SW). The SW interface 
reduces the number of signals to two. Several types of debug host 
interface modules (called Debug Port, or DP) are available from ARM. 
The debugger hardware is connected to one side of a DP, and the other 
side is connected to the DAP interface on the processor.

The Cortex-M3 is targeted at the low-cost microcontroller market in 
which most devices have very low pin counts. For example, some of the 
low-end versions are in 28-pin packages. Despite the fact that JTAG is 
a very popular protocol, using four pins to debug is a lot for a 
28-pin device. Therefore, SW is an attractive solution because it can 
reduce the number of debug pins to two.
(Excerpt from "The Definitive Guide to the ARM Cortex-M3".)

This means that there is a 2+1 pin serial interface available on all EMMCs that we should be able to access and use just like JTAG (which is overkill).



The name of that file seem to suggest it's either "encoded" or "encrypted", in either case. we should be able to find out how, by reversing or close inspection of the "ffu" program. Actually, now that I think about it, I think it is part of the source code. I remember some of these FW blobs from an old thread about EMMC sudden death due to faulty EMMC FW, in an old SGS3 thread (above). They were distributed in ./drivers/mmc/ffu/fw.h but have probably been encrypted since out posts extracted them. (We can probably still read ram or make a ram dump.)

BTW. EMMC CMD62 can be used to read/write EMMC FW/RAM.

Keep in mind CMD62 is a vendor specific command, Samsung in this case, and can have unintended consequences. This command can also resize the boot partition and other things dangerous. The adv-env.img simply contains a kernel command line
Code:
console=ram loglevel=4
So what we can tell so far, sboot is loaded into the RAM, and the eMMC firmware file is loaded also. I wonder if it is some sort of service firmware for the eMMC chips? I do know that there are OTP (one time programmable) OEM specific 'fuses' if you will, but some of these can be reset even though most documentation specifies otherwise. The question is, do the Exynos and Snapdragon devices share a common eMMC chip, is the firmware universal, and is there anything special about the sboot image (insecure, unlocked?)

I've also noticed refernces in aboot to RDX protocol. Samsung has a 3-core controller for it's SSDs called RDX, perhaps this has been applied to eMMC chips.
The Following 7 Users Say Thank You to ryanbg For This Useful Post: [ View ] Gift ryanbg Ad-Free
21st May 2014, 09:37 PM |#106  
Inactive Recognized Developer
Thanks Meter: 1,751
 
More
Code:
"act_lock: SecureBoot is enabled, write data in RPMB"
"act_lock: TEST BIT is enabled"
"act_lock: SecureBoot is not enabled yet."
"act_lock: Success to set RPMB flag on [%d]"
"act_lock: Success to set RPMB flag off [%d]"
"act_lock: Success to get RPMB flag [%d]"
"create certi failed !!"
"rsa_public_key_parse() failed"
"rsa_private_key_parse() failed"
qwertysmerty0987654321pqrstuvwe
/efs/lm/
/efs/lm/FMM.dat
"act_lock: Success to update initial flags! [%d]"
"act_lock: Success to update MAGIC string! [%d]"
"act_lock: Success to update flags! [%d]"
act_lock is an HLOS application, running on the Qualcomm DSP known as Hexagon. It is a small elf that is found in NON-HLOS. This application communicates with the Secure World in TrustZone, as do the rest of the HLOS applications. They are managed and dictated by QSEECom. The device driver for this can be found @ /dev/qseecom
The Following 8 Users Say Thank You to ryanbg For This Useful Post: [ View ] Gift ryanbg Ad-Free
22nd May 2014, 02:26 PM |#107  
Inactive Recognized Developer
Thanks Meter: 1,751
 
More
Factory Jig
@E:V:A

We've been waiting for this for awhile.

Code:
I/WSOMACP (21188): [44.131211][Line:117][xcpSystemSetCPFeature] XCP_FEATURE_SECURITY: 4369
This appears to be the SECURE SECBOOT VAL (4369) from the Secure Boot status menu inside the Hidden Menu/RIL. On top of this it gets better.

I made a factory jig for my Note 3. This is what I wanted you to see E:V:A
Code:
05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for FACTORY BIN
but I can also activate:
Code:
05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for USER BIN
It appears I've found a way past the AT filter using a Download/Factory mode jig. I have a log of even more stuff...

Code:
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:214][xdmCheckActivationLock] bActivationLock : false
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:40][onCreate] FMMApplication NOT Start !
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:110][onReceive] android.intent.action.SIM_STATE_CHANGED
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:113][onReceive] OHLJId+BT1o/PC9rzbVguJU3RzR99gWwlWgpAix4qF0=
E/DBG_FMMDM(18131): Warning!!! [v2_f18_1312_1_1][Line:117][onReceive] DM Not Init
Code:
05-21 13:58:38.837 I/ServiceManager(822): Waiting for service AtCmdFwd...
Contact me for a full log. There's way more. I think a factory jig is going to push us in the right direction.
The Following 24 Users Say Thank You to ryanbg For This Useful Post: [ View ] Gift ryanbg Ad-Free
24th May 2014, 08:15 PM |#108  
evilpotatoman's Avatar
Senior Member
Flag Charlotte
Thanks Meter: 658
 
Donate to Me
More
Quote:
Originally Posted by ryanbg

@E:V:A

We've been waiting for this for awhile.

Code:
I/WSOMACP (21188): [44.131211][Line:117][xcpSystemSetCPFeature] XCP_FEATURE_SECURITY: 4369
This appears to be the SECURE SECBOOT VAL (4369) from the Secure Boot status menu inside the Hidden Menu/RIL. On top of this it gets better.

I made a factory jig for my Note 3. This is what I wanted you to see E:V:A
Code:
05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for FACTORY BIN
but I can also activate:
Code:
05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for USER BIN
It appears I've found a way past the AT filter using a Download/Factory mode jig. I have a log of even more stuff...

Code:
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:214][xdmCheckActivationLock] bActivationLock : false
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:40][onCreate] FMMApplication NOT Start !
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:110][onReceive] android.intent.action.SIM_STATE_CHANGED
I/DBG_FMMDM(18131): [v2_f18_1312_1_1][Line:113][onReceive] OHLJId+BT1o/PC9rzbVguJU3RzR99gWwlWgpAix4qF0=
E/DBG_FMMDM(18131): Warning!!! [v2_f18_1312_1_1][Line:117][onReceive] DM Not Init
Code:
05-21 13:58:38.837 I/ServiceManager(822): Waiting for service AtCmdFwd...
Contact me for a full log. There's way more. I think a factory jig is going to push us in the right direction.

I'm not sure if this is common knowledge but the following enables a mess of debug details;
svc power reboot debug0x4948
svc power reboot cpdebug0x5500
The Following 8 Users Say Thank You to evilpotatoman For This Useful Post: [ View ] Gift evilpotatoman Ad-Free
5th June 2014, 01:52 PM |#109  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,216
 
More
Quote:
Originally Posted by evilpotatoman

I'm not sure if this is common knowledge but the following enables a mess of debug details;
svc power reboot debug0x4948
svc power reboot cpdebug0x5500

And svc is just the following script:
Code:
# Script to start "am" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/svc.jar
exec app_process $base/bin com.android.commands.svc.Svc $*
So it would be interesting to see what other options that jar supports.
Have you tried decompiling it?
The Following 4 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
5th June 2014, 02:47 PM |#110  
Inactive Recognized Developer
Thanks Meter: 1,751
 
More
Quote:
Originally Posted by E:V:A

And svc is just the following script:

Code:
# Script to start "am" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/svc.jar
exec app_process $base/bin com.android.commands.svc.Svc $*
So it would be interesting to see what other options that jar supports.
Have you tried decompiling it?

I have recently, and found some things of interest I'd like to have you take a look at. I'll send you a PM.
The Following 8 Users Say Thank You to ryanbg For This Useful Post: [ View ] Gift ryanbg Ad-Free
6th June 2014, 12:42 AM |#111  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,216
 
More
Quote:
Originally Posted by ryanbg

I have recently, and found some things of interest I'd like to have you take a look at. I'll send you a PM.

Waiting for PM...
The Following 5 Users Say Thank You to E:V:A For This Useful Post: [ View ] Gift E:V:A Ad-Free
Post Reply Subscribe to Thread

Tags
knox, root
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes