Hacking a Philips toothbrush head to allow you to use it beyond its normal lifetime. Yes, the toothbrush head is hackable. This is a fantastic tale of reverse engineering. Be sure to read the followup at the bottom of the article.
@verdre published his work about reverse engineering Android app support in Sailfish OS and bringing it to GNOME/Linux mobile. :android: :gnome: :linux: 📱
🦀 🧵 Rust reversing thread: Let's use panic metadata embedded inside Rust binaries to help us reverse engineer!
If you've ever looked inside the strings of a Rust binary, you may have noticed that many of these strings are paths to Rust source files (.rs extension). These are used when printing diagnostic messages when the program panics, such as the following message:
thread 'main' panicked at 'oh no!', srcmain.rs:314:5<br></br>
The above message includes both a source file path srcmain.rs, as well as the exact line and column in the source code where the panic occurred. All of this information is embedded in Rust binaries by default, and is recoverable statically!
Examining these can be useful in separating user from library code, as well as in understanding functionality. This is especially nice because Rust's standard library and the majority of third-party Rust libraries are open-source, so you can use the panic strings to find the relevant location in the source code, and use that to aid in reversing.
When we're doing vuln hunting on internet appliances, we often want a shell in order to figure out what's going on. For the F5 research we were lucky, you could just SSH into the box and immediately get access to relevant config files and binaries. Lots of other appliances don't like to give out that access, they might give some kind of restricted/custom shell, or maybe they just don't expose anything at all.
In order to get around this, we'll often grab VM images and then boot from a live cd / alternate linux install and mount the disks. More recent Sonicwall appliances prevent this behavior, however. Their disk partitions are all LUKS encrypted, which prevents nosey researchers like myself from being able to mount them via another OS that doesn't have the encryption keys.
What's interesting though, is that if you boot from the base image (as intended), it just works. GRUB does have a mechanism for embedding decryption keys into the boot process, but this often means just leaving the decryption key in the boot partition, which is pretty easy to grab. This is not what Sonicwall NSV appliances do.
The TL;DR is that Sonicwall modified their GRUB bootloader to perform decryption key derivation based off of the partition metadata. This is very much NOT default GRUB behavior (as far as I'm aware), so someone at Sonicwall went out of their way to bake this into the bootloader. It was a fun RE experience though, definitely got to learn a lot!
Today's guest is a KAF-0402, a mono CCD sensor made by Kodak. Their sensors were used in a lot of scientific imaging applications before CMOS devices got good enough.
🦀 Small Rust reversing tip: The Rust standard library documentation hides a lot of fields and items by default. For example, the documentation for the struct std::vec::Vec does not show you what a Vec's internal fields are. This can be annoying if you're looking for the implementation details of a certain type - I found that I kept having to click the "source" button on every single struct I wanted to get more information about, to look at the source code directly.
pub struct Vec<T, A = Global> where A: Allocator,<br></br>{<br></br> buf: RawVec<T, A>,<br></br> len: usize,<br></br>}<br></br>
This version of the documentation also documents some items which are hidden from the regular documentation (i.e. items marked as #[doc(hidden)]). One example iscore::panic::panic_info::PanicInfo::internal_constructor, which is an implementation detail of core::panic::panic_info::PanicInfo.
Having the hosted https://stdrs.dev/ site is handy for quickly looking up certain standard library structs, but you can also generate the same information locally with rustdoc, via the --document-private-items and --document-hidden-items flags. The script used to generate the stdrs.dev site is here, and you can tweak the version of the standard library docs you want to generate as required (stdrs.dev has the nightly docs). There are some more details about the site from the author's initial Reddit post about it.
#ReverseEngineering of the #SamsungNX social media uploads right from the camera reveals a huge surprise: camera engineers are bad at encryption and #security 🤦🤷
Any of y'all do any #reverseengineering with #android or general #infosec stuff with it? Read an article about a couple of dev bits and I've got some friends in the field. Sounds fun. Where should someone start with that stuff if they have a dev/sec/etc background already? Books, tools, courses, devices? Not real sure what I want to tinker with but I know I'd like to tinker.