tchebb

What you have written here is pretty much exactly the contents of the article we are all commenting on.

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.

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.

[1] https://www.espressif.com/sites/default/files/documentation/...

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.

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.

[1] https://ide.kaitai.io/

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.

[1] https://developer.android.com/guide/topics/connectivity/blue...

`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.

[1] https://www.usb.org/sites/default/files/DFU_1.1.pdf [2] http://dfu-util.sourceforge.net/

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.

I would assume that eclipxe meant that the software shipped with the Nook does not allow for on-the-fly text modification. Even if it did, this is the only occurrence of text substitution that has been seen, so the fault still lies with the publisher.