Regarding E4 with updated firmware:
The new "protection" is based on the fact that the per-device config files (FlashFS\system\appcore.d\config.d\conf.cfc, FlashFS\system\ui.d\config.d\conf.cfc, FlashFS\system\services.d\config.d\conf.cfc) are now encrypted and signed.
The encryption algorithm is RC4 with the key being the SHA1(key || "2A00"), where "key" comes from the "FAD1:" device, ioctl 0x800040C0. That ioctl, which I don't fully understand what it's actually doing, returns 0x18 bytes, with the last 8 bytes being the key (not sure if it's per-device or generic), and the second word indicating whether the config-files have to be globally signed or just including a hash. On my camera (1.2L, came with 2.3.0) it indicated that they have to be signed. common_dll.dll checks for the config file signature, and uses a RSA1024 bit public key to verify the signature.
So far, that's all bad news.
You can patch your config-file, and patch common_dll.dll to disable the signature check (and because I couldn't get CRC03 to compute correctly, I patched that as well), but then the camera doesn't auto-boot anymore since applauncher.exe verifies the CRCs from applaunch.dat (which fails for my patched common_dll.dll), and applaunch.dat itself is signed (applaunch.sig).
BUT: It appears that CRMD160 is very fundamentally broken for byte values >= 0x80 (talk about not compiling with /J, hehheh). This allows to conveniently patch the signature check in a way that applauncher.exe doesn't notice. (Unfortunately the config signature check uses MS Crypto Provider, not their custom stuff.)
I was able to apply this hack on my E4 but it's a very dirty hack. I haven't fully understand the config loading yet, maybe there's a better way, like manipulating on of the existing files instead to override the per-device config? Has someone played with that yet? (like: remove the per-device config, and then hack one of the .rsc to set the stuff that's otherwise set in the .cfc).