When writing code that is to be injected into a running process, and subsequently call functions from within that application, sometimes you need to create a function pointer if you're wanting to call a function provided by that application itself - in the manner of a computer-based training application, or a computer game hack, etc.
Function pointers are easy in C++, if you know the offset of the function. Finding those offsets are what become the time consuming part, if the application that you're working with is frequently updated, because updates to the application may change the offset.
Are there any methods of automatically tracking these offsets? I seem to recall hearing about fingerprinting methods or something that would attempt to automatically locate the functions for you. Any ideas about those?
This is very dependent on what you're injecting into and the environment you're running.
If you're in a windows environment, i'd give this a read through
x86 code injection into an x86 proccess from a x64 process
In a linux type environment you could do something with the global offset table?
You could always do signature based approach to find the function. Or perhaps there is an exported function that calls the function you want to hook. You could trace the logic as such.
Related
I am using C++ with Qt and I am struggling to find the way to achieve something I never did before.
Here is what I want to achieve :
I have a client (let's call it Client.exe) which I don't have access to the source and a launcher (let's call it... Launcher.exe) which I have access to the source.
Cient.exe needs a password and a username, supposed to come from Launcher.exe.
If I had only one couple password/username, I know I could make a .dll and inject it, but since I can have a lot of combinaisons, that is impossible.
So here is my question, what is the way to make a link allowing me to send password and username from Launcher.exe to Client.exe ?
Second question would be : is there a way to use VirtualProtect and this kind of stuff (in order to modify some instructions in memory), with an executable, meaning without any injection ? (I guess the answer is no, but I want to be sure)
Your "Launcher.exe" and your DLL injected into "Client.exe" can communicate with each other via interprocess communication, for example through file mapping. This could be used for "Launcher.exe" to pass any desired username and password to "Client.exe".
However, the main problem I see is how to get "Client.exe" to use this data, if you do not have access to the source code and if it also does not provide an API for this.
If you want to trick "Client.exe" into using the data provided by you (or by your injected DLL) instead of the intended data, then you must reverse engineer the program and change the appropriate instructions so that they load your data instead of the original data. Since you do not have access to the C/C++ source code, you will have to understand the assembly language instructions to accomplish this.
In order to find out which instructions to change, you will likely need a debugging tool such as x64dbg, which is designed to debug applications that you haven't written yourself (and have no source code for) and possibly also a static analysis tool, such as IDA or Ghidra. Furthermore, if the program deliberately protects itself from reverse-engineering, you will have to learn how to overcome this (which can be very hard).
You could also accomplish this without injecting a DLL, by using WriteProcessMemory. You may need to also use VirtualAllocEx if you need extra memory inside the target process, for example for injecting instructions or data.
In any case, before tampering with another process's instructions or data, it may be advisable to suspend all of its threads using SuspendThread, and then resuming all threads afterwards with ResumeThread. Otherwise, if the program runs while its instructions or data are in an inconsistent state, the program may crash.
I'm writing a service (i.e. background process) and want to offer starting it via a shared library. That is, someone wanting to use the service would link to the shared library, call it's start() method, which would fork and return. The fork would then run the service.
The problem with this approach is that the service process now might have a lot of legacy allocated memory it actually doesn't need. Is there a way to get rid of that and have the forked process allocate its own stuff? I know about exec() of course, but the problem with that is
that I need an executable which might not be in the location I expect it to be due to different operating system folder layouts
that I'd have to cast all potential parameters to string to pass it as program arguments to exec().
So basically, I'm looking for a way to call an arbitrary function func() with some parameters that should run in a new process, and everything not passed into that function shouldn't be in the new process. Is there a way to achieve this or something similar?
This is an interesting question that I sadly don't have a good answer for. I doubt any cleanup strategies like sbrk+close+munmap will reliably allow any libc based code to continue to function, so I'd try to make exec'ing better:
For any kind of exec based solution, you should be able to deep-copy data into shm to pass non-strings. This should take care of your second problem.
Here are some wild suggestions for your first issue:
Don't: just require that an executable is in PATH or a compile-time directory.
This is transparent and follows the UNIX philosophy. An error message Can't find myhelper in PATH will not slow anyone down. Most tools depending on helper executables do this, and it's fine.
Make your library executable, and use that as your exec target. You can try finding its name with some kind of introspection, perhaps /proc/self/maps or whatever glibc offers.
Like above, but exec python or something you can be reasonably sure exists, and use a foreign pointer interface to run a function on your library.
As part of your build process, compile a tiny executable and include it as binary data in your library. Write it to /tmp and execute.
Out of these, I prefer the simplicity and transparency of #1, even if that's the most boring solution.
Standard hacking case. Hack file type injects into a started process and writes over process memory using WriteProcessMemory call. In games this is not something you would want because it can provide the hacker to change the portion of the game and give himself an advantage.
There is a possibility to force a user to run a third-party program along with the game and I would need to know what would be the best way to prevent such injection. I already tried to use a function EnumProcessModules which lists all process DLLs with no success. It seems to me that the hacks inject directly into process memory (end of stack?), therefore it is undetected. At the moment I have came down to a few options.
Create a blacklist of files, file patterns, process names and memory patterns of most known public hacks and scan them with the program. The problem with this is that I would need to maintain the blacklist and also create an update of the program to hold all avalible hacks. I also found this usefull answer Detecting memory access to a process but it could be possible that some existing DLL is already using those calls so there could be false positives.
Using ReadProcessMemory to monitor the changes in well known memory offsets (hacks usually use the same offsets to achieve something). I would need to run a few hacks, monitor the behaviour and get samples of hack behaviour when comparing to normal run.
Would it be possible to somehow rearrange the process memory after it starts? Maybe just pushing the process memory down the stack could confuse the hack.
This is an example of the hack call:
WriteProcessMemory(phandler,0xsomeoffset,&datatowrite,...);
So unless the hack is a little more smarter to search for the actual start of the process it would already be a great success. I wonder if there is a system call that could rewrite the memory to another location or somehow insert some null data in front of the stack.
So, what would be the best way to go with this? It is a really interesting and dark area of the programming so I would like to hear as much interesting ideas as possible. The goal is to either prevent the hack from working or detect it.
Best regards
Time after time compute the hash or CRC of application's image stored in memory and compare it with known hash or CRC.
Our service http://activation-cloud.com provides the ability to check integrity of application against the signature stored in database.
I am profiling an application using VerySleepy 0.7. The application is written in C++ with Qt 4.6.x, compiled with VS 2005 and is running on Windows 7 Ultimate x64.
The highest usage by far is a call to RtlPcToFileHeader
Exclusive Inclusive %Exclusive %Inclusive Module
33.67s 33.67s 15.13% 15.13% ntdll
It is not clear to me from the documentation what RtlPcToFileHeader is but because it is referenced under "Error Handling Functions" it seems like it is something that should not be there. That being said, since it was used basically throughout my profiling capture, it could also be some very basic function call (i.e. something like main) or a side affect of the profiling itself.
What is the purpose of the RtlPcToFileHeader function?
Update: Based on Mike's suggestion, I did break into the running process and the couple times it included RtlPcToFileHeader in the stack trace it seemed somehow tied to a dynamic_cast. I have also changed to question to better reflect that I am trying to determine what RtlPcToFileHeader actually does.
The following MSDN post implies that Microsoft's x64 implementation of the RTTI routines, invoked during dynamic_cast, is slower than the x86 one.
http://blogs.msdn.com/b/junfeng/archive/2006/10/17/dynamic-cast-is-slow-in-x64.aspx
These RTTI pointers on 64-bit systems seem to be only offsets from the base address of the module. To dereference them, you need the module base address--which is retrieved by the API function ::RtlPcToFileHeader().
If this is correct, it seems that you can't do anything about it, except refactor your code to minimize the use of dynamic_casts and rely more on virtual methods. Or could it be only an imperfection of the profiler--it gets lost in dynamic_casts?
RtlPcToFileHeader is a function that uses an arbitrary address (PcValue) to look up a base address of the matching module mapped into the address space of the current process. It is very similar to calling:
HMODULE hModule = NULL;
GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS |
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
pArbitraryAddr,
&hModule);
For its search it goes through mapping addresses of all modules mapped into the current process, for which it uses the process' PEB/TEB structures in memory. Before doing that, it acquires a shared RW lock (similar to calling AcquireSRWLockShared) and then releases it when the search is done.
Just pause it under the debugger. Study the call stack to understand what it was doing and why. Then repeat several times. That will tell you where the time is going and the reasons why.
If that's too low-tech for you, try out LTProf, or any other wall-time stack sampler that reports line-level percent, preferably with a butterfly viewer.
The kind of numbers you are puzzling over is precisely the legacy of gprof.
I am working on a fairly large project that runs on embedded systems. I would like to add the capability of logging which thread called which function from which class and at what time. E.g., here's what a typical line of the log file would look like:
Time - Thread Name - Function Name - Class Name
I know that I can do this by using the _penter hook function, which would execute at the beginning of every function called within my project (Source: http://msdn.microsoft.com/en-us/library/c63a9b7h%28VS.80%29.aspx). I could then find a library that would help me find the function, class, and thread from which _penter was called. However, I cannot use this solution since it is VC++ specific.
Is there a different way of doing this that would be supported by non-VC++ implementations? I am using the ARM/Thumb C/C++ Compiler, RVCT3.1. Additionally, is there a better way of tracking problems that may arise from multithreading?
Thank you,
Borys
I've worked with a system that had similar requirements (ARM embedded device). We had to build much of it from scratch, but we used some CodeWarrior stuff to do it, and then the map file for the function name lookup.
With CodeWarrior, you can get some code inserted into the start and end of each function, and using that, you can track when you enter each function, and when you switch threads. We used assembly, and you might have to as well, but it's easier than you think. One of your registers will be your return value, which is a hex value. If you compile with a map file, you can then use that hex value to look up the (mangled) name of that function. You can find the class name in the function name.
But, basically, get yourself a stream to somewhere (ideally to a desktop), and yell to the stream:
Entered Function #####
Left Function #####
Switched to Thread #
(PS - Actual encoding should be more like 1 21361987236, 2 1238721312, since you don't actually want to send characters)
If you're only ever processing one thread at a time, this should give you an accurate record of where you went, in the order you went there. Attach clock tick info for function profiling, add a message for allocations (and deallocations) and you get memory tracking.
If you're actually running multiple threads, it could get substantially harder, or be more of the same - I don't know. I'd put timing information on everything, and then have a separate stream for each thread. Although you might just be able to detect which processor you're running on, and report that, for which thread.... I don't, however, know if any of that will work.
Still, the basic idea was: Report on each step (function entry/exit, thread switching, and allocation), and then re-assemble the information you care about on the desktop side, where you have processing to spare.
gcc has PRETTY_FUNCTION define. With regard to thread, you can always call gettid or similar.
I've written a few log systems that just increment a thread # and store in in thread-local-data. That helps with giving thread of log statements. (time is easy to print out)
For tracing all function calls automatically, I'm not so sure. If it's just a few, you can easily write an object & macro that logs entry/exit using the __FUNCNAME__ #define (or something similar for your compiler).