I am studying about the windows programming, and i have some question.
I saw a security module that defends memory data.
if one process is going to change other process memory, it detects and turns off the process.
This is often used in anti-cheat engines in games or bank application programs(i live in Korea, so i think this is the best example of this. Almost every on-line games or bank application has self-defence algorithm.)
My question is, is there any APIs or functions that detects about this?
thanks.
P.S.
i can make an example,
if 0x01000000 memory data is 'A', some different process changed it to 'B'.
when i first thought about this, i thought that i have to make a thread to check the data and if it changes, turn off the process.
but i think this is not a good idea. any suggestions?
General answer to your question: no, there are no such API or functions.
But there are different methods where you can achieve same result.
1. Api hooking. You can Hook functions in system (such as WriteProcessMemory) and then check if somebody trying to change something in your process. More on this here.
2. Debugging. You can use debugging breakpoints on functions or memory change.
There's an API that allows you to monitor writing operations into a piece of the specific memory area.
UINT GetWriteWatch(
DWORD dwFlags,
PVOID lpBaseAddress,
SIZE_T dwRegionSize,
PVOID *lpAddresses,
ULONG_PTR *lpdwCount,
LPDWORD lpdwGranularity
);
When the API detects any writing operations, it appends the writing addresses into the arrays that you provided as the parameter of the API, until your array is full.
Related
I was reading code from one of the projects from github. I came across something called a Vectored Referencing buffer implementation. Can have someone come across this ? What are the practical applications of this. I did a quick google search and wasn't able to find any simple sample implementation for this.
Some insight would be helpful.
http://www.ibm.com/developerworks/library/j-zerocopy/
http://www.linuxjournal.com/article/6345
http://www.seccuris.com/documents/whitepapers/20070517-devsummit-zerocopybpf.pdf
https://github.com/joyent/node/pull/304
I think some more insight on your specific project/usage/etc would allow for a more specific answer.
However, the term is generally used to either change or start an interface/function/routine with the goal that it does not allocate another instance of its input in order to perform its operations.
EDIT: Ok, after reading the new title, I think you are simply talking about pushing buffers into a vector of buffers. This keeps your code clean, you can pass any buffer you need with minimal overhead to any function call, and allows for a better cleanup time if your code isn't managed.
EDIT 2: Do you mean this http://cpansearch.perl.org/src/TYPESTER/Data-MessagePack-Stream-0.07/msgpack-0.5.7/src/msgpack/vrefbuffer.h
I'm working on a third-party program that aggregates data from a bunch of different, existing Windows programs. Each program has a mechanism for exporting the data via the GUI. The most brain-dead approach would have me generate extracts by using AutoIt or some other GUI manipulation program to generate the extractions via the GUI. The problem with this is that people might be interacting with the computer when, suddenly, some automated program takes over. That's no good. What I really want to do is somehow have a program run once a day and silently (i.e. without popping up any GUIs) export the data from each program.
My research is telling me that I need to hook each application (assume these applications are always running) and inject a custom DLL to trigger each export. Am I remotely close to being on the right track? I'm a fairly experienced software dev, but I don't know a whole lot about reverse engineering or hooking. Any advice or direction would be greatly appreciated.
Edit: I'm trying to manage the availability of a certain type of professional. Their schedules are stored in proprietary systems. With their permission, I want to install an app on their system that extracts their schedule from whichever system they are using and uploads the information to a central server so that I can present that information to potential clients.
I am aware of four ways of extracting the information you want, both with their advantages and disadvantages. Before you do anything, you need to be aware that any solution you create is not guaranteed and in fact very unlikely to continue working should the target application ever update. The reason is that in each case, you are relying on an implementation detail instead of a pre-defined interface through which to export your data.
Hooking the GUI
The first way is to hook the GUI as you have suggested. What you are doing in this case is simply reading off from what an actual user would see. This is in general easier, since you are hooking the WinAPI which is clearly defined. One danger is that what the program displays is inconsistent or incomplete in comparison to the internal data it is supposed to be representing.
Typically, there are two common ways to perform WinAPI hooking:
DLL Injection. You create a DLL which you load into the other program's virtual address space. This means that you have read/write access (writable access can be gained with VirtualProtect) to the target's entire memory. From here you can trampoline the functions which are called to set UI information. For example, to check if a window has changed its text, you might trampoline the SetWindowText function. Note every control has different interfaces used to set what they are displaying. In this case, you are hooking the functions called by the code to set the display.
SetWindowsHookEx. Under the covers, this works similarly to DLL injection and in this case is really just another method for you to extend/subvert the control flow of messages received by controls. What you want to do in this case is hook the window procedures of each child control. For example, when an item is added to a ComboBox, it would receive a CB_ADDSTRING message. In this case, you are hooking the messages that are received when the display changes.
One caveat with this approach is that it will only work if the target is using or extending WinAPI controls.
Reading from the GUI
Instead of hooking the GUI, you can alternatively use WinAPI to read directly from the target windows. However, in some cases this may not be allowed. There is not much to do in this case but to try and see if it works. This may in fact be the easiest approach. Typically, you will send messages such as WM_GETTEXT to query the target window for what it is currently displaying. To do this, you will need to obtain the exact window hierarchy containing the control you are interested in. For example, say you want to read an edit control, you will need to see what parent window/s are above it in the window hierarchy in order to obtain its window handle.
Reading from memory (Advanced)
This approach is by far the most complicated but if you are able to fully reverse engineer the target program, it is the most likely to get you consistent data. This approach works by you reading the memory from the target process. This technique is very commonly used in game hacking to add 'functionality' and to observe the internal state of the game.
Consider that as well as storing information in the GUI, programs often hold their own internal model of all the data. This is especially true when the controls used are virtual and simply query subsets of the data to be displayed. This is an example of a situation where the first two approaches would not be of much use. This data is often held in some sort of abstract data type such as a list or perhaps even an array. The trick is to find this list in memory and read the values off directly. This can be done externally with ReadProcessMemory or internally through DLL injection again. The difficulty lies mainly in two prerequisites:
Firstly, you must be able to reliably locate these data structures. The problem with this is that code is not guaranteed to be in the same place, especially with features such as ASLR. Colloquially, this is sometimes referred to as code-shifting. ASLR can be defeated by using the offset from a module base and dynamically getting the module base address with functions such as GetModuleHandle. As well as ASLR, a reason that this occurs is due to dynamic memory allocation (e.g. through malloc). In such cases, you will need to find a heap address storing the pointer (which would for example be the return of malloc), dereference that and find your list. That pointer would be prone to ASLR and instead of a pointer, it might be a double-pointer, triple-pointer, etc.
The second problem you face is that it would be rare for each list item to be a primitive type. For example, instead of a list of character arrays (strings), it is likely that you will be faced with a list of objects. You would need to further reverse engineer each object type and understand internal layouts (at least be able to determine offsets of primitive values you are interested in in terms of its offset from the object base). More advanced methods revolve around actually reverse engineering the vtable of objects and calling their 'API'.
You might notice that I am not able to give information here which is specific. The reason is that by its nature, using this method requires an intimate understanding of the target's internals and as such, the specifics are defined only by how the target has been programmed. Unless you have knowledge and experience of reverse engineering, it is unlikely you would want to go down this route.
Hooking the target's internal API (Advanced)
As with the above solution, instead of digging for data structures, you dig for the internal API. I briefly covered this with when discussing vtables earlier. Instead of doing this, you would be attempting to find internal APIs that are called when the GUI is modified. Typically, when a view/UI is modified, instead of directly calling the WinAPI to update it, a program will have its own wrapper function which it calls which in turn calls the WinAPI. You simply need to find this function and hook it. Again this is possible, but requires reverse engineering skills. You may find that you discover functions which you want to call yourself. In this case, as well as being able to locate the location of the function, you have to reverse engineer the parameters it takes, its calling convention and you will need to ensure calling the function has no side effects.
I would consider this approach to be advanced. It can certainly be done and is another common technique used in game hacking to observe internal states and to manipulate a target's behaviour, but is difficult!
The first two methods are well suited for reading data from WinAPI programs and are by far easier. The two latter methods allow greater flexibility. With enough work, you are able to read anything and everything encapsulated by the target but requires a lot of skill.
Another point of concern which may or may not relate to your case is how easy it will be to update your solution to work should the target every be updated. With the first two methods, it is more likely no changes or small changes have to be made. With the second two methods, even a small change in source code can cause a relocation of the offsets you are relying upon. One method of dealing with this is to use byte signatures to dynamically generate the offsets. I wrote another answer some time ago which addresses how this is done.
What I have written is only a brief summary of the various techniques that can be used for what you want to achieve. I may have missed approaches, but these are the most common ones I know of and have experience with. Since these are large topics in themselves, I would advise you ask a new question if you want to obtain more detail about any particular one. Note that in all of the approaches I have discussed, none of them suffer from any interaction which is visible to the outside world so you would have no problem with anything popping up. It would be, as you describe, 'silent'.
This is relevant information about detouring/trampolining which I have lifted from a previous answer I wrote:
If you are looking for ways that programs detour execution of other
processes, it is usually through one of two means:
Dynamic (Runtime) Detouring - This is the more common method and is what is used by libraries such as Microsoft Detours. Here is a
relevant paper where the first few bytes of a function are overwritten
to unconditionally branch to the instrumentation.
(Static) Binary Rewriting - This is a much less common method for rootkits, but is used by research projects. It allows detouring to be
performed by statically analysing and overwriting a binary. An old
(not publicly available) package for Windows that performs this is
Etch. This paper gives a high-level view of how it works
conceptually.
Although Detours demonstrates one method of dynamic detouring, there
are countless methods used in the industry, especially in the reverse
engineering and hacking arenas. These include the IAT and breakpoint
methods I mentioned above. To 'point you in the right direction' for
these, you should look at 'research' performed in the fields of
research projects and reverse engineering.
I'm writing a linux kernel module that emulates a block device.
There are various calls that can be used to tell the block size to the kernel, so it aligns and sizes every request toward the driver accordingly. This is well documented in the "Linux Device Drives 3" book.
The book describes two methods of implementing a block device: using a "request" function, or using a "make_request" function.
It is not clear, whether the queue limit calls apply when using the minimalistic "make_request" approach (which is also the more efficient one if the underlying device is has really no benefit from sequential over random IO, which is the case with me).
I would really like to get the kernel to talk to me using 4K block sizes, but I see smaller bio-s hitting my make_request function.
My question is that should the blk_queue_limit_* affect the bio size when using make_request?
Thank you in advance.
I think I've found enough evidence in the kernel code that if you use make_request, you'll get correctly sized and aligned bios.
The answer is:
You must call blk_queue_make_request first, because it sets queue limits to defaults. After this, set queue limits as you'd like.
It seems that every part of the kernel submitting bios are do check for validity, and it's up to the submitter to do these checks. I've found incomplete validation in submit_bio and generic_make_request. But as long as no one does tricks, it's fine.
Since it's a policy to submit correct bio's, but it's up to the submitter to take care, and no one in the middle does, I think I have to implement explicit checks and fail the wrong bio-s. Since it's a policy, it's fine to fail on violation, and since it's not enforced by the kernel, it's a good thing to do explicit checks.
If you want to read a bit more on the story, see http://tlfabian.blogspot.com/2012/01/linux-block-device-drivers-queue-and.html.
Title pretty much sums it up. I just found out about this function and well, it surprised me it existed as immediately the possible security consequences sprung into mind.
Why is there such a function? I understand that for debugging something like this is more or less necessary but allowing it for all processes seems like a big security problem.
Am I missing something?
If the function is needed to write a debugger, then the function must exist, it's as simple as that. The hProcess argument must have been opened with sufficient privileges to write into the process, and it will be difficult for malware to do that.
If you read the MSDN documentation for WriteProcessMemory you will see,
hProcess [in]
A handle to the process memory to be modified.
handle must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process.
So you already have to have access to the process you want to modify. So the users can't mess with each other's processes using this function.
I am using Radio Layer Interface (RIL) Native APIs in Windows Mobile application. In this API, the return values / results of most functions are not returned immediately but are passed through a callback function which is passed to the RIL API.
Some usage examples are found at XDA Develompent Tools and Google Gears Geolocation API.
My question is, in these two examples, a mutex is used to guard the data instead of other synchronization objects.
Now, will Critical Section do fine here in the use cases described by both examples? Which thread or process will actually call the callback functions?
Edit:
My data is accessed by my codes only from inside my process but which thread/process is calling the callback functions in RIL API? I mean, I passed a function callback to the RIL API, but are the callbacks called from other process? in that case, it will give another explanation why the samples are using Mutex. If the RIL API actually creates a thread inside my process and it calls my callback functions, then I think Critical Section would be fine (and it's faster than a mutex).
Update:
I have data which is (1) accessed by my codes from within my own process and is also (2) modified from a function callback. The callback is done by RIL API.
My Question: Which thread/process is calling the callback functions in RIL API?
The Story so far:
Me: Hi Mr RIL, please put some data into my office (a.k.a variables).
RIL: OK Sir. I will put the data later and I will signal you when it is done (I used an event here).
An access card is required to enter my office. If Mr RIL is from the same company as me, Mr RIL can use his own access card to enter my office (in my case, it means a Critical Section). If he is from other companies, I will need to set up an access card/visitor card for him (in my case, I need a mutex here).
If Mr RIL uses his own access card, it means I don't need to set up an access card/visitor card for him and that means less trouble for me. (i.e. Critical Section is faster than a Mutex)
The problem is, I just met this Mr RIL a few days ago and I don't know much about him. I don't know if he is from the same company as me. One option as mentioned by nobugz is to set up an access card for Mr RIL regardless whether Mr RIL is from the same company as me. This way, Mr RIL is guaranteed to be able to enter my office. (my data/variables are guaranteed to be safe)
Right now I use mutex in my code (set up a possibly redundant access card for Mr RIL).
Aha! Just got an idea when writing this. I think I will just ask Mr RIL from which company he is. That way, I don't have to set up access card for him in the future if he turns out to be in the same company as me. (i.e. put GetCurrentProcessId() and GetCurrentThreadId() in the callback function)
The Windows Mobile RIL normally resides in device.exe (for WM6.x). However, when your process invokes the RIL, your call passes via the RIL Proxy.
The RIL proxy is linked with, and resides in your process, and handles all of the issues associated with process boundaries for you (as an aside, this is at least part of the reason why all RIL data structures need to be packed into a single block of memory of known size). Internally the RIL Proxy creates a thread on which your callback is executed.
This means that your code can use a CRITICAL_SECTION object to provide the necessary synchronization/protection.
The point of using the mutex is that you don't know what thread might make the callback. Yes, a critical section would work too. Careful, getting it wrong causes random and very hard to diagnose failure.
A critical section is a mutex. A critical section is different from a normal mutex (at least primarily) in one way: it's specific to one process, where a mutex can be used across processes.
So, in this case, the basic question is exactly what you're protecting -- if it's the data inside your program, that won't be accessible to another process, then a critical section should do the job nicely. If you're protecting something that would be shared by the two processes if the user were to run two instances of your program at once, then you probably need a mutex.
Edit: As far as having to use a critical section to protect what RIL itself does, no, that isn't (or at least definitely shouldn't) be needed. With a mutex, you're counting on all the processes cooperate by opening a mutex with the same name to control access to the shared resource(s). You can't count on that, so if it is needed the interface is completely broken.
Update: unless they're doing something really unusual in RIL, the callback will happen within your process, so a critical should be adequate. If it's modifying your data, that means your data is mapped and visible to that code -- which means the data in the data in the critical section will also be mapped and visible, and it'll work. The time a critical section doesn't work is when you're dealing with separate processes, so the data in one isn't mapped/visible to the other.
Well, one other difference between a mutex and a critical section (Windows implementations, of course) is that a critical section is re-entrant - i.e. the same thread can acquire the critical section twice without having to release it.