Flag: Tornado!
Hurricane!
|
|
Topic created on: May 5, 2008 13:58 CDT by sleepster  .
Hello everyone...
I've come across a little bit of a problem and I am not quite sure how to get out of it. I am currently learning IDA Pro, so I decided to start by playing around with it inside of a game. Unfortunately, each time I attach the debugger to the game, I end up in the function: 'ntdll_DbgUiRemoteBreakin'. I used 'stealth' which is the ant-debugger plugin for IDA. Apparently it is supposed to hide the debugger.
I was wondering if someone could help me with this dilemma?
Thanks.
|
Call up the thread list (Debugger menu) and check other threads.
|
> igorsk: Call up the thread list (Debugger menu) and check other threads.
Thanks for the reply. I already checked the other threads though. They also seem to be stuck in some perpetual debug loop as well.
|
|
sorry for the stupid question, but what you excepted? there is nothing wrong to land in NTDLL.DLL after attaching. just set a few breakpoints on the certain functions and run the process. guess, I just don't understand your situation. please, describe your actions step-by-step.
|
I am sorry for not explaining the problem in more detail. Ideally, I would like to break into the program at the actual code. Instead, I am getting stopped by some debugger detector function. If I were to continue stepping through the code, it would keep me in that function forever. It's sort of an infinite loop to deter hackers from easily snooping around the code.
I was hoping for some IDA plugin or some other technique that will fool the ant-debugging code to let me actually see the code.
Thanks
|
attach to notepad and trace the code forever! do you think that notepad detects your debugger and somehow prevents tracing? what the deuce?! of course notepad has no any protection at all!!! so, why you got nothing?! due to the nature of windows-program. they aren't executed like old ms-dos program - there is no "interstate", there is no "broadway", no linear sequence of commands, like in old BASIC or FORTRAN programs. windows-program are event-based and this means: a program receives messages and calls certain handles. tracing gives you nothing, just an infinite loop. in over word: a program doesn't not decides how it has to be executed, but user with her mouse, does! if she does nothing, program does nothing, if she click a button, the appropriate procedure is called.
so, first of all you have to find the certain functions. which ones? depends on... well, what you want to get. for example, you analyze a rootkit and see the function writes somewhat to somewhere. to find out what it is - set the breakpoint and run the process. when breakpoint hints, debugger stops the process and from that moment you can begin tracing.
if you want to know what the program writes on the disk - set breakpoint on WriteFile, if you want to know what the program read form the dialog form - set breakpoint on GetWindowText and... ops, no! GetWindowText isn't your choice! use library functions, recognized by IDA Pro by FLIRT technology. suggest, you analyze Borland stuff, so, set breakpoint on @TControl@GetText$qqrv; TControl::GetText(void) or @System@@LStrCmp$qqrv;System::__linkproc__ LStrCmp(void)
in essence, before attach a debugger to the process you _must_ know what you want to. a typical program spends 99.9% CPU time in the sleep and/or infinitive loops.
p.s. sorry for my bad eng and misprints, I just run out of the time
|
|
Thanks Nezumi. That makes a lot of sense. I will give it a shot :)
|
So, I tried playing with the game a bit more, but I am still stumped.
The game has a concept of 'score' and I thought a good practice would be to learn how to alter the memory location that stores the 'score'. However, in order for me to search through memory to find the memory location and set a hardware breakpoint on that location, I would first need to break somewhere in the code. However, I am not sure what function to set a breakpoint on.
In general, if I am interested in locating a memory location that controls a specific variable in the game (or any program), how would I go about locating this? Is there a systematic approach to doing this? I am using IDA Pro if that helps.
Thanks
|
I thought this is has something to do with scores or ethereal life or ammo. why you didn't tell me that from the beginning? well, to answer you question: as a general rule, scores are stored "as is", I mean: if you have 666 scores, some memory cells keep 9Ah 02h (dec2hex, and remember the byte order, the less significant byte comes first).
you don't need IDA Pro to do that. use any memory dumper. personally, I prefer soft-ice (dumping memory via history; another way to do that is using extensions like IceExt), but there is a lot of dumpers anyway.
ok. check your safety belts, we're blasting off:
1) dump the process when you have the certain score;
2) dump the process again with the same score, but something different (move player to the next place for example, open a door, etc);
3) do something to change the score and dump the process once more;
ok, you have three dumps with two different scores.
1) compare first two dumps to find unmatched bytes - they are definitely not the score (since, first and second dumps have the same score);
2) delete the unmatched bytes out of the dumps;
3) compare first and third dumps to find unmatched bytes - some of them definitely keep the score;
4) find the best candidates for "scores". if you're lucky, you have only one hit equaling to scores, which you got in the game. but quite often you have two or more locations, keeping the scores (or something looks like). some of them - is nothing just false positives (more dumps - less false positives), but some of them are natural "copies" of "original" score. the program can store the score-value in the global variable, passing it to many functions, so you have to find out which one is genuine. it's simple. just change the memory cell with your favorite debugger return to the game. if the score-window doesn't react, you're dealing with "forgery". try the next one. however, score-windows might accept your value, entered in the debugger, leaving the actual score unchanged. this is because of using local copy of original score variable for score-window;
5) ok. you have found the exactly memory location of the original score variable - set hardware breakpoint on access and debugger helps you to discover the code reading or writing it;
6) modify the code as you wish, for example, if it adds 10 points, you might change 10 to 100;
btw, to compare dumps, I wrote quick-n-dirty utility. yeah, it's a very silly tool, so feel free to rewrite it.
// usage: fck.exe dump_1 dump_2 dump_3 ... dump_n
// note: this tool finds the "hot" bytes.
// dump_1 and dump_2 are supposed to have matched "hot"-bytes,
// while the other dumps are supposed to have unmatched "hot"-bytes.
#include <stdio.h>
#define MAX_DUMPS 0x10
main(int c, char **v)
{
int pos=0;
int a,b,flag;
FILE* f[MAX_DUMPS];
unsigned char ch[MAX_DUMPS];
if (c-- < 4) return printf("-err: need more files\n");
for (a=0;a<c;a++)
if (!(f[a]=fopen(v[a+1],"rb")))
return printf("-err: cant open %s\n",v[a+1]);
printf("raw offset");
for (a=1;a<c;a++) printf("\t%s",v[a+1]);
while(1)
{
for(a=0;a<c;a++)
if (!fread(&ch[a],1,1,f[a])) return 0; pos++;
if (ch[0] - ch[1]) continue;
for(a=flag=1;a<c;a++)
for(b=a;b<c;b++)
if ((a-b) && (ch[a]==ch[b])) flag=0;
if (flag)
for (printf("\n%08Xh:",pos-1),a=1;a<c;a++)
printf("\t%02Xh",ch[a]);
} printf("\n");
}
|
|
Thanks a bunch for the help. This is exactly what I need :)
|
|
http://www.woodmann.com/collaborative/tools/index.php/Category:Memory_Data_Tracing_Tools
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}