Hi,
I would be happy if g-rom, owl or people that already did such a program could help me a little.
I would like to add to my current iat rebuilder some tracing features,
I call a function, giving it the address to start the trace and a mem
address start and end to stop it, the goal is to intercept the exact
address where the traced process lands, but I can't force the process itself to be traced, my program must trace the code by itself...
Do I have to code a device driver on ring 0 ? Is there already made sources available ? TIA

tsehp

did you consider other options as well? eg, initially you may get away with decoding instruction lengths only, recognizing specific instructions, all without actually executing anything. of course i don't know your goals and why you chose the tracer idea, but you may want to give this a try as well. z0mbie.cjb.net has a nice package called LDE for this purpose (e.g. one of the example Hydra plugins in icedump uses it, enough for peshield and some asprotect API obfuscation).



by 'process'/'program' i assume you referred to 'thread' which is the executable 'entity' in win32. now, further interpreting the above (feel free to clarify it yourself btw), what you meant probably is that you don't want to start up the target app but instead want to execute its code somehow in your own process, eg. by loading it somewhere in your process' address space and starting a new thread (under the tracer's control). this is indeed possible and would actually result in what i could best describe as the user mode equivalent of icedump's tracer engine.

what you will have to do is roughly this:

1. implement a state machine like icedump's tracer and have it gain control on each single step exception that will occur in the traced thread. you can achieve this by ensuring that the engine's main entry point is always the first Structured Exception Handler in the traced thread. this means of course additional emulation for code that installs its own SEHs (something i didn't have to bother with in icedump).

2. to use the tracer, you'd create a new thread in suspended state, change its context so that single step exceptions would be enabled in it and by grabbing its FS, you have to install your engine's main entry point as the thread's first SEH (the emulation i mentioned will later ensure that it always remains the first handler thereafter). then you resume the thread and let the tracer carry out its job.

3. terminating the tracer will be easy once you got all the above to work, eg, you can do a simple range check for EIP in your engine's main function (which gets called on each single step exception), much like icedump's tracer does it.

now, having said all this, let me address a few points. first of all, this is a very interesting project with lots of potential, i beleive you didn't fully realize it when you asked your question ;-). one advantage of it would be that it would work under both win9x and NT as it would be pure user mode code. the drawback of it will be of course its speed, you can expect it to be between 10-100 times slower than icedump's tracer. this is not a tragedy per se, as long as you don't want to trace hundred million instructions ;-). so, my suggestion is that you study and understand how icedump's tracer works (at least the state machine part, how it interfaces to the win9x kernel or softice is less important for now), then implement it in c++. i will be available for help but don't expect me to do it for you, simply no time for this undertaking (you can expect to spend a 'man-week' or two to get all this to work).

thanks owl for your reply, I have previously seen the icedump's sources, sound a little complicated for me at first glance, but tha'ts ok.
My purpose is to fix the modified IT's by asprotect (and other's) scheme.
I first look at all the good api's addresses and remove them from test.
Then the bad adresses are traced, and I just look where they land into
all the addresses belonging to all the modules loaded by the app, then
we rebuild the iat. I'll check the site you told me and report of my progress.
Thanks a lot !

Tsehp

hi artha,
thanks also for your reply, I think your way will be much more easy to handle for me. Icedump's powerful tracing features are good when you go live debugging, but my app just wants to trace the asprotected application. I have anyway two big problems :
1-I can't use the app's thread context and trace it, I could find it's
first encrypted/redirected thunk, but it will crash just after.
2-If I use nasm disass to scan every thunk, I could find redirected jumps but If I encounter a decrypting scheme, that's gonna be more than difficult.

I have to finish pretty soon the easy iat rebuilding part of my app, then I'll start the tracing part, I'll tell you about my progress.
best regards,

tsehp

In his reply to ur question, Owl suggested at first u use a LDE (Length Decoder Engine) for opcodes. Tracing wrapper and so on is a nice idea/concept BUT if u don't have a powerfull emulator/tracer you will get detected/fucked at some stage. Trust me I know of what I am talking about .

WIN32 API system is easy to use, however highly detectable and fucking SLOW. So would be a step by step with a SEH... now up to you to know how reliable and fast u wanna be... and if it is worth the job .

Cheers,
G-RoM

ok, considering all the answers I had for my project, no doubt, I have to work at the deepest level possible. I don't want to code something to scan for special opcodes like redirecting jumps and anything depending of the protection scheme, this could be easily defeated in the future
So , I load and start the target into my tracer's mem context, setting
the seh to it's main entry point (owl's option), but I don't want to use
it's entry point, only the iat's redirected/encrypted adress points I have to trace. I put on the single step mode, and check if the eip belongs to every possible addresses I have to fix (dependant module's
exports), and when this occurs, they are logged and fixed inside the target's iat. Teh target's thread will crash after going into the api export, what can I use to fix this ? A general exception handler to get back into my tracer and fix the next iat entry ?
TIA,

