This Week In Security: Landfall, Imunify AV, And Sudo Rust

Let’s talk about LANDFALL. That was an Android spyware campaign specifically targeted at Samsung devices. The discovery story is interesting, and possibly an important clue to understanding this particular bit of commercial malware. Earlier this year Apple’s iOS was patched for a flaw in the handling of DNG (Digital NeGative) images, and WhatsApp issued an advisory with a second iOS vulnerability, that together may have been used in attacks in the wild.

Researchers at Unit 42 went looking for real-world examples of this iOS threat campaign, and instead found DNG images that exploited a similar-yet-distinct vulnerability in a Samsung image handling library. These images had a zip file appended to the end of these malicious DNG files. The attack seems to be launched via WhatsApp messaging, just like the iOS attack. That .zip contains a pair of .so shared object files, that are loaded to manipulate the system’s SELinux protections and install the long term spyware payload.

The earliest known sample of this spyware dates to July of 2024, and Samsung patched the DNG handling vulnerability in April 2025. Apple patched the similar DNG problem in August of 2025. The timing and similarities do suggest that these two spyware campaigns may have been related. Unit 42 has a brief accounting of the known threat actors that could have been behind LANDFALL, and concludes that there just isn’t enough solid evidence to make a determination.

Not as Bad as it Looks

Watchtowr is back with a couple more of their unique vulnerability write-ups. The first is a real tease, as they found a way to leak a healthy chunk of memory from Citrix NetScaler machines. The catch is that the memory leak is a part of an error message, complaining that user authentication is disabled. This configuration is already not appropriate for deployment, and the memory leak wasn’t assigned a CVE.

There was a second issue in the NetScaler system, an open redirect in the login system. This is where an attacker can craft a malicious link that points to a trusted NetScaler machine, and if a user follows the link, the NetScaler will redirect the user to a location specified in the malicious link. It’s not a high severity vulnerability, but still got a CVE and a fix. Continue reading “This Week In Security: Landfall, Imunify AV, And Sudo Rust” →

Rust Drives A Linux USB Device

In theory, writing a Linux device driver shouldn’t be that hard, but it is harder than it looks. However, using libusb, you can easily deal with USB devices from user space, which, for many purposes, is fine.  [Crescentrose] didn’t know anything about writing user-space USB drivers until they wrote one and documented it for us. Oh, the code is in Rust, for which there aren’t as many examples.

The device in question was a USB hub with some extra lights and gadgets. So the real issue, it seems to us, wasn’t the code, but figuring out the protocol and the USB stack. The post covers that, too, explaining configurations, interfaces, and endpoints.

There are other ancillary topics, too, like setting up udev. This lets you load things when a USB device (or something else) plugs in.

Continue reading “Rust Drives A Linux USB Device” →

If Your Kernel Development Is A Little Rusty

To paraphrase an old joke: How do you know if someone is a Rust developer? Don’t worry, they’ll tell you. There is a move to put Rust everywhere, even in the Linux kernel. Not going fast enough for you? Then check out Asterinas — an effort to create a Linux-compatible kernel totally in Rust.

The goal is to improve memory safety and, to that end, the project describes what they call a “framekernel.” Historically kernels have been either monolithic, all in one piece, or employ a microkernel architecture where only bits and pieces load.

A framekernel is similar to a microkernel, but some services are not allowed to use “unsafe” Rust. This minimizes the amount of code that — in theory — could crash memory safety. If you want to know more, there is impressive documentation. You can find the code on GitHub.

Will it work? It is certainly possible. Is it worth it? Time will tell. Our experience is that no matter how many safeguards you put on code, there’s no cure-all that prevents bad programming. Of course, to take the contrary argument, seat belts don’t stop all traffic fatalities, but you could just choose not to have accidents. So we do have seat belts. If Rust can prevent some mistakes or malicious intent, maybe it’s worth it even if it isn’t perfect.

Want to understand Rust? Got ten minutes?

The rust language logo being branded onto a microcontroller housing

Esp-hal, A Stable-API ESP32 HAL Gift For Your Rust Code

Looking to write Rust on the ESP32? You’re in luck, a new challenger has entered the scene, looking to help you write code that lasts – [Scott Mabin] and the team from Espressif have brought us the esp-hal 1.0.0-beta. From a personal project to an Espressif-sponsored one to an effort under Espressif’s wing, [Scott] tells us about the arduous journey of bringing first-class Rust support to ESP32 chips, Xtensa and RISC-V alike.

In particular, esp-hal, with the hal part standing for Hardware Abstraction Layer, focuses on providing you with a stable API to access hardware, making sure your code can remain stable for years to come. For now, you get drivers for GPIO, UART, SPI and I2C, as well as a number of auxiliary features like time and SoC reset, more than enough for a large amount of projects we hackers build with a generic MCU in mind.

