Quick Memory Editor
Kathleen Denson
It shouldn't be hard right? I tried /proc/5052/mem (as 5052 is the process id) - can't read s*it (nor write obviously). ATM I have 010editor (6.0.2) but it seems not to be able to open any process by itself (by the way this is the only usable hex editor for linux). Tried running as root as well.
The problem was the ida debugger (linux_serverx64) was somehow denying access to the process memory while being attached to the process. This is really stupid IMO. In windows I can both attach a debugger into a process and externally read/write to the process memory (using HxD for example). I don't know if this is a problem with the debugger or with the OS.
Editing process memory is a debugger-a-like feature in HxD, it's no way something the OS would grant you. Memory isn't a trivial bytemap and w/o stopping the process, you'd be pointing a moving target (so if you edit the heap, you just edit "something")
I know what I'm doing. You don't need to stop a process in order to edit its memory. The point is in windows I can both debug a process with lets say IDA and at the same time open it in edit mode with HxD. For now I haven't found a way to do the same in linux. It's either the problem in the OS or the IDA debugger.
Edit (2): I think the only way to fix my problem, is to decompile the .exe (I guess it's written in C, or?) and change the minimum time. Then I have to compile it again. Is this procedure even workable? What things could fail?
Now, the problem here is that when I try to breakpoint at that location I can no longer type anything because osk.exe adds itself to the input drivers. This can easily be seen by holding a modifier key like Alt on your keyboard, this lights it up in osk.exe.
It might be in one of the four cmp (compare) instructions, but that would require debugging information. Or it could happen in a higher up function altogether, which would require more investigation. But without the ability to debug it without losing input capabilities, this is a very hard thing to do...
Seems that finding the right location will require a debug cable as the computer on which you debug loses its input capabilities, or is way too slow due to the overhead of debugging. As I don't currently have a laptop with a 1943 port, I'm unable to do this debugging myself. It would be able to do this, and yes, it would literally freeze your OS. Debugging an OS instead of an application is fun... ^^
Change the jz instruction into a jmp instruction which always do the jump, you can find it at relative offset 41BC10. In case your program calculates offsets different, you need to know that it uses 401000 as a basis so subtracting gives us the absolute offset 1AC10.
Please note that changing 74 (JZ) in the hex editor to E9 (JMP) won't work. You can't do this in a hex editor, you will need something that disassembles and reassembles the code but that's not necessarily easy to find (eg. IDA Professional which people actually pay for, can't produce proper c code or an executable. OllyDBG, commonly used in the patch community, can't even open the executable.). And then even, Microsoft might be protecting its executable against tampering, because this could be considered against the EULA; so, good luck!
You should definitely check out Dasher which is way faster than an On-Screen Keyboard. It simply works by moving your mouse towards letters; horizontal movement determines the speed and vertical movement select the letters. With a dictionary built in it can even size the most likely letters to be bigger, it also tries to learn from your movement such that the speed and letters are really accustomed to your usage.
Of course this is rather small and not really fast as it's an example, but you could resize it to be at the right side of your screen such that it does not interfere with your screen. This allows you to type as fast as you can...
Also note that the letters at the right are sorted in a specific order, such that the major direction (up, mid or down) chooses between the different types (lowercase, uppercase, numbers and punctuation); and then within such major direction, your minor direction will choose between A-Z, a-z, 0-9 and so on. I've used this in the past and was actually amazed by how fluent this is compared to other competitors...
The decompilation can only help to pinpoint the area that HKEY_CURRENT_USER\Software\Microsoft\Osk\HoverPeriod is used, so as to find out where this value is read and where the 500 ms limit is enforced.
You could either use a C-decompiler or a disassembler. The later type may be more useful, although it requires some small knowledge of the Intel instruction set. You will also need a good hex editor, and there are some that advertise disassembler capabilities (see link below).
project fenris advertises itself as "suite of tools suitable for code analysis, debugging, protocol analysis, reverse engineering, forensics, diagnostics, security audits, vulnerability research and many other purposes". Sounds good and recommended by many, but I have no experience with it.
Search for the string "HoverPeriod" (case insensitive). If you are lucky, the disassembler has identified it as a string and you can find it as-is. If not, you will need to search for it byte-by-byte. As a Unicode string it will look like H,0,o,0,v,0... where the letters should be replaced by their numerical codes.
Once you have found the "HoverPeriod" string, the disassembler should have placed a label somewhere before it. Use the name of this generated label to search for where it is used, to identify where it is retrieved from the registry and in which global variable is the result stored.
Locating the command to patch in osk.exe may require searching if the offsets that the disassembler gives are in the code rather than in the exe file. If the hex editor doesn't support assembler search, do the disassembly while listing the original instruction bytes so you will know for which binary bytes to search for. Avoid searching for instructions that contain addresses, since addresses may be relocated in the exe, so rather search for a sequence of bytes near-to such an instruction.
You can create the new patch bytes either directly in the hex editor if it supports assembler. Or if it doesn't and you don't feel comfortable with Intel machine code, find an assembler to compile your new code and use its listing to get the compiled bytes to use for patching.
The idea would be to monitor mouse idling when the cursor is within the on-screen window (e.g. in a control loop, checking at a regular interval whether cursor has changed position) and auto-click (call function SendClick) after, say, 100ms of inactivity.
Maybe you don't have to recompile everything. In the game-world it's common to use trainers, which manipulate a value in memory when the program is running. If you find the minimum value in memory (0.5) and program something like a loader to make that number smaller, it could work.
I'm assuming we're talking about desktop games -- something the player downloads and runs on their local computer. Many are the memory editors that allow you to detect and freeze values, like your player's health.
I think it's kinda pointless to try to prevent stuff like this. People have successfully created hacks/cheats for much more complex stuff and it just needlessly obfuscates your code or makes your game perform worse.
Here's the nasty bit: every time you manipulate the value, free and allocate the bits again. Allocation should happen in random order, so the data jumps around in memory and can't be easily frozen.
Additional safeguards would be to store checksums of the values (as well as the "plain" int) and compare these during the manipulation calls too. If mismatch is found, do something subtle, like remove a random key needed to unlock doors to progress in the game.
Edit: For multiplayer games, it's also possible to serialize the data structure, compress it, and send it over the network. Not the most efficient use of the network, but definitely harder to figure out through packet sniffing.
How about you store the health complemented with a random value generated each time you store it. This would at least defeat the simple mechanism of searching for increasing/decreasing values in memory to find the health.
In addition, you might want to reset the value each frame, even if the health doesn't change. This will prevent people from searching for changed addresses when their health changes and that stay the same when their health stays the same.
Although I made the first comment questioning the point of degrading the experience of a portion of your audience for no apparent gain, I still find it an interesting question from a technical point of view.
I just had this idea: What cheaters do is find values that change and freeze them. The search would then happen only between deaths or events that changed the player's health. Moreover, the cheater could be refining the search by filtering out what changed when he was "not dying".
What if the "health" counter is changing the whole time? Make it a pointer and reallocate it every frame or every N frames if the performance hit is too big. Or XOR it with a random value that changes every frame (XORing again against the same value for decrypting before encrypting with a new random value).
If you have other in-game data also changing the whole time (including x and y positions of the player character, or the time counter), that might make it harder to find out which of all the changing data is the health. And freezing the whole game state is a no-go for the cheater.
Still, the cheater might try to find which of the variables that is changing the whole time is the one to freeze through trial and error. A possible solution would be to couple the variables together.
This way, if the cheater freezes only one of them and then moves the character, the position is affected and, depending on which one was frozen, h goes negative (instant death). You can switch between the above formulas and:
64591212e2