How common is it to be able to read/write another program’s memory space? It’s not something I’ve ever done before, but it doesn’t seem like it’s a very good idea from a security standpoint. Are there other use cases that I’m missing?
This is a great example of how security has changed from the applications being installed by the system administrator being "trusted" and access control focused on users, to the main threat being malicious applications all nominally under the control of the user but with unwanted behaviour.
Directly going into another process's memory is a bit antisocial and unreliable, so it's normally only seen in debuggers and cheat engines. Some systems use shared memory deliberately to communicate, but that's setup specially (MAP_SHARED etc).
What's far more common is shared code "injection": Windows shell extensions, for example. Keyboards and input method helpers. Or OS hook mechanisms: Autohotkey. COM/OLE. And if you want to be baffled and terrified, "OLE Automation" which lets you RPC into Microsoft Word.
Just wanted to point out screen readers and other disability tools are a very important reason to read and modify another application memory. My understanding is this was a primary motivator for the detours library. Though I can't seem to find the MS Research blog post talking about this nearly 20 years ago, I'm wondering if there's some revisionist history that's happened :(
Except when they don't, or don't give enough context. A top-level comment here[0] gives an example where text was internally rendered to a bitmap prior to display, so a MS library was needed to hook the relevant API calls to get at the source text. Unfortunately (in this exceptional case), native UI toolkits aren't always as nice as webpage DOM. We'll probably start experiencing the same issue on the Web as soon as WebAssembly gets popular enough for people to develop UI toolkits on top of it.
> screen readers and other disability tools are a very important reason to read and modify another application memory.
That has historically been true on Windows, and to the extent that people still need to use legacy applications that use GDI (the Win32 graphics API), it sometimes helps to use a screen reader that uses such hacks. But for applications using any modern graphics stack, we must rely on programmatic accessibility APIs like UI Automation.
I have some expertise in this area. I started developing a Windows screen reader in late 2004 (for a tiny company, long before I joined the Windows accessibility team at Microsoft). Naturally I started with the proper programmatic accessibility API at the time, Microsoft Active Accessibility (MSAA). I quickly encountered MSAA's severe limitations and had to turn to other techniques, such as sending window messages to Win32 edit controls to get the text under the cursor or the current selection. Internet Explorer and the Office apps had COM-based object models, so I used those as well.
About a month into developing my screen reader, I realized I was going to need something more. I kept running into pieces of UI that I couldn't access through MSAA, window messages, or an object model. I came across a technique called API hooking, that is, patching user-space Windows API functions in memory at runtime, and I realized that I could do this with GDI functions. I knew that other Windows screen readers -- all of the serious ones -- hooked into GDI, but they did it in kernel space, by installing a fake graphics driver that would receive all the function calls from the GDI subsystem in the kernel, pass the information to the screen reader, then forward the calls to the real graphics driver. I figured that with API hooking, I could do something like that in user space. Note that I didn't do the low-level patching (i.e. rewriting x86 instructions) myself; I found a cheap commercial library that did that part. But I wrote the code to apply the technique to the specialized domain of screen reading.
I should mention that I was late to the screen reader game. The real pioneers started releasing Windows screen readers in the early 90s. And one of those pioneers came up with a term for what we were doing, which became common across the industry. They called it an off-screen model. It basically worked like this: a screen reader would hook GDI functions like TextOut, FillRect, BitBlt, etc., and use the information gathered from those function calls, as well as whatever state it could query from the GDI device context, to build a model of what was on the screen. For each piece of text, the model would have information like the text string itself, the bounding rectangle, the color, the width of each character, the font name, the font weight, and probably some other things I've forgotten (I wrote most of that code in 2005 and haven't worked with it in a long time). Whenever a rectangle was filled (e.g. through FillRect or ExtTextOut), we'd note the color, so we could use it for things like detecting whether a given piece of text was highlighted and should be spoken automatically. And we had to keep track of which GDI bitmaps represented graphics, and which ones were text that had been drawn into off-screen memory and then blitted onto the screen. In short, it got really complicated. But it was the only way we could provide access to some important applications.
There were limits to what we could do with this kind of hooking and hacking, though. In early 2006, I heard that TurboTax wasn't accessible with any screen reader. Full of the hubris that comes from having some success at something difficult (edit: and being young), I bought a copy of TurboTax (though I had no intention of using it), installed it, and jumped in to see how I could make it work with the product I had been developing. I quickly discovered why none of the other screen reader developers had been able to make it work. I've long since forgotten the details, but the problem was something like this: Instead of drawing text into a GDI bitmap and then using BitBlt (or one of the similar functions) to blit the bitmap onto the screen, TurboTax would draw into a GDI bitmap, transfer the contents of that bitmap into normal memory, and then somehow blit from that memory onto the screen. Because of this roundabout approach, a screen reader's off-screen model lost track of the bitmap, and by the end, saw it as nothing but an opaque image.
So, off-screen models were fragile even with the fairly simple GDI. I don't think any screen reader developer ever shipped an off-screen model that worked with more complex graphics APIs like DirectX or OpenGL. By the time major non-gaming applications on Windows started replacing GDI, about 10 years ago, it was clear that programmatic accessibility APIs like UI Automation would be the only reliable solution going forward. And now, as a developer on the Windows accessibility team at Microsoft, I work on the Narrator screen reader, which relies exclusively on UI Automation. Sometimes I miss the ability that I had to hack accessibility into an application that wasn't accessible by design; it felt like a superpower. But I know that the days of being able to do that are over, for many good reasons.
If you are root, you can do almost anything on your OS, including reading/writing another program memory space.
I guess a common usecase is when debugging an executable.
Read/write another program’s memory space is commonly used in video games hacks but nowadays they are doing it using drivers to access the Ring 0 (Kernel Mode) and have full control over the OS and bypass user-mode anti-cheats.
In normal operation, very uncommon. Many protections to prevent it from happening in the normal, day-to-day activity.
However, in diagnostics it is extremely common, because it's how debuggers and a ton of other necessary tools work. Debuggers go in even more deeply than that, they can pause execution and single step it, etc. So it's hard to remove the things these tools use to work.
Beyond that, Windows has its own weird concerns here. At the very bottom layer of the way Windows was designed, all windows were in a common space on a single-user system (think Windows 3.0 era here), and all windows can send arbitrary messages to each other, and those messages are often very powerful commands. Not quite literally "set this memory value to that", but things like "set text to this" or "redraw yourself" or "terminate yourself", plus any additional arbitrary things the programs added for their own message loop internally. While Windows has had the basic process model protections of not allowing direct memory access to other process, etc., historically speaking being able to send Windows messages to arbitrary processes has any number of ways of escalating to code execution, even before we get into buffer overflows and such (though there were plenty of those). It has been a long and bumpy road securing Windows against all of these issues to make it multi-user safe. While this particular hack doesn't use windows messages to do all of the work, note that there can still be some legitimate surprise at how much access a program can get to Notepad just by sending messages, like, directly telling it to run its rendering loop to redraw its screen.
Debugers have been already mentioned, but antiviruses do that, as well as various cheat and anti-cheat engines.
From a security perspective, reading/writing another program's memory space is well understood as a specific, risky privilege, so in all modern OSes control and prevent that if it's not "your" process or unless you're root/admin already.
But a cool thing for reading/writing another program's memory space is the ability to do that through PCI without the OS being able to intervene - e.g. Ulf Frisk's PCILeech (https://github.com/ufrisk/pcileech/), here's a video demo of writing to Notepad's memory remotely https://youtu.be/5DbQr3Zo-XY?t=1440
If I remember correctly, not long ago someone posted here about a cheat using DMA to modify the display buffer of a shooter. I'm in a hurry but I'll look it up later.
Well, with DMA, one can do pretty much anything. Doesn’t Thunderbolt (which is PCIe and hence has DMA) have this problem? As in, couldn’t a rouge TB peripheral siphon your data?
Thunderbolt & Firewire before it. DMA to external devices is powerful but the feature also means you expose a bus that wasn't originally conceived to be read by malicious agents.
Well shared memory is a non-adversarial and limited way to effectively read and write the memory of an other process.
It doesn't have any obvious implications security-wise since obviously if a process can read and write an other processe's memory then obviously you have some amount of trust that it's not going to do that. That's why you generally need certain privileges to do that.
The main problem is that messing with a process memory is inherently non-portable and very likely to break if the program changes even slightly. Actually if the system uses address space randomization it may even change between invocations of the program. As such the only programs that usually bother to do that are debuggers and tracers.
Before the advent of MMUs and virtual memory everybody shared the same address space and everybody could write everywhere. Fun times. You still have MMU-less system nowadays but it's generally limited to really low power (or really old) microcontrollers.
Back in the days of old (windows 3.1), I did that to extract dictionary entries - had to control the interface with wm_click too. There was way more encoding than notepad shown in the example, end result was rft. The basic principle is that it was possible to make the process load a DLL.
Still, this is a really cool hack.