Ray tracing in notepad.exe at 30 FPS
kylehalladay.com
kylehalladay.com
It would read a pixel value from a file, then "click" in the FaceBook app's color textfield, send 7 delete messages to remove the #000000 color, type in the new color value, then "click" at an X/Y position. It did it 10 times a second.
It worked great until I accidentally focused another app while it was running: and the 70 delete-messages-per-second got sent to Microsoft Outlook.
It took me a while to figure out what was going on as screenfuls of emails evaporated before my eyes.
;-)
I have:
F9::
Reload
Return
Another is that platforms have been locking down on cross-application access for quite a while, for security reasons. Reading or writing a process's memory is a big no-no these days, since it effectively lets you inherit the privileges of that application, and some operating systems will prevent you from doing it altogether no matter how much privileges you have. The latter operating systems have also begin to lock down the APIs that give programmatic control as well, which is somewhat sad…
Finally, when doing things like this try to see if you can find the "highest level" to do such hackery at. Ideally, the app has functionality built-in to do what you want, and if that doesn't work see if the accessibility APIs can help. Then see if you can find functions in the binary to call, and then as a last resort you can touch data structures in memory. This is because using higher-level APIs is more likely to keep things working: you might be changing the string in memory, but some code at a "higher level" might not expect that and misbehave. Perhaps it cached the string's length or thinks it has exclusive access to that memory so it overwrites your modifications. Have fun with your hacks, but be careful!
You can't stop the user (or other application pretending to be him) from accessing the content of something while allowing him to access the content of something, and you can't stop the user (or other application pretending to be him) from interacting with your software while being interactive for him.
* actual mouse is plugged into the pi, pi is plugged in the computer in usb and pretend to be a mouse, video output is piped into the pi, software magic running on the pi "fix" the mouse movement to make perfect aim when need be through image analysis https://www.youtube.com/watch?v=d1jz8qbzfIk
I had a lot of fun as a kid fucking with Windows in Spy++. Oh your shareware program disabled the "Continue" button?? Let me just go in there and reenable it. It was like the DOM inspector but for Windows itself.
Later I got to use these skills to port a Firefox addon to Internet Explorer. It was a contraption, and it worked. Ironically that project died because I couldn't get the installer to work right
Basically the permissions are enforced at OpenProcess(), and these are the permissions you can ask for: https://docs.microsoft.com/en-us/windows/win32/procthread/pr...
Sure letting it be a free-for-all was a bad idea. I'm fine with granular permissions, but am wary because it means I'm relying on features that upstream could turn off because they felt like it, or it made them look bad, or it introduces a security hole they just don't want to fix.
It's giving away liberty for security.
Fun fact. The C++ hooking library I found, Detours, which at the time was the most common (only?) library for hooking windows API calls. It was written by microsoft research for accessibility reasons. There are 2 windows API functions (maybe more) that will render text to the screen basically as a bmp making it impossible to gain access to the text being written. Not sure if this was an oversight by the MS windows group, or it was intentional to allow for developers to obfuscate text output in various ways. Thing is, this breaks screen readers. So microsoft got to create a library that unbreaks their API, which I personally found very amusing at the time.
Also you should know, that the library makes it obvious it's being used if the client has enough privileges. I don't remember the details because I never needed to care. But it's some combination of adding a process in task manager, and making an obvious fingerprint in memory. I think this was to appease complaints of use by more nefarious purposes than screen readers. My understanding is that companies like Blizzard know how to find you're using detours, if you don't go out of your way to modify the library before compiling it.
Sometimes you can work with the x and y coordinates if you resize each screen each time.
Sometimes that can be very fast because you can click on the controls before they’re even drawn on your screen.
I went looking for something similar that was interactive and found ASCIICKER. It's everything I wanted and more.
I remember seeing Chromium Embedded Framework had a caca backend (circa 2015) so you could use the chromium renderer in a text terminal.
There are a whole bunch linked on the main page: https://asciicker.com/
I suspect that some younger developers simply started tinkering with CheatEngine before they learned proper programming so they feel very comfortable using it instead of a regular debugger. I started programming by tinkering with BASIC game listings so I feel a certain kinship with this approach.
Also CheatEngine is probably easier to set up and will work regardless of whether you have access to the source or not. And unlike more advanced tools like IDA you don't have to worry about expensive license or pirating since it's free and open source.
That being said if you're reporting bugs on open source projects on GH please try to use more appropriate debugging tools, I don't know what to do when somebody starts posting dumps of the Windows VM address space to show me how something isn't working as it should...
WinDbg, and DOS's DEBUG that came before it, feel far more natural with such (and the former can also debug at source-level.)
[1] "No function contains specified address." -- when there is absolutely no requirement for anything to resemble a function in order to be capable of being disassembled.
How about injecting your code into that process? (Either from your own DLL via LoadLibrary and SetWindowsHookEx; or WriteProcessMemory directly into it then CreateRemoteThread) [1]
I love that Windows lets you do this kind of stuff. Security nightmare, sure, but it allows use cases the creators couldn't envision (e.g. I believe UltraMon uses it to add and override window functionality). The first time I injected a hook into another app from Visual Basic it felt like I had a new superpower.
I was going to add some code to force notepad to use the fonts I wanted (Consolas, 11pt), but for some reason sending WM_SETFONT messages kept messing up how fonts were displaying
For this one you could automate the menu dialogs to display the current font. SendKeys should do the trick, then read the control values with the same methodology already used in your project.
[1] https://www.codeproject.com/Articles/4610/Three-Ways-to-Inje...
(defun sh-line ()
(interactive)
(let ((cmd (buffer-substring-no-properties (line-beginning-position) (line-end-position))))
(end-of-line)
(newline)
(insert (shell-command-to-string cmd))))
(local-set-key (kbd "M-RET") 'sh-line)
The solution I came up with is a bit lower-level, looks like this:
(make-process :name "some_name"
:buffer "buffer"
:command ("cmd" "to" "run")
:connection-type 'pipe
:coding 'utf-8-dos)
Now, if anyone figured out how to configure a connection to a language server across the WSL boundary, I'm all ears.
It infuriated long time players whose score I beat in just a few days. It was fun :)
Still have the source code here - https://github.com/shadabahmed/quizroom_hacker
One very useful, was an extension that allowed you to “save” a file even after you‘ve hit “don’t save”
Still, this is a really cool hack.
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.
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.
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.
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
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/nx30b... (how to use ActiveX from Object COBOL)
--
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.
https://www.gnu.org/philosophy/right-to-read.en.html
In 2047, Frank was in prison, not for pirate reading, but for possessing a debugger.
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.
There is no denying how cool the end result is but input to any Windows thingie can be scripted with AutoIt in a nice easy way with a very expressive, BASIC style language that has existed for decades. You can get it to churn out a self contained .exe.
I don't know why Windows sysadmins piss around with anything less for most tasks on an OS that needs a GUI. You can always call into or out of PS/cmd or whatever as needed.
I'm guessing this is how a lot of the game shark cheats were discovered back in the day.