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

[BrunoWestone]

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.

 

[ryanbg]

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

 

[A.S._id]

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

 

[E:V:A]

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:

[SIZE=2]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.
[/SIZE]

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

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.

 

[ryanbg]

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:

[SIZE=2]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.
[/SIZE]

(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

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.

 

[ryanbg]

"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

 

[ryanbg]

Factory Jig

@E:V:A

We've been waiting for this for awhile.

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

05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for [B]FACTORY[/B] BIN

but I can also activate:

05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for [B]USER[/B] 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...

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][B] FMMApplication[/B] 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

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.

 

[evilpotatoman]

@E:V:A

We've been waiting for this for awhile.

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

05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for [B]FACTORY[/B] BIN

but I can also activate:

05-21 13:58:38.327 D/FactoryTestApp(6664): [RegisterFactoryBinHandler$registerHandler] Register AT command handler for [B]USER[/B] 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...

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][B] FMMApplication[/B] 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

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

 

[E:V:A]

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:

[SIZE=2]# 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 $*[/SIZE]

So it would be interesting to see what other options that jar supports.
Have you tried decompiling it?

 

[ryanbg]

And svc is just the following script:

[SIZE=2]# 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 $*[/SIZE]

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.

 

[E:V:A]

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

 

[shayind4]

Towelroot by Geohot

Hey guys

Check towelroot by Geohot. It works on P605 and Knox 0x0.

http://forum.xda-developers.com/showthread.php?t=2783157

 

[vacaloca]

Talk of this came up on the S5 bootloader thread as a possible vulnerability in aboot:
http://forum.xda-developers.com/showpost.php?p=53482874&postcount=1006

Figured this might be a place where it could get some thought/exposure.

 

[siraltus]

So Samsung's giving up on Knox: http://www.forbes.com/sites/bobegan...ixs-knox-the-android-security-saga-continues/

I wonder if they'll eventually give us a bootloader with no more Knox warranty flag.

 

[Product F(RED)]

So Samsung's giving up on Knox: http://www.forbes.com/sites/bobegan...ixs-knox-the-android-security-saga-continues/

I wonder if they'll eventually give us a bootloader with no more Knox warranty flag.

They're not really giving up on Knox. If you read articles about Android L's security, you'll see that Samsung "gave" Google portions of Knox's code so that it could be implemented into Android itself.

 

[siraltus]

They're not really giving up on Knox. If you read articles about Android L's security, you'll see that Samsung "gave" Google portions of Knox's code so that it could be implemented into Android itself.

Yes, I read it. However, if you read the article, you'll see that Google's implementation of the container is different from Knox, and not backwards compatible.

The question of whether Android L will require a tamper flag in the bootloader remains to be answered - Google can drop it by using a different implementation, or they could require all devices to have it, which would be a PITA to implement in existing handsets that lack the eFuse and secure boot logic. I could see it being available only on flagship devices, as your regular S3-carrying Joe Schmoe could not care less about a secure container. Any device based on the Snapdragon 800 series chip will become compatible with just a bootloader update, as those SoCs have all the required hardware to implement the tamper flag.

 

[Er. Aditya]

They're not really giving up on Knox. If you read articles about Android L's security, you'll see that Samsung "gave" Google portions of Knox's code so that it could be implemented into Android itself.

thanks samsung for making it more idiotic then it was

 

[Product F(RED)]

Yes, I read it. However, if you read the article, you'll see that Google's implementation of the container is different from Knox, and not backwards compatible.

The question of whether Android L will require a tamper flag in the bootloader remains to be answered - Google can drop it by using a different implementation, or they could require all devices to have it, which would be a PITA to implement in existing handsets that lack the eFuse and secure boot logic. I could see it being available only on flagship devices, as your regular S3-carrying Joe Schmoe could not care less about a secure container.

I can't see Samsung backpeddling on the bootloader flag, since a tamper flag is a vital part of security. It just happens to be that it gets in the way of modifying our phones (for warranty purposes). I think they're just giving up on marketing Knox as their own in-house product and relying on Google to do the heavy-lifting. That way there's no weight on their shoulders in terms of security and cost of building and maintaining Knox.

 

[siraltus]

I can't see Samsung backpeddling on the bootloader flag, since a tamper flag is a vital part of security. It just happens to be that it gets in the way of modifying our phones (for warranty purposes). I think they're just giving up on marketing Knox as their own in-house product and relying on Google to do the heavy-lifting. That way there's no weight on their shoulders in terms of security and cost of building and maintaining Knox.

That's my point. Since the tamper flag's main purpose is to indicate the integrity of the secure container, perhaps in Android L it will be decoupled from any hardware warranty claims and be software-resettable by some kind of enterprise administration authority that configures the secure container, such as your employer, and not just Samsung. Here's to hoping.

 

[ryanbg]

Was able to manually set the CC mode flag via a couple dalvik bytecode patches via a few security mechanisms. More to come. Should be exciting and seems promising.