Anything stopping building malicious ops and redistributing?

[Espionage724]

Lets say I decrypt the ops from a random restore package, modify one of the images and inject something malicious, re-package it, and put it up for download.

Do any of the EDL flashing tools, including MsmDownloadTool do any kind of check on the ops package to determine if it came from a reputable source? As far as I know it can do checks on the file integrity, but you only get the hash after the bad-actor already created the image, and of course is the only one who can provide that particular hash.

It seems like the security in this model lies in the generation of the ops package, which opscrypto.py can seemingly let anyone do. If that's true, is there any protection against this?

[Lanchon]

do any of the EDL flashing tools, including MsmDownloadTool do any kind of check on the ops package

download tools can be hacked. what you really want to know is whether the soc firmware does any checks. the answer? probably not. but don't panic.

the soc itself has some security e-fuses (one-time programmable) in which an OEM burns its own public key during manufacturing. the bootloader rom inside the soc (not programmable) checks that the next loader in the boot chain is signed with a private key (which only the OEM has) that corresponds to the public key in the embedded e-fuses. from there, android is loaded through a chain that maintains secure boot.

so i guess you can flash anything you want to the phone, but it won't boot if you change a single bit of it. from a security standpoint, it is immensely better to check integrity on every boot instead of once during programming. this is why android eventually switched to secure boot, with all the headaches it brought on modders.

so i guess you can flash anything you want to the phone, but it won't boot if you change a single bit of it.

unless... you flash an image of the phone in an OEM-unlocked state, which is probably possible, with a hacked OS. but now the android bootloader must display a warning screen during 5 seconds every time an OEM-unlocked phone is booted that clearly states that the phone cannot be trusted. (it used to be an unlocked pad symbol and no pause before, but only experts would notice a problem with that.) if you see this warning after attempted restore to stock, you'd clearly know that the flashed package has been tampered with.

this warning cannot be bypassed, because it is enforced by a signed bootloader stage that runs in secure boot mode even on unlocked phones.

unless... a exploitable bug is found in the early boot chain to allow booting unsigned code. (this has been known to happen.) so you could build a package that exploits this bug with a hacked OS that won't trigger a bootloader warning. if the manufacturer patched the bootloader, you can simply include an earlier version in the package, given that its signature will still be valid.

well... no, you can't. when an OEM needs to patch a security-related bootloader bug like this, the new bootloader would burn some extra e-fuse. you have many of these, and the original buggy bootloader would check that none of these e-fuses is burnt or else refuse to boot. (given their usage by the boot chain, you could call these e-fuses rollback prevention fuses, but their function is solely determined by the OEM bootloader code and not by the soc.) so if your phone ever got updated to the new bootloader, it can't be rolled-back to the older ever (the soc/processor is physically changed by blowing these fuses), and thus cannot be attacked via an older signed but buggy bootloader.

rest assured that very smart people worked on these issues so you don't have to, and google (but certainly not most OEMs) takes security very seriously.

[ghost]

Lets say I decrypt the ops from a random restore package, modify one of the images and inject something malicious, re-package it, and put it up for download.

Do any of the EDL flashing tools, including MsmDownloadTool do any kind of check on the ops package to determine if it came from a reputable source? As far as I know it can do checks on the file integrity, but you only get the hash after the bad-actor already created the image, and of course is the only one who can provide that particular hash.

It seems like the security in this model lies in the generation of the ops package, which opscrypto.py can seemingly let anyone do. If that's true, is there any protection against this?

Why do you plan on hacking someone? You'd be stupid to even attempt to.

[Espionage724]

Why do you plan on hacking someone? You'd be stupid to even attempt to.

No, I was more concerned about my own device. OnePlus doesn't provide these tools, and yet there's probably half a dozen different Msmdownloadtool packages floating around on XDA and no way to directly verify how legitimate they are.

To "factory" restore my device, I have to rely on these packages, and I wanted to know what was stopping anyone from making one of these packages, implementing whatever in them, and then redistributing them. Change a few dates in the zip archive, and it looks older. Replace one of the static URLs for an old Msmdownloadtools package, and it looks innocent enough.

I'd like to assume nobody is bothering with such a concept for an outdated device nowadays, but I was wondering what would stop someone from doing that? People are flashing all sorts of one-shot random SafetyNet passing stuff just to get banking apps on non-mainstream ROMs, so nobody is suspecting or even checking a Msmdownloadtools package to be malicious.

[Lanchon]

but I was wondering what would stop someone from doing that?

did you read my post above?

regardless, there are known caveats for some oneplus devices. which one are you interested in in particular?

[Espionage724]

but I was wondering what would stop someone from doing that?

did you read my post above?

regardless, there are known caveats for some oneplus devices. which one are you interested in in particular?

Thanks, I did! I'm interested particularly in the OnePlus 6 (not T)

[bkerler]

Closing this, as it is NO issue. All firmware files are still rsa signed, so there is no way to bypass that without having the firmware signature. Only the partitions that aren't signed (and those are r/w anyways) can be changed. Unless of course you unlock the device, but hey, then it's your choice what you install and also your responsibility.

[Lanchon]

@bkerler hi,

what do you mean by the firmwares being RSA signed? could you expand a bit or point me in the right direction?

is the whole firmware file signed? or some partitions within it? are you referring to android's signed kernels and dm-verity or is there something esle?

if there is, who checks the signature? if the upload exe checks it, that is trivial to bypass. i doubt the EDL rom check signatures... does it?

if you are refering to android's regular stuff, nothing stops you from composing an image of a phone with an unlocked bootloader and a custom kernel. (or am i mistaken?) so the original question is relevant. and i know for a fact that some oneplus phones (at least 8/8pro/9/9pro) can be flashed to be unlocked and NOT show any warnings at boot, which complicates maters.

(you can still catch it: boot fastboot and state will show as unlocked; but you have to be proactive.)

[Lanchon]

Thanks, I did! I'm interested particularly in the OnePlus 6 (not T)

OP6 is NOT affected by the abovementioned bug/feature, so you would immediately note the phone is unlocked and customized after a supposed return to stock.