yashsingh1/xdaforums huggingface dataset:
[Galaxy Note 3 Developer Discussion [Developers Onl] nicholaschum:
How about the check whether KNOX is actually tripped on an N900W8 without knowing it yet, we're still on the two region different bootloaders -

Leaked Mexican NA2

and Canadian NB7, which is identical as they are the first N900W8 4.4.2 ROM bootloaders.

Well first of all, as the Mexican NA2 is a leak, you can't download it officially anywhere, and could have been a leak from a developer build.

Also to think, why does this only work on the Canadian N900W8 and not the Mexican N900W8? (verify this for me, I have seen 0 reports of successful Mexican 0x0 flashes as of yet).

We essentially flash Mexican NA2 over Canadian 4.3 which allows us to do anything we want and not trip KNOX. BUT -> If you flash official NB7 Canadian, you cannot downgrade back to an older firmware and not trip KNOX, unlike on NA2 Mexican.

Is there a possibility that the chip already blown the fuse but the system fails to detect that particular fuse due to a bug, and still reports fine to the system (Bootloader view, and in-system view (Phone Info))?
[Galaxy Note 3 Developer Discussion [Developers Onl] schndr777:
Here is the link

Subhash Chander has shared a file with you - Subhash Chander shared "BL_HA3GZS_CLEAR_WARRANTY_BIT.tar": https://onedrive.live.com/redir?resid=1676562414352B19!1399&authkey=!AGWIAuosxXwO66E&ithint=folder,
[Galaxy Note 3 Developer Discussion [Developers Onl] NoteboyTech:
I still have that attached bootloader, which was on that website, if anyone wants I can give them via a PM
[Galaxy Note 3 Developer Discussion [Developers Onl] NoteboyTech:
Guys, those who need it.. [MENTION=1981426]alok_dhawal[/MENTION]

https://drive.google.com/file/d/0ByVK-G_0rAexX3h3RUpfR095Tm8/edit?usp=sharing

Please hit thanks and keep helping others.. hehe!

HIT THANKS!
[Galaxy Note 3 Developer Discussion [Developers Onl] malybru:
Mod Edit

Thread cleaned.

Please note the title of this forum:

Galaxy Note 3 Developer Discussion [Developers Only]

If you are not actively helping with the Development , please do not post here

Thank you.

malybru

Forum Moderator
[Galaxy Note 3 Developer Discussion [Developers Onl] hobbit19:
http://www.openwall.com/lists/oss-security/2014/05/12/3
[Galaxy Note 3 Developer Discussion [Developers Onl] frostmore:
For those who are interested in this software,PM me and i'll let you have a copy.

I have nothing against qualcomm or a big fan of distributing copyrighted stuff.

but my inherent dislike/distaste/discomfort for samdung's douche baggery and high handedness in forcing their obKNOXous crap down consumers do not sit very well with me.

if you can come up with something to stick it to samdung,let me know,i'll like to help.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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.
[Galaxy Note 3 Developer Discussion [Developers Onl] Surge1223:
It contains sboot and param. The qualcomm equivalent would be aboot and param.
[Galaxy Note 3 Developer Discussion [Developers Onl] RaluSiCris:
I if just somebody with 0x0 knox can find in his phone aboot and param and then to be compared with those from 0x1
[Galaxy Note 3 Developer Discussion [Developers Onl] 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.
[Galaxy Note 3 Developer Discussion [Developers Onl] BrunoWestone:
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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..
[Galaxy Note 3 Developer Discussion [Developers Onl] 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...
[Galaxy Note 3 Developer Discussion [Developers Onl] 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:

[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.
[Galaxy Note 3 Developer Discussion [Developers Onl] ryanbg:
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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
[Galaxy Note 3 Developer Discussion [Developers Onl] ryanbg:
Factory Jig

[MENTION=4372730]E:V:A[/MENTION]

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.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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
[Galaxy Note 3 Developer Discussion [Developers Onl] E:V:A:
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?
[Galaxy Note 3 Developer Discussion [Developers Onl] 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.
[Galaxy Note 3 Developer Discussion [Developers Onl] E:V:A:
Waiting for PM...
[Galaxy Note 3 Developer Discussion [Developers Onl] :
Towelroot by Geohot

Hey guys

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

http://xdaforums.com/showthread.php?t=2783157
[Galaxy Note 3 Developer Discussion [Developers Onl] vacaloca:
Talk of this came up on the S5 bootloader thread as a possible vulnerability in aboot:

http://xdaforums.com/showpost.php?p=53482874&postcount=1006

Figured this might be a place where it could get some thought/exposure.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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.
[Galaxy Note 3 Developer Discussion [Developers Onl] Product F(RED):
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] siraltus:
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] Er. Aditya:
thanks samsung for making it more idiotic then it was
[Galaxy Note 3 Developer Discussion [Developers Onl] Product F(RED):
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] siraltus:
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.
[Galaxy Note 3 Developer Discussion [Developers Onl] 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.
[Galaxy Note 3 Developer Discussion [Developers Onl] Product F(RED):
For anyone interested in what CC mode is and how it changes the device behavior, you might find this interesting: https://www.niap-ccevs.org/st/index...ffa34fe6c-2FF928A8-FE41-7367-5EF4130BA9B6BE9D
[Galaxy Note 3 Developer Discussion [Developers Onl] tropazr:
I think you all will be interested in this report by [MENTION=4229979]djrbliss[/MENTION] which was presented at Black Hat USA 2014 last week. The vulnerability supposedly exists to unlock the Note 3 bootloader. Hopefully, Dan will share the magic (if he hasn't already) with someone who can help the Note 3 community finally get this beast unleashed.

http://i.imgur.com/TXKDpOI.png

Mods: Please delete if this is a repost. I couldn't find mention of this anywhere.
[Galaxy Note 3 Developer Discussion [Developers Onl] sokrboot:
Here's a direct quote from Dan Rosenberg's twitter "LG and Samsung devices cannot be bootloader unlocked via TrustZone, so please stop asking me about it."
[Galaxy Note 3 Developer Discussion [Developers Onl] akp.ajinkya:
Recently bought note 3 with update to ENG1 firmware.Thought of rooting my device and of course knox tripped to 1.Then tried to reset knox using the bootloader and method given in RuchRha's post (post #76 in this thread) and followed every steps given by him.

Apparently the knox did reset but the thing is the download mode still shows the screen given below.

Can anyone help regarding this?

[MENTION=5374564]RuchRha[/MENTION] I know this is for developers only but kindly guide me before deleting this post.
[Galaxy Note 3 Developer Discussion [Developers Onl] msasm09:
You need to flash full 4 files rom after reset knox i think
[Galaxy Note 3 Developer Discussion [Developers Onl] Kaibil:
Just need to flash ROM with Odin from sammobile firmwares, then wipe all data
[Galaxy Note 3 Developer Discussion [Developers Onl] akp.ajinkya:
The package I used was a single one .tar.md5 but I am not sure if it contains bootloader file too....can anyone confirm this?

EDIT:Acc. to phone info app,the bootloader is HA3GZS_TEST,so I think the UENG1 package doesn't contain the bootloader file.It may be the culprit.Can anybody give me the bootloader file which is compatible with the UENG1 build?

Did it bro...I used the UENG1 firmware file downloaded from sammobile,even the one used in post #76 i.e ND1 but to no avail.
[Galaxy Note 3 Developer Discussion [Developers Onl] Ram121:
[MENTION=5374564]RuchRha[/MENTION] can you please provide md5 check sum of bootloader file or can you provide tar.md5 bootloader file as it is important that no one should flash a corrupted or incomplete file by chance

Another thing is, if possible, can you please create a thread in general section about knox reset of N900, as people will be able to clear their questions in that thread
[Galaxy Note 3 Developer Discussion [Developers Onl] kizzle4:
So in regards to this.. looks promising. But i wish i even knew where to start. Can we finagle this to work for us somehow?
[Galaxy Note 3 Developer Discussion [Developers Onl] watson540:
if you would bother to read 6 posts up, you would see your answer. that answer is a no :/
[Galaxy Note 3 Developer Discussion [Developers Onl] shangrila500:
Actually there is a possibility that it would work for the Verizon and AT&T Note 3, especially if you have stayed away from updating. In his original paper he stated that the S5 was the only Samsung device that had the TrustZone exploit patched at the time he wrote published the paper. Since he wrote and published the paper all Samsung devices could have had a patch issued but if you're on an earlier version there is still a chance that the TrustZone exploit is still there to be used by an enterprising developer.

He was very specific on what devices were already patched so if the Note 3 was patched at the time he wrote the paper it would've been listed with the S5.

There is s problem though, it is thought that our eFuse is already blown so there would have to be another workaround for that if the TrustZone exploit works for our devices. I don't know how hard that'd be to get around though and it may be impossible...

The obvious downside is if there were a bootloader exploit published from using this information the exploit would ONLY work on devices that hasn't been updated yet.

There is also the fact that even if the TrustZone exploit has been patched on all Note 3's and there is no way to unlock them with the TrustZone exploit this still offers invaluable information and insights and may lead to the developers researching our devices bootloader unlocking finding another exploit that will work for our devices. This entire situation is a god send.
[Galaxy Note 3 Developer Discussion [Developers Onl] TheLoonyRebel:
I'm curious if they patched the potential exploit on the NC4 boot loader (VZW). Obviously our leaked NC2 build I believe uses the same boot loader as MJE which is why we are able to downgrade to 4.3 if we want to so no issues there on that.
[Galaxy Note 3 Developer Discussion [Developers Onl] watson540:
yeah, i just unofficially upgraded from NB4 JellyBean a few days ago so i could have a few more "rom" choices..I hope I dont regret that but apparently there is a way to regress that change.

Im mostly happy with what we have. But there is always the want for more. A shame to have such a great piece of hardware be crippled in this way. If the BL is ever cracked open it will be far past its prime I think...
[Galaxy Note 3 Developer Discussion [Developers Onl] RuggedHunter:
I'm pretty sure his paper described a vulnerability, not an exploit. That vulnerability is present on all new qualcomm devices except what he specifically mentioned, and any device that's already been patched. He then demonstrated how to exploit this vulnerability on the moto X to unlock its bootloader. This vulnerability cannot be exploited in the same way on Samsung devices to unlock their bootloaders.
[Galaxy Note 3 Developer Discussion [Developers Onl] ryanbg:
So much misinformation here. There is no 'unlock' QFPROM 'fuse'. That's why Dan said it can't be simply unlocked. However, there is no information on Samsung's Odin and how it recognizes Developer devices vs. Production. There are multiple mechanisms and venues of attack via TrustZone aside from a simple unlock fuse. It's 100% possible, but we'd need a dump of QSEE in order to see how and where. This exploit is very difficult to exploit, and requires a significant amount of research.
[Galaxy Note 3 Developer Discussion [Developers Onl] shangrila500:
Thank you for the response.

What I meant about the fuse was the way I understood how the Moto X unlock worked was that it had a fuse that had to be blown in order for it to show bootloader unlocked status and not check kernel signatures. There has been speculation that Samsung also uses these fuses but instead of blowing one to unlock the bootloader like with the Moto X the fuse is blown in Samsung devices to lock the bootloader therefore there could never be an unlock just by simply blowing the fuse. I do not know for sure is Samsung does use blown fuses to tell the software the bootloader is locked and to check the kernel signature against Samsung's official keys, it is just something that a few people have suspected about Samsung devices.

I also did not mean to come across like I thought, or knew, the exploit that Dan used to unlock the Moto X bootloader could be used on Samsung devices. I've understood from the start that using an exploit that relies of hardware wouldn't work on different devices made by different OEMs.

What I am trying to get across is that Dan gave us a vulnerability that we might possibly be able to use to create our own exploit to unlock our own bootloaders on various devices. I know it will be extremely difficult to do but this really seems like the best possibility for our bootloader to be unlocked since the Verizon Note 3 was released. Even if we cannot unlock our bootloaders by exploiting the vulnerability that Dan found this still has great potential.

How would one go about getting a QSEE dump?

As for Odin knowing the difference between developer devices and consumer devices, I wasn't aware that Odin could tell the difference between developer and consumer devices. If it can why would that matter?

What other venues of attack are there to unlock a bootloader by exploiting a TrustZone vulnerability aside from blowing a fuse like with the Moto X? What all is holding us back from creating an exploit to unlock our bootloader using one these multiple venues of attack?

How did Adam Outler and the team he worked with unlock the Verizon Note 2 bootloader? I thought they exploited a TrustZone vulnerability to gain bootloader unlocked status but it has been so long that I really can't remember. Is there anything they did with the Note 2 that could be used on the Note 3?

Sorry for all the questions, I just want a better grasp of the situation and to see if there is anything I can do to help.
[Galaxy Note 3 Developer Discussion [Developers Onl] ryanbg:
The AP_ANTI_ROLLBACK fuse controls the S+T+R+A+P flags in ODIN, and this controls whether a revision is blacklisted or not via a monotonic counter in QFPROM (fuses.) There is a check on address 0xF9269EC whether the value is 0 or not. If the value is not 0, Odin recognizes the device as 'MODE: DEVELOPER". This same check also controls whether the device will boot an unsigned kernel or recovery. A spare fuse is also used for something, but I haven't identified what yet. There's also some goodies on the RPMB on the eMMC chip, which is secured with a symmetrical 32 byte key stored on the SoC and eMMC chip.

There's much more than that. This is a very complex and multi-system operation.
[Galaxy Note 3 Developer Discussion [Developers Onl] ahmekh:
can you please advice me how to fix Knox on N9005.
[Galaxy Note 3 Developer Discussion [Developers Onl] shangrila500:
Is there anything Note 3 owners can do that would help you in any way? I'd be willing to help you in any way I possibly could.