views:

55

answers:

4

Hi, guys.

I have an application, which displays me some data. I need to attach to this app's process, find the data I need in memory (one single number, actually), and save it somewhere. This application doesn't seem to use standard windows controls, so things aren't going to be as simple as reading controls data using AutoIt or something similar.

Currently I'm a self-learner database guy and have quite shallow knowledge about windows apps debugging. Not even sure if I asked my question correctly enough.

So, can you give me some starter guidelines about, say, what should I read first, and general directions I should work on?

Thanks.

A: 

I used to know the windows debugging API but it's long lost memory. How about using ollydbg:

http://www.ollydbg.de/

And controlling that with both ollydbg script and autoit?

Here's some wealth of knowleedge about olly: http://reversengineering.wordpress.com/
+2  A: 

My primary advice is: try to find any other method of integration than this. Even if you succeed, you'll be hostage to any kinds of changes in the target process, and possibly in the Windows O/S. What you are describing is behaviour most virus scanners should flag and hinder: if not now, then in the future.

That said, you can take a look at DLL injection. However, it sounds as if you're going to have to debug the heck out of the target process at the disassembly level: otherwise, how are you going to know what memory address to read?

Pontus Gagge
+1 avoid this at all costs.
SLaks
I don't care about any changle problems pretty much as this is going to be a one-off job - I just need to collect some constant data and forget it. I could have collected it using this application's API, but it doesn't provide me a way to get these numbers for unknown reason.
be here now
In my experience, it's the quick-n-dirty do-it-once, get-it-over-with, this-won't-matter-in-six-months'-time jobs that **really** turn out to need to be supported forever plus six months. Good luck...
Pontus Gagge
in fact, this is not a job, that is ever going to be supported. in fact, this is not a job at all. this is just a tribute to my curiosity and desire to play with different programming things, related to my "real-life" projects in absolutely no way. no one would never ever support it, 'cause no one would never ever even see it, 'cause it would never ever leave my personal, home desktop. calm down ;)
be here now
A: 

Sounds interesting... but very difficult. Since you say this is a 'one-off', what about something like this instead?

  • Take a screenshot of this application.
  • Run the screenshot through an OCR program
  • If you are able to read the text you are looking for in a predictable way, you're halfway there!

So now if you can read a OCR'd screenshot of your application, it is a simple matter of writing a program that does the following:

  • Scripts the steps to get the data on the screen
  • Creates a screenshot of the data in question
  • Runs it through an OCR program like Microsoft Office Document Imaging
  • Extracts the relevant text and does 'whatever' with it.

I have done something like this before with pretty good results, but I would say it is a fragile solution. If the application changes, it stops working. If the OCR can't read the text, it stops working. If the OCR reads the wrong text, it might do worse things than stop working...

As the other posters have said, reaching into memory and pulling out data is a pretty advanced topic... kudos to you if you can figure out a way to do that!

mpeterson
I didn't realize you were doing this for fun. I'll leave my answer up anyway as an alternative method.
mpeterson
+1  A: 

To read memory of other application you need to open the process with respect of OpenProcess with at least PROCESS_VM_READ access rights and then use ReadProcessMemory to read any memory address from the process. If you are an administrator or have debug privilege you will be able to open any process with maximal access rights, you need only to enable SeDebugPrivilege before (see for example http://support.microsoft.com/kb/131065).

If you don't know a much about the memory of the destination process you can just enumerate the memory blocks with respect of VirtualQueryEx (see http://stackoverflow.com/questions/3010741/how-does-one-use-virtualallocex-do-make-room-for-a-code-cave/3010909#3010909 as an example where I examine the program code. The program data you can examine in the same way).

The most practical problem which I see is that you ask your question in too general way. If you explain more what kind of the data you are looking for I could probably suggest you a better way. For example if you could see the data somewhere you could examine the corresponding windows and controls with respect of Spy++ (a part of Visual Studio Tools). The most important are the class of windows (or controls) and the messages which will be send at the moment when the most interesting window are displayed. You can also use Process Monitor to trace all file and registry access at the time when the windows with the interesting information will be displayed. At least at the beginning you should examine the memory of the process with ReadProcessMemory at the moment when the data which you are looking for are displayed on the window.

If you will have no success in your investigations I'd recommend you to insert in your question more information.

Oleg
+1.. This looks like some promising information.
mpeterson