Note that this menu item was not used to install Android apps, which is what people often mean by "sideloading", especially with all the discourse around Google's new developer verification requirements. This menu item was used to manually install an OS update from a .zip file and already required that file to be signed by Samsung on locked devices.
On unlocked devices, you can install your own recovery that still has the option. So the removal doesn't prevent too much in practice. That ship sailed when Samsung stopped allowing bootloader unlocking on most of their phones.
That's still possible so long as you're on a version of OneUI 8 that allows downgrading to OneUI 7. I did that and then patched the OneUI 8 firmware with Magisk and substituted the new bootloader for the old one and it works. Literally did this like in the past 2 days. Didn't even have the time to sound like a conspiracy theorist.
> You don't need to know how a plane/car/elevator works to know that it works when you use it.
I'm sure the 737 MAX seemed to work just fine to Boeing's test pilots. Observing the external behavior of a system is not a substitute for understanding its internal workings and the failure modes they carry.
Is there a reason you wired MOSI and MISO together with a resistor instead of setting the SPI_SIO bit in the ESP32C6's SPI controller? The reference manual[1] says that bit enables "3-line half-duplex communication, where MOSI and MISO signals share the same pin" (page 866). I'm not sure if it's suitable, since the half-duplex mode (see section 28.5.8.4) seems to be designed mainly for talking to SPI flash chips.
Surely Windows keeps the FVEK in RAM regardless of whether the TPM requires a PIN to initially obtain it. Otherwise, wouldn't you need to enter your PIN every time a block from the disk needs decrypting? Not to mention the performance impact of calling the TPM on every disk operation.
This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate it.
The point is that the TPM PIN prevents the attack if the system is powered off when the attacker obtains it.
If the TPM doesn't have a PIN, this attack works even if the attacker obtains the system when it's powered off. They can start the computer, proceed to the Windows logon screen (that they can't get past and that hence prevents them from exfiltrating data from the running system), then just reset the computer and perform this attack to obtain the encryption key. This obviously doesn't work if the PIN prevents Windows from ever even starting.
I know this is besides the point, but still kinda relevant:
Even on Win11 it's still possible to do the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot), from there you can change account passwords at will.
I think Windows repair prompts for an admin login and the bitlocker key before allowing you to proceed. Assuming the windows install is intact enough to read the security sam.
Correct, unless you're using a self-encrypting drive the FVEK sits in RAM once it's been released by the TPM during boot. The TPM is only a root of trust; for fast crypto operations without keeping the key in kernel memory you would need something like Intel SGX or ARM TrustZone.
BitLocker no longer leverages SED by default due to vulnerabilities in drive manufactures firmware as of Sept 2019.
> Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.
If you can short the reset pins while the computer is running and make it restart without losing power, then yes, I agree. But if you have to shut down to make your modifications, then you won't get past the PIN prompt.
Why? It means you'll only get one shot at the attack, but nothing here is intrinsically prevented by using a TPM PIN (or even a non-TPM password, the attack doesn't depend on TPM-based Bitlocker in any way other than if the target machine is powered off or your first attempt fails)
I wouldn't underestimate that a PIN prevents this attack on machines that are powered off.
You can then go further up the chain with a UEFI settings password and no usb booting. If the password is hard to decrypt, then that's a pretty good approach.
Then there's custom Secure Boot certificates that replaces the ones from MS. It'll work for Linux, not sure about BitLocker. But my Surface tablet doesn't even support custom sb certs.
Kaitai Struct[1] is my preferred tool for parsing binary files. It's open-source (unlike Synalize It! and 010 Editor) and cross-platform (unlike HexFiend). Not sure how it compares to ImHex's pattern language, though—I've been put off by ImHex's UI the few times I've tried it.
My favorite thing about the Kaitai Web IDE is that it instantly updates the parsed tree as you make changes to the format specification, which makes it viable for reversing unknown formats instead of just specifying known ones.
Did it update the firmware over Bluetooth? Up until Android 11, Android required fine location permission to perform Bluetooth scans[1] because knowledge of nearby devices can be used to derive location.
`sl absorb` can turn that workflow into a single command in many cases: it automatically looks at what hunks you've changed and tries to propagate them back to earlier commits in the stack that touched those same hunks. It's not perfect, but in my experience using this at Meta, it does what you want 90% of the time.
...at least, for the one Bose device I own. Other Bose Bluetooth devices use the same image format and can be updated by the same official update tool (which doesn't run on Linux or support downgrades, hence this one), so I'm hopeful they use the same protocol as well.
This was a fun reverse engineering project, and I also used it as an opportunity to learn Rust better. The protocol is quite close to USB DFU[1], but it's been altered to run on top of HID reports instead of raw USB transactions, presumably because every major OS lets you talk to HID devices without having to publish and sign your own driver.
Interestingly, Bose seems to have also forked dfu-util[2], which is GPL-licensed, altered it to speak this protocol, and shipped the binary with an official update tool for a different product with no accompanying source to be found. More details on that at the end of the README.
Realtek drivers on Linux, at least for some codecs, have this feature built-in, no malware needed. On my Dell XPS 13 9350, for example, I can use alsamixer or pavucontrol to choose between "Internal Mic," "Headset Mic," and "Headphone Mic."
The "Headphone Mic" setting is designed for connecting a microphone to the single multi-purpose 3.5mm jack, but it can also record audio from a pair of headphones just fine if you turn the gain up.
