If got a native application which adds value by for instance analyzing measurement data from measurement programs. Some of them have an API, so I can get their data via IPC. But how can I achieve this for specific native programs, which won't support this?

AFAIK I have to reverse engineer the assembly, look for the variables, to know where they should be in the foreign process. I found books for this and does not seem to be that hard, but whats the "best practice" to actually access the foreign process, in a most stable and less intrusive way? I found, on the windows platform, DLL injection is very common, so I can inject code to craft an IPC-API and find the data.

Are there better methods? Is the DLL-injection method feasible? How about automatic attaching a small debugger?

The specific third party application is a native Win32 program, no source code, no symbol tables, and target platform is at or above Windows 8

  • 1
    I don't think that this is answerable in the general case. How feasible this is, whether it is advisable, and the best approach to take will depend on the specific software and what you are trying to accomplish.
    – user82096
    Apr 13, 2017 at 7:42
  • 1
    Note that this is often a bad idea, and there may be legal issues with it, too, I think, depending on the software's license agreement.
    – user82096
    Apr 13, 2017 at 7:54
  • @dan1111 I know it's not best best approach, but sometimes its necessary, may just to get the third party so supply a real API later. I'm also aware of the legal issues, luckily the german law is much in favour for creating interoperability when you bought a license to even only use the software. I'm just looking for a few pointers to common techniques, which I will evaluate anyway. Apr 13, 2017 at 8:04
  • Please add to your question what you know about the software you are trying to interface with: do you know the programming language it was written in? is the source code available? what OS are you trying to do this on? We cannot help without such info.
    – marstato
    Apr 13, 2017 at 8:25
  • 1
    In that case you got it right: you will have to reverse engineer. Your solution will likely break with every update of the target software. Whether that is feasible still depends on the complexity of the target software and on how much if its data you need to access.
    – marstato
    Apr 13, 2017 at 9:17

2 Answers 2


If the entire application is contained on a specific server, it is most likely writing that data somewhere, you may be able to find the datafile and then see if you can make sense of that.

If the application is sending data to some main server somewhere else you might want to look into listening to what's being sent out, assuming that data isn't encrypted.

  • This is a native application, also not using RPC, so your answer does not make any sense to me. And the data is not necessarily persisted either. May 11, 2017 at 11:55
  • Ok, so no RPC or REST or any of that. Still I am surprised that there is no data persisted of any kind. Not even in a text file somewhere or in logs written to the system. That is the approach I would go with and not DLLs. Good luck.
    – unflores
    May 16, 2017 at 10:03

I found out that the buzzwords i.e. terms which summarises or lets you find the best information the best techniques are "Hooking" (good wikipedia article on that), "DLL injection" a technique for Hooking at windows platforms and as I already knew "reverse engineering of course".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.