tsehp

> In this example my code only retrieves
> few handles (the dll's handle) so that I can
> use WriteProcessMemory() on it.
> Why not using GetModuleHandle() you
> could say ? Because GetModuleHandle()
> only works for the current Process.

You can retrieve module handles without
injecting code with ToolHelp functions, see
PSDK's GetProcessModule() code.

S.

I may add u can use too PSAPI (NT), and may be VirtualQueryEx . And this is only to get a modulehandle from a foreign context.

There are several way to do in memory context patching without r0... some are however OS dependant (9x have bunch of shit non swappable).

I will never need a tutorial on how to do a thing linked with memory context patching and especially in C++... And frankly I never used and trusted tutorials : I try, debug, and so on which is lots more educationnal. Spreading knowledge with tutors is not always alright imho.

Cheers,
G-RoM

I mean several things :

- Some "tutors" are full of bullshit.
- Some people use them as a tv guide... they don't think they just apply.
- Some tutors are inacurrate and can introduce bad habits.

Hence some tutors shouldn't exist as they are not helping at all or even confusing people... And some people shouldn't have access to them since after they think they know something and create more tutors that are full of bullshit.

I tend to go to the method which give advices/hints/informations but NEVER a fully detailed solution coz this is too easy and people forget to use their brains. Discovered knowledge will always remains... especially if it was hard to get .

This is my opinion, may be some people thinks like me, some will say I am an "elitist" or even someone who don't want to share knowledge. In fact, I just want to have people with brains because I tend to think more people and more people forget what it is.

Cheers,
G-RoM

Hi artha (and others) I've been very busy finishing the first part of my iat rebuilder, it's almost finish now and I will soon add it the tracing features. Artha, you're talking about using nasm to disassemble the target, to see where it goes, starting from it's iat. I'm just afraid of one thing : encryption and very long routines if some protecting wrappers redirects the addresses into itself, I didn't had the time to
see how imhotep works but understood that you use disassembling.
My purpose is to be able to trace the program, just like you do in softice : you force the target to jump at the iat address and put a bpr
on himem, just to see where it goes, then you have the api entry, and deduce it's name and module. I don't know if you can solve this problem with encapsulating nasm and using it but g-rom's solution seems much complicated to implement but surely closer to the result I have to get, maybe you have another solution to what he used inside
icedump.
I'll be back soon when I'll get into this coding part, best regards,

Tsehp

Ok the beta is finished, now the real work begins, it's gonna take some time and I want to be sure to choose the right option.

1-Using a lde, disassembling every iat address not resolved could solve
easily some simple code, like redirect jumps, but when you meet a decryptor that leads you to the api export, it's very hard to program and too much dependent of asprotect coding

2-Using a tracer, I force the protected app to visit every iat not resolved, it finally lands into the api export and could crash before/after this point, do I have to implement another SEH to go back
and trace the other unresolved iat's ? I have to try the icedump's tracer to see if it solve this in another way...

3-last idea : log every api export call while it's coming from the target,
I can redirect every api export from every module depending from the target, test the caller and relink the iat while looking at the caller's origin, the drawback is that you have to use the program while it's logged, hoping that all the imports will be called and logged.

I just don't know at this point if someone have an original idea about this, just asking.

regards,

Tsehp