[Galaxy S 4 General] z-phoria:
"There is no way to forge an authentic certificate without the right signed security key. As of right now, we don't even know how to access the key's location (evidence suggests it's stored within the encrypted KNOX partition, and if a single unauthorized attempt is made to access the partition then KNOX trips and the partition is destroyed). Even if we could reach the key, it would be virtually impossible to decrypt it. It's a good thought, though."

Well, thats what i thought. Their own white papers are the most silly-built things i've read (or looked at, since there are mostly images).

Anyway. I guess you read D. Rosenbergs blog about his exploit by their badly constructed code where he made the bootloader execute his shellcode in the ramdisk? In case you didn't, here it is; blog.azimuthsecurity.com/2013/05/exploiting-samsung-galaxy-s4-secure-boot.html

-

"People have been able to create dump files. I included one example in the compilation posts a little earlier on this page."

I'd like to see everyones, actually. My google-magic don't seem to work this night thou, 'cause i can't find anything of that.

Are the mbn-files encrypted too, before flash? aboot, sbl1, 2 etc? If not, are they fully reverse-engineered?

-

"I'm not sure if I'm understanding you correctly, but it sounds like you're asking if there is any way to create a 4.3 ROM that isn't built on the most recent bootloader. The answer is "yes," CNexus and several others have recompiled 4.3+ ROMs which exclude the new bootloader as well as KNOX incorporations into the kernel and OS."

Not exactly. I meant, for what i just realized you've made - a loopback-mount.

Is it virtually impossible to dump the software from main bl using the first method (with variation ofc) i referred to?

dangerousprototypes.com/docs/Bus_Pirate <- This. JTAG.

-

"There have been a handful of theories regarding how these reported KNOX resets might be done. The current lead theory is that some very select handful of Samsung authorized techs have access to a handheld device that can be plugged into the phone and used with a security key to reset the KNOX flag notification to 0x0. While all KNOX-enabled devices have eFuses built into them, there is some evidence to suggest that there is some variation in the way the KNOX flag works with older devices vs. newer ones. That evidence suggests that in older devices the KNOX flag does not actually burn the eFuse unless a failed attempt to reset it is made, but in newer devices the eFuse is burnt as soon as KNOX is tripped. This is speculation though, and it's equally possible that the eFuse burns immediately in all devices. If the latter is true, and there is truth to the rumors of shops resetting KNOX without replacing the mainboard, then that indicates the reset is achieved by reprogramming KNOX to utilize a different eFuse."

If any of this is possible the problem would be to retrieve the exact method?

-

Hm. This is not what im after, you see. Trip or no trip, doesn't matter. For me, the best scenario would be (except total abscence of knox) to have the main bl believe the secondary is intact/original/unhacked while its any bootloader of choice and leave the rest of the bs just booting kernel at once...kind of :)

And yes, i know that many people spent many hours with this, and no, this is no mockery to them,

but in my world (at least digital) anything is possible, and nothing is bulletproof.

And here goes probably the timeframe question, so i'll just end with a small req: Anybody might be so kind u/l:ing the bootloader-files in a rar/zip to any filehosting-site (like anonfiles.com) and give the link for it?

Regards.

z