Code Injection

Hi All,

I am chasing a bit of advice in regards to code injection, so any help appreciated

to find a spot to inject my code is it
(image base + virtual offset + virtual size)
so if
Image base = 00400000
Virtual offset = 1000
and virtual size = c7000
does that mean I can inject my code into
004C8000

when I am looking at this address
I appears to have code allready there,
is it real code or Junk code that can be over written

when I modify this area the program tends to fall over after executing my code



Many thanks

R@dier

If you wanna Inject your Code at Runtime,yes... But..

Its very uncommon that after a Section (here Code one) comes JunkData..Prolly a new Section starts wich is needed to run the Exe proper..

You could go and check for some Space to inject Stuff after the Section Infos -> Start of first Section...

Or maybe smash your Code into 0 Bytes of the last Section (if there are any)...

You will have to set correct flags with VirtualProtect,otherwise u will prolly fail at your Attemp...

Can you explain a bit more what you wanna inject,and how do u call your injected Code etc.?

Probably easier to sort the Problem then

Cheers

Hi
I was trying to turn the program into its own keygen
I ended up getting it sorted by over writting another area that was not critical to the key generation.

it worked great, the only problem now is the loader I am using
(abel's loader generator)
falls over while patching the code.

the code I have injected works fine in olly but when I use the loader the loader falls over. (loader failed.. process write error)

the loader waits for the reg screen before patching, by this stage the program is unpacked (Aspack2.12).

here is the code I am injecting,
004550A4 60 PUSHAD ;save registers <---new code stats here
004550A5 8BF2 MOV ESI,EDX ; move serial
004550A7 BF B0F31200 MOV EDI,12F3B0 ; store generated serial here
004550AC B9 09000000 MOV ECX,9 ; length of serial to write
004550B1 F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[> ;write new bytes
004550B3 61 POPAD ;restore registers
004550B4 83C4 04 ADD ESP,4 ; <--- moved from original jump
004550B7 33C9 XOR ECX,ECX ;<----" "
004550B9 ^E9 8D1AFEFF JMP prog32.00436B4B ; <--- jump back to where we began
004550BE 90 NOP

00436B3C |. 8D5424 10 LEA EDX,DWORD PTR SS:[ESP+10]
00436B40 |. 52 PUSH EDX
00436B41 |. E8 B7FC0700 CALL prog32.004B67FD
00436B46 E9 59E50100 JMP prog32.004550A4 ;<--- jump to injected code
00436B4B |. 3BE8 CMP EBP,EAX
00436B4D |. 5F POP EDI

00455221 . 68 00DF4F00 PUSH prog32.004FDF00
00455226 68 B0F31200 PUSH 12F3B0 ; <---- changed to push new serial
0045522B . 50 PUSH EAX
0045522C .^EB 9C JMP SHORT prog32.004551CA

The Idea was to use the loader to turn the program into a keygen,
write the serial down. then use the program with new serial
no need for the loader

any ideas about getting a loader to do the work?

R@dier

If it works in Ollydebug its probably a Loader Issue.
I think Yoda did some nice Aspack Unpackers,or unpack it by Hand and inject your Code then...Probably easier than using a Loader.. I never used,saw a Loader Generator so I in generally cannot mind what fails...

Unpack/Inject your Code in the plain Data should be probably a better Way.

Thanx [NtSC],

I originally unpacked it by hand, to see how it worked,
the changes I made I don't want to be permanent, just to turn this proggy into a keygen for a while, thus the loader

I had success doing this to a neolite packed proggy so I was hoping to do the same to this one.

Thanks for your help

R@dier

NP ;-)

A good Solution would be coding an own Loader that breaks when the Exe is unpacked and goes then to inject your Changes...
R3 Functions like - CreateProcess,Set/GetThreadContext,Write/ReadProcessMemory will be enough for this.

This Way you can make sure you patch it right after the Data is unpacked, at some secure Point you catch and hold in the Unpack-Routine.

I have put some Unpackers with Sources on my Page,maybe they help you getting up a bit into it.

xxx.cstn.cjb.net

Cheers

[NtSC],

Thanks again for your help and your site
I think your sugestions and the source code will be very helpfull.


Cheers

R@dier

@[NtSC],

Thanks for your sugestions,
it was a great learning experience
my loader works a treat and only 2.5k in size


R@dier

As I told u ;-)

Hello,

I have a similar need ... the only thing is that in order to turn the application in its own serial generator I'd need to be able to patch the target application as soon as it is unpacked.
How could this be accomplished? I mean, being able to catch the moment the application is completely unpacked. It has been suggested to intercept some API call near the serial generation routine. I was wondering if there are alternative approaches.


yaa

Depends on the Packer/Crypter you wanna intercept.
If there is not much poly decryption i would suggest to code some basic r3 Loader that sets some small Breakpoints,...

If too much junk and poly i would suggest to hook an Api-Function near the Place you wanna intercept..

I think i saw you posting on an other Forum aswell.. If you want to do an Asprotect Patcher/Loader (I think i remind that from the Forum i saw u posting), I can tell you Global and me did our Asload just with Ring3 Routines (Read/Write ProcessMemory etc.) and some scanning ofcourse,but no Apihook needed at all.

I did a post on RCE Messageboard. It is an aspack protected application not an asprotected one. The problem is that the application generates the correct regcode at startup (after having requested a name and regcode the application requires to be restarted). Apart this specific need I'd love to undestand how in general it is possible (if it is indeed possible) to stop an application as soon as it has been completely unpacked.
Could placing a breakpoint on the statement just before the OEP be a good general solution?

yaa

Hummm--

*** I'd love to undestand how in general it is possible (if it is indeed possible) to stop an application as soon as it has been completely unpacked.
Could placing a breakpoint on the statement just before the OEP be a good general solution? ***

Yes... You could code an R3 Tool that loads the App.. Then you have to search for Signatures you can set Breakpoints on,and hangle down this locations until you catch a Point were the Application is unpacked.

Placing a Breakpoint on the Statement before the real OEP is indeed the Way to go..

Else you could hook some Api that gets called before the real OEP is executed...

As i already told Radier before,play with some examples..
Its not that much Voodoo as u think off it ;-)

Hi Guys,

another approach you can try
is using WaitForInputIdle this should halt your process which will inject the code untill the target program has become unpacked.

It will kinda synchronise the loader/code injector with the target program

you can then if you wish throw in a Bp after the WaitForInputIdle

it would probably be a good idea to check for some bytes to make sure it is really unpacked with ReadProcessMemory

for a full description read the win32 SDK reference manual




DWORD WaitForInputIdle(

HANDLE hProcess, // handle to process
DWORD dwMilliseconds // time-out interval in milliseconds
);



The WaitForInputIdle function enables a thread to suspend its execution until a specified process has finished its initialization and is waiting for user input with no input pending.

--> thus once unpacked and waiting for input your code injector routine will then execute

I hope this helps

Best Wishes
R@dier

R@dier, WaitForInputIdle is what most loaders I've seen use.
Unfortunately my need is different. I can't let the application load itself for the regnumber generation is done during loading .... while the WaitForInputIdle API would "fire" when the application has finished the loading and is awaiting user input. What I need is then to somehow intercept the "application completely unpacked" event, patch the application in memory and then let it run normally.

yaa