ResHacker project

[trancexx]

thank you for your reply but my need is a bit different, i just want to know that which section contain IMAGE_SCN_CNT_CODE,

anyways i got the code from Code Project

VC:
if( pSectionHeader->VirtualAddress <= dwEntryPoint &&
    dwEntryPoint < pSectionHeader->VirtualAddress +
                     pSectionHeader->Misc.VirtualSize )
{ break; }

AutoIt :
Local $VA = DllStructGetData($tIMAGE_SECTION_HEADER, "VirtualAddress")
Local $VSZ = DllStructGetData($tIMAGE_SECTION_HEADER, "UnionOfData")
Local $AddressOfEntryPoint = DllStructGetData($tIMAGE_OPTIONAL_HEADER, "AddressOfEntryPoint")
If ($VA <= $AddressOfEntryPoint) And $AddressOfEntryPoint < ($VA+$VSZ) Then
   ConsoleWrite("Execution Starts at SEC# "&$i&" :"&$Section&@CRLF)
EndIf

Nice one. I like that.

[monoceres]

I want more! I've been using this as a general pe-explorer for a while now (since I realized it could) and since I know you're an expert with these files I expect more cool functions

[corgano]

I want more! I've been using this as a general pe-explorer for a while now (since I realized it could) and since I know you're an expert with these files I expect more cool functions

Me too! Can't wait for modifying / compileing EXE files to come....

[monoceres]

Do you accept feature requests?

[trancexx]

Sure.

What do you have in mind?

[monoceres]

I was thinking of some IAT adding/modifying capabilities.

Oh and some x64 support would be nice

[trancexx]

I was thinking of some IAT adding/modifying capabilities.

Oh and some x64 support would be nice

So that custom dll could be plugged-in for example, or to make a ground point for native exe compressor?

I think it would be hard to keep the validity of the modified app. It shouldn't be difficult to actually add new function, but other sly modifications - that could be tricky.

Clear goal and necessary discussion on the subject is needed.

As for 64 bit support. I have limited access to 64-bit systems. This fact makes me unsuitable for the job. But I guess I could add some more support for 64-bit modules to _PopulateMiscTreeView() function.

[monoceres]

My thinking is this:

I like to add/correct functionality on apps running on my system. Do to this I usually inject dll's into them during runtime.

However this requires an extra exe running and waiting for the process to exist and then injecting it. I would much rather be able to just modify the IAT on the target exe so my dll get's loaded during target exe's startup.

[trancexx]

My thinking is this:

I like to add/correct functionality on apps running on my system. Do to this I usually inject dll's into them during runtime.

However this requires an extra exe running and waiting for the process to exist and then injecting it. I would much rather be able to just modify the IAT on the target exe so my dll get's loaded during target exe's startup.

So, let's say this happens...

I compile AutoIt script. This new app will import different functions from different dlls.

Two of them will be CopyFileW and MoveFileW.

My compiled script uses this code:

FileCopy("FullPathToSomething", @DesktopDir)

If I run it what would happen? It will copy something to @DesktopDir.

But what would happen if I would manipulate IAT and replace CopyFileW with MoveFileW? One thing is sure, my app would import two MoveFileW functions from kernel32.dll.

Will the code copy or move that "FullPathToSomething" to @DesktopDir afterwards?

I'm gonna speculate and say later would happen.

What if I have MyApp.exe that imports "X", "Y", "Z" functions from user32.dll. What if I make user33.dll and export "X", "Y" and "Z" functions from it. What if "X" and "Y" functions are just redirections to "X" and "Y" from user32.dll and "Z" is my function (the way I like it). What if I simply replace name "user32.dll" from IAT of MyApp.exe with "user33.dll" and place my user33.dll where it should be placed for windows to find it when loading MyApp.exe. Would that work? What do you think?

[monoceres]

So, let's say this happens...

I compile AutoIt script. This new app will import different functions from different dlls.

Two of them will be CopyFileW and MoveFileW.

My compiled script uses this code:

FileCopy("FullPathToSomething", @DesktopDir)

If I run it what would happen? It will copy something to @DesktopDir.

But what would happen if I would manipulate IAT and replace CopyFileW with MoveFileW? One thing is sure, my app would import two MoveFileW functions from kernel32.dll.

Will the code copy or move that "FullPathToSomething" to @DesktopDir afterwards?

I'm gonna speculate and say later would happen.

Strictly speaking it would crast since MoveFile and CopyFile doesn't have the same amount of paramaters. But in theory I would say that the would be moved (unless MoveFile is using CopyFile and we get an internal unbreakable eternal loop, but that's irrelevant.)

