| ▲ | onli 2 hours ago | |
I still haven't seen what you describe, the behaviour of other projects. And I dont believe it without proof (since it was claimed so often by GOS without proof being shown, or in some cases with it obviously not existing). For the security thing: It is wrong to claim that an unlocked bootloader completely breaks the android security model. If anything, it breaks one specific aspect, one that doesn't matter for many attacker models. Besides, on some phones the bootloader just can't be relocked, that's on the phone vendor though. Signing keys for bootloaders might just not matter if change detection was working or the bootloader was not relockable, but maybe I'm missing some specifics there. So imho what you describe as catastrophic scenario likely wasn't one. | ||
| ▲ | palata an hour ago | parent [-] | |
> It is wrong to claim that an unlocked bootloader completely breaks the android security model. You seem knowledgeable about this, so I'll take the opportunity to ask: if I install a malicious app and it manages to escape the sandbox and alter the system, my understanding is that it will be detected next time I boot it (because the image hash won't match). Isn't that true? > Signing keys for bootloaders might just not matter Again a question, I haven't found it in the official documentation: aren't those keys the "system keys"? As in, if my system is signed with some keys and an app is signed with those same keys, doesn't it allow this app to get privileged permissions? | ||