5 ms·

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 id

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? Still, this is a really cool hack.

swinglock 6y ago
Debuggers.
- mbreese 6y ago
  There we go... that was the obvious use case I was forgetting!
- deleted 6y ago
  [deleted]
xxs 6y ago
I'd not call it common. 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.
simias 6y ago
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.
jerf 6y ago
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.
PeterisP 6y ago
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/ https://github.com/ufrisk/pcileech/), here's a video demo of writing to Notepad's memory remotely https://youtu.be/5DbQr3Zo-XY?t=1440 https://youtu.be/5DbQr3Zo-XY?t=1440
- _Microft 6y ago
  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.
  - colejohnson66 6y ago
    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?
    - velosol 6y ago
      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.
- saagarjha 6y ago
  Some operating systems do not allow you to do this even if you are root.
pjc50 6y ago
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. I tried searching for detailed explanations and came across this absolute horror: https://supportline.microfocus.com/documentation/books/nx30books/opolea.htm https://supportline.microfocus.com/documentation/books/nx30b... (how to use ActiveX from Object COBOL)
- epse 6y ago
  Oh yeah I remember <pretty big accounting app> which used OLE hacks to use word, excel and access as a backend
- milesvp 6y ago
  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 :(
  - saagarjha 6y ago
    Screen readers should not require reading (or modifying!!) a process's memory; platform UI toolkits make this information available programmatically.
    - TeMPOraL 6y ago
      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. -- [0] - https://news.ycombinator.com/item?id=23251509 https://news.ycombinator.com/item?id=23251509
rnotaro 6y ago
CheatEngine needs Root / UAC admin. 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.
rightbyte 6y ago
I have used it for testing running release programs.
deleted 6y ago
[deleted]

swinglock 6y ago

Debuggers.

mbreese 6y ago
There we go... that was the obvious use case I was forgetting!
deleted 6y ago
[deleted]

xxs 6y ago

I'd not call it common. 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.

simias 6y ago

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.

jerf 6y ago

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.

PeterisP 6y ago

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/ https://github.com/ufrisk/pcileech/), here's a video demo of writing to Notepad's memory remotely https://youtu.be/5DbQr3Zo-XY?t=1440 https://youtu.be/5DbQr3Zo-XY?t=1440

_Microft 6y ago
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.
- colejohnson66 6y ago
  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?
  - velosol 6y ago
    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.
saagarjha 6y ago
Some operating systems do not allow you to do this even if you are root.

pjc50 6y ago

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. I tried searching for detailed explanations and came across this absolute horror: https://supportline.microfocus.com/documentation/books/nx30books/opolea.htm https://supportline.microfocus.com/documentation/books/nx30b... (how to use ActiveX from Object COBOL)

epse 6y ago
Oh yeah I remember <pretty big accounting app> which used OLE hacks to use word, excel and access as a backend
milesvp 6y ago
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 :(
- saagarjha 6y ago
  Screen readers should not require reading (or modifying!!) a process's memory; platform UI toolkits make this information available programmatically.
  - TeMPOraL 6y ago
    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. -- [0] - https://news.ycombinator.com/item?id=23251509 https://news.ycombinator.com/item?id=23251509

rnotaro 6y ago

CheatEngine needs Root / UAC admin. 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.

rightbyte 6y ago

I have used it for testing running release programs.

deleted 6y ago

[deleted]