Log in

View Full Version : Getting the debugger to reveal memory access to a string


5aLIVE
August 19th, 2005, 04:27
I've reached a bit of code which copies a string using :

push 100h
push ebx; source string pointer
push offset byte_2000502C; destination string pointer
call _strcpy

My aim is to find where else this newly created string is read in the program. Being a debugger newbie, it seems logical to set a memory on access BP to find out where else in the code is this string read.
Is this the usual approach?

It only breaks inside _strcpy function, but I know it must be accessed elsewhere at least to copy to a variable before being passed to a function.

Any suggestions greatfully received.
Thanks 5aLIVE.

blabberer
August 19th, 2005, 05:33
select ebx follow in dump right click find referances to selcted address
if it was in analysis olly should show who accessed or is going to access
that area
most probably it should be mov ebx,blah instruction some where above

5aLIVE
August 19th, 2005, 05:44
Hi,

You are quite right, move ebx,eax is used before the strcpy.

I'm wanting to find references to address $2000502C after the copy has completed.

5aLIVE

blabberer
August 19th, 2005, 05:58
2000502c sounds to be a very high address
is your application (dll may be loadd in such a high memory) ??
if it is code olly can sure find referance
if it is virtuall alloced global alloced or malloc or whatever discodance alloced memory then olly doesnt have a chance unless there are hard coded referance (higly unlikely) to that address

you can set a memory access breakpoint or memory write or harware write read execute break points and deal with the breaks case by case

unless i feel the code i cant comment on how to retrieve referance for that address especially after strcpy is done with

may be you could get the analyzethis plugin by joestewart
and force analysis and try using ctrl+r (find ref to selected address)

5aLIVE
August 19th, 2005, 06:19
Oops that's a typo, it should read $0205xxxx, the DLL is relocated to a higher address.

The string in question is a Dynamic Data Exchange object created using the DdeCreatStrinHandle API. So I think It should be possible to find all references.

I'll try using hardware BPs to see if this helps at all.

I appreciate the difficulty of discussing code that you cannot see, let alone run. Would you be willing to look at the code if I am unsuccesfull?

The hole object of this exercise is to identify where the string is passed to a MD5 function. I've found the initialisation of the chaining variables and the rounds function, I would like to identify the message string and the digest.

AS I said before, I am new to this and there are lots of question I need to answer to make progress.

5aLIVE.

blabberer
August 19th, 2005, 09:34
well if it is small wouldnt want to be installed could run well on non admin accounts as well and doesnt have headache antidebugging tricks that would eat more time than the real problem yes i can take a look
provided you dont ask for a time deadline


hey but its easy enough to spot those strings just trace a little if it is malloce it will do a free if it is virtual alloc it will do a virtual free
if it some globalalloc it will do global free
just before tha data vanishes it would be stored some where else
and take on from there all it takes is some concentration

5aLIVE
August 22nd, 2005, 07:50
Thanks for the kind offer and advice.

The software meets nearly all your crieria except for size.
I won't bother you with it now. I'll do some more reading where time permits to get a better understanding of some of the mechanisms in place before reaching for the debugger again.

I've since found the main app references this string to do some checks.
5aLIVE.