Finding a variable in a non managed running executable's memory space.

  • Thread starter Thread starter garyusenet
  • Start date Start date
G

garyusenet

Some time ago I enquired about how I interface with a program written
in an old version of C++

Any terms i use like list that follow are used in their common everyday
usuage!

One of the programmes features is that it displays a list. The contents
of this list are the names of people that are logged into the
programme.

I am writing a programme in C# which will extract this data from the
programme, and allow me to query the list. I must stress I have no
access to any libraries etc.. that the program may/may not have been
written with. I have no documentation. All i have is a running exe
programme. That functions fine in itself.

So. From my investigations to date I have figured that I will need to
use P/Invoke with the kernel32.dll's memory functions to read the
memory. The problem is I don't know where to look in the memory. I have
been told that the address in memory i am after is likely to be a
'fourth level' pointer. But I do not know what this means very well.

Could someone explain how I should best tackle this problem please.

Thankyou,

Gary-
 
Basically you can have pointers that point at pointers. One use for
this as an example is on the old 68x mac's. Coding in C++ using the OS
meant using handles, which are pointers to pointers. The idea being the
OS can move resources around memory to keep things tidy, you just worry
about the handle.
So a fourth level pointer would suggest you'll have a pointer to a
pointer to a pointer to a pointer...
What you'd need to do is get the address of the first pointer and find
out where it points and follow the chain. As for how you find the
pointer. My suggestion would be to use a debugger to pause it with one
user logged on (so it's the first item in the list) and then search for
any address which contains that address. Repeat until you can't get any
further back.
The chances are they've used a linked list, possibly of user objects,
which may contain further objects like an indentity object that
contains the name.
A linked list in case you don't know is a data structure where you have
an item object (or struct) which contains a pointer to the next object
in the list. The last object contains null in the pointer to the next
element. For added complexity, remember what I said about handles on
the mac's? Each node could hold a handle to the next node, although I
think it's fairly unlikely.
This is relevant as it may be a doubly linked list where each node
contains a pointer both to the next object and the previous object. In
that situation the head end will be the one where something points at
one of the two nodes with null in one of the two pointers. You should
be able to figure out where you because the data is layed out
sequentially so you can spot patterns.

That's a real brief overview and abstracts away a lot of the
complexity, but I hope it helps a little.
 
Thankyou for that, can you tell me.

Can you tell me would you expect me to find the users name if i
searched the memory for it in plain text, or is it likely to be in some
other form?

If it's likely to be in some other form, do you know which you would
guess it to be in?

Thanks,

Gary-
 
One of the programmes features is that it displays a list. The contents
of this list are the names of people that are logged into the
programme.

I think you'll find it easiest to hook into the program's display
routines. Is it a console program? -- then just redirect its stdin and
stdout. Is it a windows program that displays lin a listbox? -- then
disassemble it and search for a call to SendMessage/LB_ADDSTRING. Does
it display the list in a normal window? -- then disassembl and search
for a call to DrawText.

My instinct would be to use a modified executable where you've
rewritten some bytes of assembly code around this call. Or your
program could invoke the program as a debugger and set a breakpoint
there (I don't know what the implications are of this).

Or you could make your own "shim" dll, so that when the program
attempts to invoke DrawText it instead invokes the DrawText inside
your own shim dll. Your dll will call the normal win32 DrawText, but
it will also tell your program what the value was.

Or you can use this point just as the starting poiint for debugging.
Well, more like the "ending point" for debugging, because you'll be
trying to figure out how the program GOT TO this DrawText point,
working backwards, to figure out the chain of pointers.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top