3 ms·
Here's the concern I have, if you're able to "unlock" a single device, how do you do it where it's useful to the researcher, but can't be done to an unsuspectin
by jsjohnst 9y ago
Here's the concern I have, if you're able to "unlock" a single device, how do you do it where it's useful to the researcher, but can't be done to an unsuspecting 3rd party's phone?
The only way I can think of that doesn't have an endless array of problematic edge cases is for Apple to have a "researcher edition" of the phone, but even that isn't problem free.
Thoughts?
- saurik 9y agoApple already solves this problem by way of their TSS update server: they can whitelist specific ECIDs to be able to sign and install developer customized firmwares. What the argument was was "if we sign on to your program, can you add us to your whitelist?". The only issue I can come up with would be "what if a researcher who was registered with and known to Apple gave their phone to someone else as a fake gift to spy on them". If you really want to go there we could argue it, but it seems a little far fetched in terms of "amount of damage that can be done via this route that couldn't be done via other ones".
- jsjohnst 9y ago> The only issue I can come up with would be .... If it's locked to specific hardware, then no, I definitely wouldn't argue the edge case scenario you mentioned.
- willstrafach 9y agoApple has DEV-fused devices which use separate development certificates and keys. The bootloaders and kernels for production devices still retain the code for the "special" functionality, that is how researchers are aware of it, but it simply will not work without an actual dev-fused device.