The N3 takes full advantage of ARM Trustzone technology in the Snapdragon 800 SoC. This involves a microkernel running on a separate ARM core from processor ROM space and SoC private memory to do things like key storage and crypto computations, as well as chain-of-trust bootstrapping where each image loaded in the boot sequence is cryptographically verified before loading.
There is a portion of the eMMC flash memory chip (rpmb - Replay Protected Memory Block) which can only be accessed via a hardware protocol that re-keys every read-write transaction. So, even if you could sniff the eMMC (hardware) bus, you might be able to passively read data, but the key used to generate the transaction nonce is never exposed... meaning you won't gain control of it.
In addition, as of the MJ7 release, part of this boot sequence (aboot - the part which interacts with Odin) stores & uses anti-rollback protection information which disallows even valid *prior* Samsung firmware from being re-flashed onto the device. This is to prevent vulns discovered in prior releases from becoming a gateway to device customization.
Sounds complicated, right? Well, that's only the start of it. In addition there are "trustzone applets" that are running during the normal boot that continuously perform a variety of attribution measurements that detect tampering of kernel memory, changes to certain partition signatures, etc. It is sort of unknown at this point whether or nor these live "tripwires" also blow irreversible tamper fuses on the SoC or merely write tamper detection into the rpmb via the TZ api. In either case though, the possibility exists that "harmless" activity such as a kernel exploit that writes into volatile private kernel memory could result in semi-permanent disabling of the device.
In any event, there isn't a playbook for exploit discovery, other than this: understand approximately how a given subsystem works, and look for/test against implementation errors. If one is found, the dev needs to create and test hypotheses that might allow a minor exploit to be leveraged up into increasing privilege or control.
I'm not optimistic that a "class break" exploit of the hardware trustzone technology will occur; but the normal OS requires services from the trustzone, so perhaps there are implementation errors that exist that are close to the exposed APIs.
Probably there are private methods known to Samsung ARCs (Authorized Repair Centers) for reprogramming/resetting devices. These are probably low-hanging fruit in the sense that (a) if known they would enervate devs to experiment, knowing they have a rescue method, and (b) are the type of thing which could be exposed through social methods, and (c) are close in function to the goal of loading altered images onto the phone.
This phone has a *ton* of security stuff going on compared to phones that are only one year old. Given Samsung's dominance in the Android "premier device" segment, if I were CyanogenMod's new investors, I would be worried about what this portends for the future for aftermarket ROMs which require a custom kernel.
Maybe the right approach is to beat Samsung up over their horrid track record for making developer devices available - or maybe it is time to start rewarding OEMs who are happy to allow opt-out of device lockdown through market mechanisms. Samsung boycott, anyone?
Personally, I find it objectionable that my phone needs to be locked down and bristling with security armament on the off-chance that it might someday become a corporate BYOD device. That puts the interests of a low-probability straw-man ahead of the actual device owner... namely, me.
"I'm gonna start coding placebo apps. That way I will be sure that the complaints are real and the praises hollow."