What if I have MyApp.exe that imports "X", "Y", "Z" functions from user32.dll. What if I make user33.dll and export "X", "Y" and "Z" functions from it. What if "X" and "Y" functions are just redirections to "X" and "Y" from user32.dll and "Z" is my function (the way I like it). What if I simply replace name "user32.dll" from IAT of MyApp.exe with "user33.dll" and place my user33.dll where it should be placed for windows to find it when loading MyApp.exe. Would that work? What do you think?

It would be some kind of API hooking (but your example could provide a lot of difficulties since user32 is a pretty essential part of windows, it could screw up pretty bad). But yes, I think it would work. I mean, the IAT is just a table of addresses and functions. Editing it before execution shouldn't be much different from editing it during runtime (which I know you know I have done before).

[trancexx]

Strictly speaking it would crast since MoveFile and CopyFile doesn't have the same amount of paramaters. But in theory I would say that the would be moved (unless MoveFile is using CopyFile and we get an internal unbreakable eternal loop, but that's irrelevant.)

No it wouldn't crash because MoveFileW takes two parameters and CopyFileW three. That means that MoveFileW will take what it needs from the stack leaving else. This is ok. Opposite situation could lead to a crash.

Let's take this code:

If $CmdLine[0] = 1 Then
    If StringRight($CmdLine[1], 4) = ".au3" Then
        Run('"' & @AutoItExe & '" /AutoIt3ExecuteScript "' & $CmdLine[1] & '"')
    EndIf
EndIf

After compilation, to run some script with it we need to drop it on that exe.

If I write some new script (on the desktop) that goes like this:

DirCreate(@DesktopDir & "\SomeNewFolder")
FileCopy(@ScriptFullPath, @DesktopDir & "\SomeNewFolder")

If MsgBox(262144 + 32 + 4, "Copy or Move?", "Is " & StringRegExpReplace(@ScriptFullPath, ".*\\", "") & " on your deskop now?") = 7 Then
    MsgBox(262144 + 64, "Great", "All works well.")
Else
    MsgBox(262144 + 64, "Failure", "Described idea sucs! Not working.")
    DirRemove(@DesktopDir & "\SomeNewFolder", 1)
EndIf

... and drop it on previously compiled one there would be "Failure" scenario happening.

But if I make described intervention and update IAT of my app afterward, there should be "All works well." box displayed.

Unfortunately I'm not able to attach that exe (no more available space), but take my word for it - it works.

It would be some kind of API hooking (but your example could provide a lot of difficulties since user32 is a pretty essential part of windows, it could screw up pretty bad). But yes, I think it would work. I mean, the IAT is just a table of addresses and functions. Editing it before execution shouldn't be much different from editing it during runtime (which I know you know I have done before).

I'm not touching user32.dll.

Just changing reliance of MyApp.exe from user32.dll to user33.dll (one byte change).

Edited September 4, 2009 by trancexx

[monoceres]

Not sure where you're going here, but yeah, you're pretty much describing the behavior I want. Adding/Changing an exe's dependencies.

[trancexx]

I'll make separate script for testing purposes to do that. Changing first, adding maybe later.

...will see how that works.

[trancexx]

Ok, I have something.

There are few limitations. Some are deliberate, some not.

Try to brake it.

... just wait till I delete some attachment so I can upload this one.

edit:

IATManipulate.au3

Edited September 7, 2009 by trancexx

[monoceres]

Working very well (as expected)!

My test:

Created an exe that displayed a profanity in a MessageBox.

Created an dll that exported a function that redirected to MessageBoxW but added a check for profanities before redirection.

Used your script to change the IAT of the exe to point to my dll and exported function.

Saved the modified exe as a new file.

Ran it and success

Test files included.

http://monoceres.se/Uploads/test_iat_mod.zip

[ptrex]

@all

Maybe this is of any interest to you guys.

http://sandsprite.com/CodeStuff/IAT_Hooking.html

Rgds

ptrex

[Digisoul]

Ok, I have something.

There are few limitations. Some are by deliberate, some not.

Try to brake it.

... just wait till I delete some attachment so I can upload this one.

edit:

IATManipulate.au3

Nice Work trancexx. its Awesome

[MisterD]

Looks very good trancexx!!

;o

[trancexx]

Working very well (as expected)!

My test:

Created an exe that displayed a profanity in a MessageBox.

Created an dll that exported a function that redirected to MessageBoxW but added a check for profanities before redirection.

Used your script to change the IAT of the exe to point to my dll and exported function.

Saved the modified exe as a new file.

Ran it and success

Test files included.

http://monoceres.se/Uploads/test_iat_mod.zip

Good.

Profanities are really fucked up now.

[corgano]

Will this be added into the next release of this?