Next stop? WiFi and BLE support, of course, an ESP32 just doesn’t feel the same without these two. Rust is a fun and seriously promising language, and it’s a joy to use! So, if you have a wireless-less project in mind and you’re looking for a HAL, try out the esp-hal, it might just be exactly what you need.

If you’re looking for examples, here’s an STM32 touchpad project with Rust firmware, a PIC32 Rust blinky demo, and we’ve even featured larger projects like this ESP32 open-source (reverse-engineered) WiFi MAC stack being written in Rust. In case you missed it, we’ve introduced Rust to you a couple of times, even as far as 2015!

UScope: A New Linux Debugger And Not A GDB Shell, Apparently

[Jim Colabro] is a little underwhelmed with the experience of low-level debugging of Linux applications using traditional debuggers such as GDB and LLDB. These programs have been around for a long time, developing alongside Linux and other UNIX-like OSs, and are still solidly in the CLI domain.  Fed up with the lack of data structure support and these tools’ staleness and user experience, [Jim] has created UScope, a new debugger written from scratch with no code from the existing projects.

GBD, in particular, has quite a steep learning curve once you dig into its more advanced features. Many people side-step this learning curve by running GDB within Visual Studio or some other modern IDE, but it is still the same old debugger core at the end of the day. [Jim] gripes that existing debuggers don’t support modern data structures commonly used and have poor customizability. It would be nice, for example, to write a little code, and have the debugger render a data structure graphically to aid visualisation of a problem being investigated. We know that GDB at least can be customised with Python to create application-specific pretty printers, but perhaps [Jim] has bigger plans?

Continue reading “UScope: A New Linux Debugger And Not A GDB Shell, Apparently” →

Bringing OpenStreetMap Data Into Minecraft

Over the years, dedicated gamers have created incredible recreations of real (and not so real) locations and structures within the confines of Minecraft. Thanks to their efforts, you can explore everything from New York city to Middle Earth and the U.S.S. Enterprise in 1:1: scale.

But what if you wanted to recreate your own town, and didn’t have the hundreds of hours of spare time necessary to do it by hand? Enter Arnis, an open source project from [Louis Erbkamm] that can pull in geographic data from OpenStreetMap and turn it into a highly detailed Minecraft map with just a few keystrokes.

The tool, written in Rust, can be either run via an interactive graphical interface or on the command line. In either case, you provide Arnis with the latitude and longitude for a bounding box around whatever you want to import into the game. [Louis] warns that the resulting process is fairly computationally heavy, so you should start be experimenting with small areas.

Once generated, the map can be loaded into the Java Edition of Minecraft. This refers to the original build of the game that predates the Microsoft buyout. Once Redmond took over they spearheaded a new version of the game written in C++ which was then ported over to mobile operating systems and game consoles. Long story short, if you want to wander around a Minecraft version of your home town, you’ll have to do it on your desktop computer instead of your Nintendo Switch.

While the tool is usable in its current state, [Louis] has a fairly long list of features that either still need to be implemented or could use some improvements. From the number of pull requests that have been merged in, it looks like any assistance the community can provide to make Arnis as capable as possible is welcome, so feel free to lend a hand if you’ve got that geospatial fever.

We’ve seen several examples of hackers bringing objects from Minecraft into the physical world, so it’s refreshing to see a bit of our reality sneaking into the game’s blocky universe.

38C3: Towards An Open WiFi MAC Stack On ESP32

At the 38th Chaos Communications Congress, [Frostie314159] and [Jasper Devreker] gave us a nice update on their project to write an open-source WiFi stack for the ESP32. If you’re interested in the ESP32 or WiFi in general, they’ve also got a nice deep dive into how that all works.

On the ESP32, there’s a radio, demodulator, and a media access controller (MAC) that takes care of the lowest-level, timing-critical bits of the WiFi protocol. The firmware that drives the MAC hardware is a licensed blob, and while the API or this blob is well documented — that’s how we all write software that uses WiFi after all — it’s limited in what it lets us do. If the MAC driver firmware were more flexible, we could do a lot more with the WiFi, from AirDrop clones to custom mesh modes.

The talk starts with [Jasper] detailing how he reverse engineered a lot of Espressif’s MAC firmware. It involved Ghidra, a Faraday cage, and a lucky find of the function names in the blob. [Frostie] then got to work writing the MAC driver that he calls Ferris-on-Air. Right now, it’s limited to normal old station mode, but it’s definite proof that this line of work can bear fruit.

This is clearly work in progress — they’ve only been at this for about a year now — but we’ll be keeping our eyes on it. The promise of the ESP32, and its related family of chips, being useful as a more general purpose WiFi hacking tool is huge.