Log in

View Full Version : Some problem with my simple import protector


Hero
February 28th, 2005, 09:45
Hi all
I have been witten an small import protector for some training,but I got an strange
problem in it.My algorithm is following:
I simply inject some codes in program that cause all of import table is retranslated
to use of LoadLibrary,GetProcAddress,FreeLibrary.
My problem is that when I protect the import table of an application that has no message
translation loop(for example a simple MessageBoxA in masm32) it runs normaly,but
when I protect a program that has an messge loop it get terminated with error code 80h
(ERROR_WAIT_NO_CHILDREN).
Do you know why this will happen?I can't solve it myself.
In addtion I attached to small programs and protected one to see.

sincerely yours

blabberer
February 28th, 2005, 10:34
i dunno a quick look shows you are probably giving wrong hInstance to CreateWindowExA()



0012FF4C 004010A3 /CALL to CreateWindowExA from popup_pr.0040109E
0012FF50 00000388 |ExtStyle = WS_EX_TOPMOST|WS_EX_TOOLWINDOW|WS_EX_WINDOWEDGE|WS_EX_CLIENTEDGE
0012FF54 0040106D |Class = "LISTBOX"
0012FF58 00403000 |WindowName = "Popup ListBox"
0012FF5C 00EF1140 |Style = WS_OVERLAPPED|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_VSCROLL|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION|1140
0012FF60 BA558190 |X = BA558190 (-1168801392.)
0012FF64 0000012C |Y = 12C (300.)
0012FF68 8B550000 |Width = 8B550000 (-1957363712.)
0012FF6C 00000000 |Height = 0
0012FF70 00000000 |hParent = NULL
0012FF74 00000000 |hMenu = NULL
0012FF78 43EDCC00 |hInst = 43EDCC00
0012FF7C 00000000 \lParam = NULL


can you give more specifically what problem ?? did you try using ollydbg with
as your just in time debugger to catch the exception and look at call stack ??

further down it you try to SendMessage() this
[/CODE]
0012FF6C 004010D6 /CALL to SendMessageA from popup_pr.004010D1
0012FF70 0009026C |hWnd = 9026C
0012FF74 00000030 |Message = WM_SETFONT
0012FF78 018A0028 |hFont = 018A0028 (font)
0012FF7C 00000000 \Redraw = 0
[/CODE]

which selects object here


0012FDC0 77E2B753 /CALL to SelectObject from USER32.77E2B751
0012FDC4 01010057 |hDC = 01010057
0012FDC8 018A0028 \hObject = 018A0028 (font)


after this it returns here and crashes when returning



004012D1 |. E8 20000000 CALL popup_pr.004012F6
004012D6 |. C9 LEAVE
004012D7 \. C2 1000 RETN 10



and this code is one of your callback code

Hero
February 28th, 2005, 11:59
Hi blabberer
Thanks for quick reply.
Quote:
you are probably giving wrong hInstance to CreateWindowExA()

I didn't think that I made hInstance wrong,because the sequence that I use for push and pop
data to stack is identical,and hInstance will be saved to memory and I didn't do anything in
memory.
You exactly see what I found:
Quote:
did you try using ollydbg with
as your just in time debugger to catch the exception and look at call stack ??

You mean this problem is from a part of my code injection that cause CreateWindowExA()
failed and there is nothing for hdc in next sentences?

sincerely yours

Kayaker
February 28th, 2005, 14:32
Hi

I'm curious where you get the ERROR_WAIT_NO_CHILDREN termination message. If I run the file on XP, it dies after the first CallWindowProcA, the problem being that the ret ESP is invalid, a simple stack crash.

It occurs here:

.text:004012BF push [ebp+arg_C]
.text:004012C2 push [ebp+arg_8]
.text:004012C5 push [ebp+arg_4]
.text:004012C8 push [ebp+arg_0]
.text:004012CB push dword_40301A
.text:004012D1 call sub_4012F6
.text:004012D6 leave stack not restored correctly
.text:004012D7 retn 10h faulty return handled by KiUserExceptionDispatcher
.text:004012D7 sub_40129E endp

Using an API monitor, the code that leads up to this is:

004010D1:SendMessageA(HWND:0041029A,DWORD:00000030,DWORD:018A0028,DWORD:00000000)
0040414A: LoadLibraryA(LPSTR:004043ED:"USER32.dll"
0040414A: LoadLibraryA = 77D40000
00404162: GetProcAddress(HANDLE:77D40000,LPSTR:004043F8:"CallWindowProcA"
00404162: GetProcAddress = 77D45F5A
00404169: FreeLibrary(HANDLE:77D40000)
00404169: FreeLibrary = 1
004012D1: CallWindowProcA(LPDATA:77D632BC,HWND:0041029A,DWORD:00000030,DWORD:018A0028,DWORD:00000000)
004012D6: CallWindowProcA = 0
same thing, all roads lead to KiUserExceptionDispatcher

I wonder if this is one and the same problem, or a different issue entirely?

Kayaker

CoDe_InSiDe
February 28th, 2005, 18:14
Hi Hero (And the others),

Hmm, none of those "protected" files run on my system (Win2K SP4)
And I know why...

In those protected files you've added you're own Import Table which imports 3 API's from "KERNEL32.DLL".

Now when I run the file "test_protected_no_problem.exe" (Which displays a MessageBox from "USER32.DLL", you're injected code loads the library "USER32.DLL" with LoadLibraryA, then gets the address of MessageBoxA with GetProcAddress, and THEN it frees the library "USER32.DLL" with FreeLibrary...
This results in an exception because the address of MessageBoxA isn't valid anymore because you freed the library "USER32.DLL" (Which wasn't loaded by the Import Table).

Although I don't know why you all don't have this problem?
The same problem happens offcourse with the file "popup_protected_problem.exe"...

Regards,

CoDe_InSiDe

Kayaker
February 28th, 2005, 20:12
CoDe_InSiDe might be correct about freeing User32.dll too early. The reason may be in the use of SendMessageA to execute window procedures, SendMessageA does not return until the window procedure has processed the message (WM_FONT, LB_ADDSTRING, ...). However, you do use FreeLibrary on USER32 before SendMessage has been allowed to return. Likely a similar problem with MessageBoxA which waits for user input.

Code:

If you look at the working app with the unaltered imports,
note how CallWindowProcA is a "child" of SendMessageA
DWORD:00000030 = WM_FONT

004010D1:SendMessageA(HWND:000501D4, DWORD:00000030, DWORD:018A0028,DWORD:00000000)
004012D1: CallWindowProcA(LPDATA:77E24506,HWND:000501D4,DWORD:00000030,
DWORD:018A0028,DWORD:00000000)
004012D6: CallWindowProcA = 0 (POPUP.EXE)
004010D6:SendMessageA = 0 (POPUP.EXE) ; return from SendMessageA


And your "protected" version,

004010D1:SendMessageA(HWND:000F0142,DWORD:00000030,DWORD:018A0028,DWORD:00000000)
0040414A: LoadLibraryA(LPSTR:004043ED:"USER32.dll"
0040414A: LoadLibraryA = 77E10000 (ppp.exe)
00404162: GetProcAddress(HANDLE:77E10000,LPSTR:004043F8:"CallWindowProcA"
00404162: GetProcAddress = 77E15349 (ppp.exe)
00404169: FreeLibrary(HANDLE:77E10000) ; WHOOPS, TOO EARLY?
00404169: FreeLibrary = 1 (ppp.exe)
004012D6: CallWindowProcA(LPDATA:77E24506,HWND:000F0142,DWORD:00000030,
DWORD:018A0028,DWORD:00000000)
004012D6: CallWindowProcA = 0 (ppp.exe)
CRASH OCCURS HERE ON XP & 2K


Since there's no way around using SendMessage with a listbox and LB_ADDSTRING for example, you may need to modify your code not to FreeLibrary until all your initialization code etc. is completed, anywhere this may be a problem. This includes your ShowWindow and UpdateWindow calls which also wrap around CallWindowProcA calls.

I can't *directly* tie this to User32.dll being freed too early, but I always get the same stack error on the first CallWindowProcA call executed, so something in there isn't correct.

Cheers,
Kayaker

nikolatesla20
February 28th, 2005, 22:01
Why exactly do you wish to free the library anyway, it needs to be there. Don't free it !

-nt20

doug
February 28th, 2005, 23:04
Quote:
[Originally Posted by CoDe_InSiDe]
Although I don't know why you all don't have this problem?

The library gets freed when its reference count gets to zero. I suppose you have a very tight machine with few extras added? Or maybe windows XP just loads more dlls that depend on USER32, by default.

In any case, it is a bug in Hero's code ;-)

Hero
March 1st, 2005, 00:34
Hi all
First of all I should say that I found a bug in my code that cause protected popup
is not running(it was simple,I forget to push and pop EBP and that cause problem),
and now my program is running for this target,But still some other target are not
working.
Quote:
Why exactly do you wish to free the library anyway

I should do something for memory allocation and should freed somewhere.
But I get what you mean,If I free it it cause problem.
But I still don't know why test_protected_no_problem.exe is working with no problem
on my computer,But on your computer it make some trouble(mine is XP).

In addtion,Is it correct that I say sending parameters to APIs are all from its parameters
(In the other word by using stack) and the value of global register has no effect on
running an API?

sincerely yours

blabberer
March 1st, 2005, 05:58
well there are lot of replies till now and as i posted it was crashing on CallWindowProc
return wher the stack is no balenced again (at that leave retn 10 )

so i quickly hacked it to correct the ebp yesterday and tried to run it it runs without problem in w2k sp4 ( but wait it is not showing up but it shows up as running in task manager and inside ollydbg it is again running but not showing up

here is the hack i did yesterday

Code:


redirected from
004012D1 /E9 76000000 JMP <popup_pr.hack>


0040134C <popup_hack.>/> \E8 A5FFFFFF CALL popup_pr.004012F6
00401351 |. 8BEC MOV EBP, ESP
00401353 \.^ EB 81 JMP SHORT popup_pr.004012D6



here is the log window details

Code:

Log data
Address Message
00404160 COND: GetModuleHandleA
00404160 COND: GetCommandLineA
77E10000 Module C:\WINNT\system32\USER32.dll
77F40000 Module C:\WINNT\system32\GDI32.DLL
75E60000 Module C:\WINNT\System32\IMM32.DLL
77DB0000 Module C:\WINNT\system32\ADVAPI32.DLL
00404160 COND: GetSystemMetrics
00404160 COND: GetSystemMetrics
00404160 COND: CreateWindowExA
00404160 COND: SetWindowLongA
00404160 COND: GetStockObject
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: SendMessageA
00404160 COND: CallWindowProcA
00404160 COND: ShowWindow
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: CallWindowProcA
00404160 COND: UpdateWindow
00404160 COND: GetMessageA


to kayaker
is using FreeLibrary work if there is only one count ??
that is the after the first time it is loaded and before being unloaded
it will call DllEntryPoint to denote detach and it can fail if the resources that it allocated arent deallocated and the FreeLibrary will actually not Free the Library
i think any way i tried to FreeLibrary some time back when working with a malware dll that got loaded into explorer i couldnt free it
yeah i tried diamond softwares apm (advanced process manger which claimed it could
unload any module and it failed and then i had to code some hacks to look why some thing fails
other wise one can use FreeLibrary() at the Start of code and and unload all dlls
that are loaded isnt it ?? it didnt work when i tried it what do you think any comments insights appreciated

Kayaker
March 1st, 2005, 23:09
Hi

I'm not too sure of the question blabberer (or the answer), but you can get some clue to the internals of FreeLibrary and its reference count check as doug mentions, by disassembling with symbols, ntdll!_LdrUnloadDll. There is further description of the module reference count procedure LdrpUpdateLoadCount, in:

What Goes On Inside Windows 2000: Solving the Mysteries of the Loader
Russ Osterlund
http://msdn.microsoft.com/msdnmag/issues/02/03/default.aspx

Quote:

If you take stock of what you have seen and learned so far, you will realize that the first three parts in LdrpLoadDll's processing have been completed. The last part of LdrpLoadDll to explore involves an update to module reference counts. That is the job for LdrpUpdateLoadCount.
LdrpUpdateLoadCount is a dual-purpose routine; it is called when the DLL is both loading and unloading. It attempts to walk either the Bound Imports table or the Imports table, and it will recurse on itself for any subordinate modules. The result is code that will likely be difficult for you to follow, but LdrpUpdateLoadCount.cpp contains my attempt to write pseudocode for this procedure. Distilling the essence of the pseudocode leaves the following: LdrpUpdateLoadCount walks through either the Bound Imports Descriptor or the Imports Descriptor looking for imported modules using LdrpCheckForLoadedDll and the NTDLL hash table. If the module was newly loaded by a LoadLibraryExW call, then LdrpUpdateLoadCount updates its reference count and walks its tables for any imports.

You can easily imagine a tree structure that describes the relationships between DLLs and their imports, and LdrpUpdateLoadCount must walk the tree completely to update everyone's reference count correctly. Some modules enter the process with a reference count of -1 and are skipped by this update. I leave here a question for future exploration: why do some DLLs have a reference count of -1 and the others contain an actual count?


Kayaker

blabberer
March 2nd, 2005, 07:49
Dear Kayaker,
thanks for answering
i have skimmed through osterlunds article earlier and some more articles by pietrek like avoiding dll hell

the question in simple terms is like this
assume you load iczelions win.exe (tut 03) into ollydbg
and when it has stopped on 401000

you code


00401000 >PUSH WIN_orig.004021B4 ; /pModule = "KERNEL32.dll"
00401005 CALL KERNEL32.GetModuleHandleA ; \GetModuleHandleA
0040100A PUSH EAX ; /hLibModule = 77E80000
0040100B CALL KERNEL32.FreeLibrary ; \FreeLibrary
00401010 JMP SHORT WIN_orig.<ModuleEntryPoint>


and execute it you will see FreeLibrary wont return failure that is it will return 1 but you will see it neither unloads the module

like you say it will check for -1 some where here and



77F8AA4C ntdll.RtlEnterCriticalSection MOV ECX, DWORD PTR FS:[18]
77F8AA53 MOV EDX, DWORD PTR SS:[ESP+4] ; ntdll.LoaderLock
77F8AA57 CMP DWORD PTR DS:[EDX+14], 0
77F8AA5B JNZ ntdll.77F9A0F6 <--- will not jump 77F8AA61 NOP
77F8AA62 INC DWORD PTR DS:[EDX+4] <---- here
77F8AA65 JNZ ntdll.77F8B523

if you try to play with flags and make it jump
it will still create do
77F83609 |. E8 96FFFFFF CALL ntdll.RtlpCheckDeferedCriticalSection

the param here is Loaderlock
then on its result
create an event, semaphores and wait for single object and hang for ever

[CODE]
Call stack of main thread
Address Stack Procedure / arguments Called from Frame
0012FC48 77F8ED75 ntdll.ZwWaitForSingleObject ntdll.RtlpWaitForCriticalSec 0012FCB8
0012FC4C 00000044 Arg1 = 00000044
0012FC50 00000000 Arg2 = 00000000
0012FC54 00000000 Arg3 = 00000000
0012FCBC 77F8ECF1 ntdll.RtlpWaitForCriticalSection ntdll.77F8ECEC 0012FCB8
0012FCC0 77FCD301 Arg1 = 77FCD301
0012FCC4 77F8F979 ntdll.RtlEnterCriticalSection ntdll.LdrGetDllHandle+60 0012FF38
0012FCC8 77FCD348 Arg1 = 77FCD348
0012FF3C 77E87F6A KERNEL32.LdrGetDllHandle KERNEL32.77E87F65 0012FF38
0012FF90 77E8DBF3 KERNEL32.GetModuleHandleForUnicodeString KERNEL32.77E8DBEE 0012FF8C
0012FFB0 77E956FC KERNEL32.GetModuleHandleW KERNEL32.77E956F7 0012FFAC
0012FFB4 7FFDEC00 pModule = "KERNEL32.dll"
0012FFBC 0040100A KERNEL32.GetModuleHandleA WIN_orig.00401005 0012FFB8
0012FFC0 004021B4 pModule = "KERNEL32.dll"


anyway thanks
hope i will understand some thing someday

Kayaker
March 3rd, 2005, 01:37
Hi

Maybe to clarify a bit, a comment on that code. I must have a different Icz tut#3 from you, because mine looks different and doesn't even export FreeLibrary. No matter, more to the point is that it's always useful to make use of the documentation on hand before delving into unknown code and changing flags willy-nilly hoping to achieve something.

Using debug symbols on ntdll!_LdrUnloadDll identifies some of the flags you should be aware of:
Code:

:77F8B61B cmp _LdrpInLdrInit, 0 ; a much used global flag
:77F8B622 jnz short loc_77F8B63E ; don't use a CriticalSection
:77F8B624 mov eax, large fs:18h ; TEB
:77F8B62A mov [ebp+var_88], eax
:77F8B630 mov eax, [eax+30h] ; PEB
:77F8B633 push dword ptr [eax+0A0h] ; PEB.LoaderLock // CRITICAL_SECTION
:77F8B639 call _RtlEnterCriticalSection@4
:77F8B63E
:77F8B63E loc_77F8B63E: ; CODE XREF: LdrUnloadDll(x)+43j
:77F8B63E inc _LdrpActiveUnloadCount
:77F8B644 cmp _LdrpShutdownInProgress, 0
:77F8B64B jnz loc_77F8B790 ; decrement _LdrpActiveUnloadCount and exit
...


Knowing RtlEnterCriticalSection takes a CRITICAL_SECTION as a parameter, you can analyze the code you posted and see what flags you are actually messing with. RtlEnterCriticalSection is simply used to synchronize (protect as a resource) the code that will follow.
Code:

typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;

// The following three fields control entering and exiting the critical
// section for the resource

LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread; // from the thread's ClientId->UniqueThread
HANDLE LockSemaphore;
DWORD SpinCount;
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;


You can probably see that changing the jump after the check for RTL_CRITICAL_SECTION.SpinCount (DWORD PTR DS:[EDX+14]), may not be what you want to do. At least not without in conjunction with some other modification..



As a sideline to this re "the loading process", for the tech-heads, you can enable the Debug version of the ntdll Loader by modifying the PEB NtGlobalFlag bit 2 (FLG_SHOW_LDR_SNAPS, see struc SYSTEM_GLOBAL_FLAG, ntapi.h). The various LDR: DbgPrint messages used by the loader in ntdll will be sent to Softice or other debugger.

Fortunately, you don't have to do this bit modification yourself, the Resource Kit util, GetFlags (gflags.exe) will do it for you (and modify the other 25 NtGlobalFlag bits for playing). Here's the output for Icz's WIN.exe, the loader LDR: messages interspersed with the NTICE ones:
Code:

NTICE: Load32 START=400000 SIZE=4000 KPEB=81A6CA80 MOD=WIN
NTICE: Load32 START=77F80000 SIZE=7B000 KPEB=81A6CA80 MOD=NTDLL
LDR: PID: 0x28c started - 'c:\win.exe'
LDR: NEW PROCESS
Image Path: c:\win.exe (win.exe)
LDR: USER32.dll used by win.exe
NTICE: Load32 START=77E10000 SIZE=65000 KPEB=81A6CA80 MOD=USER32
LDR: USER32.dll bound to NTDLL.DLL
LDR: USER32.dll has correct binding to NTDLL.DLL
LDR: USER32.dll bound to KERNEL32.DLL
NTICE: Load32 START=7C4E0000 SIZE=B9000 KPEB=81A6CA80 MOD=KERNEL32
LDR: KERNEL32.DLL bound to NTDLL.DLL
LDR: KERNEL32.DLL has correct binding to NTDLL.DLL
LDR: USER32.dll has correct binding to KERNEL32.DLL
LDR: USER32.dll bound to NTDLL.DLL via forwarder(s) from KERNEL32.DLL
LDR: USER32.dll has correct binding to NTDLL.DLL
LDR: USER32.dll bound to GDI32.DLL
NTICE: Load32 START=77F40000 SIZE=3C000 KPEB=81A6CA80 MOD=GDI32
LDR: GDI32.DLL bound to NTDLL.DLL
LDR: GDI32.DLL has correct binding to NTDLL.DLL
LDR: GDI32.DLL bound to KERNEL32.DLL
LDR: GDI32.DLL has correct binding to KERNEL32.DLL
LDR: GDI32.DLL bound to NTDLL.DLL via forwarder(s) from KERNEL32.DLL
LDR: GDI32.DLL has correct binding to NTDLL.DLL
LDR: GDI32.DLL bound to USER32.DLL
LDR: GDI32.DLL has correct binding to USER32.DLL
LDR: USER32.dll has correct binding to GDI32.DLL
LDR: Snapping imports for win.exe from USER32.dll
LDR: KERNEL32.dll used by win.exe
LDR: Snapping imports for win.exe from KERNEL32.dll
LDR: Refcount USER32.dll (1)
LDR: Refcount KERNEL32.DLL (1)
LDR: Refcount GDI32.DLL (1)
LDR: Refcount KERNEL32.DLL (2)
LDR: Refcount USER32.DLL (2)
LDR: Refcount KERNEL32.dll (3)
LDR: Real INIT LIST
C:\WINNT\system32\KERNEL32.DLL init routine 7c4ece51
C:\WINNT\system32\USER32.dll init routine 77e311c5
LDR: KERNEL32.DLL loaded. - Calling init routine at 7c4ece51
LDR: USER32.dll loaded. - Calling init routine at 77e311c5
LDR: PID: 0x28c finished - 'c:\win.exe'
NTICE: Exit32 PID=28C MOD=WIN
NTICE: Unload32 MOD=WIN


Have fun,
Kayaker

blabberer
March 3rd, 2005, 10:20
hehe kayaker ,
iczelion made only one set of tuts and they will be same for you as well as me


i said you code that meant assembling it onsite

and when you assemble in ollydbg you dont have to have any imports imported by the exe if the module is loaded ollydbg will call any exports that module exports without the implicit need by the loaded app importing it

all you have to do is
call "Module_Name.Import_Name"

anyway on your second point of using gflags.exe well i dont use gflags.exe but use
a registry file
which is like this

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"GlobalFlag"=dword:00000002


just merging this will put out all those dbgprint messages in ollydbg

Quote:

77F9FA77 Debug string: LDR: Snapping imports for WIN_original.exe from KERNEL32.dll
77F9FA77 Debug string: LDR: Refcount USER32.dll (1)
77F9FA77 Debug string: LDR: Refcount KERNEL32.DLL (1)
77F9FA77 Debug string: LDR: Refcount GDI32.DLL (1)
77F9FA77 Debug string: LDR: Refcount KERNEL32.DLL (2)
77F9FA77 Debug string: LDR: Refcount USER32.DLL (2)
77F9FA77 Debug string: LDR: Refcount KERNEL32.dll (3)
00400000 Module C:\masm32\ICZTUTES\TUTE03\WIN_original.exe


anyway what i was asking was is it possible to free a module which was loaded
explicitly by an app by calling FreeModule()

thanks and regards

Kayaker
March 3rd, 2005, 13:29
Quote:
[Originally Posted by blabberer]hehe kayaker ,
iczelion made only one set of tuts and they will be same for you as well as me
i said you code that meant assembling it onsite


Aah good, I thought maybe you'd gotten hold of a l33t set of Icz tuts or something
I think I understand now, sorry, I'm not too familiar with all the cool things you can do with Ollydbg.

Cheers

Hero
March 9th, 2005, 05:21
Thanks for great help on everybody.
Now my import protector is more better and is able to protect import table for
more compilicated programs such as winrar.
But I still have a big problem.It about MFC dlls.
The way that I used to protect IT with LoadLibrary and GetProcAddress is that
I inject some code based on orginal program IT into new program and overwrite
the FirstThunk of imported functions to mine program addresses and destroy that headers of that imports.
But this will cause problem in MFC.
Because programs that uses MFC,will use IT in other ways too.In some functions
they read the address in IT table for some function,Then read what is in that address.
Any suggestion that How I can bypass this problem?
(I think I should write all in an other way ,Can you suggest a better way or how
I can correct this?)

sincerely yours

Hero
April 7th, 2005, 05:08
Hi again!

I should say that I try to correct this problem.I make a list for DLL that should not

recontructed like this,and I use the previous place of their FirstThunk value for them.

I mean When I try to make a new IT for protected file,After the main IMAGE_IMPORT_DESCRIPTOR

that contains the needed kernel32.dll function for me,I add the DLLs that should not

rebuilded IMAGE_IMPORT_DESCRIPTOR after them,but for these DLLs I use the

previous FirstThunk.

But I don't know why my PE structure crashs.I explore protected program with

"PE explorer" and the PE structure is correct on the face of it and I can't find
the PE problem.Do you have any suggestion?
I attachech a sample for corrupted file.

sincerely yours

blabberer
April 7th, 2005, 11:48
your 30 kb test is looking for 1.5 mb download in the name of mfc71.dll
and msvcr71.dll well i had them some where in my hdd

so by copying them to local directory i was able to load your hello world
both of them in ollydbg (didnt look further but it seems your protected exe is not loading the mfc dll at all look at the debug strings that i have attached if you downloaded it or if you dont want please reply so that i can delete the attachment

anyway your protected is crashing here it seems you are trying to loadlib msvcr

Code:

0040A8E3 FF75 0A PUSH DWORD PTR SS:[EBP+A] ; MFCtest_.0040CB46
0040A8E6 8B55 14 MOV EDX, DWORD PTR SS:[EBP+14] ; MFCtest_.0040CBAD
0040A8E9 FF12 CALL NEAR DWORD PTR DS:[EDX]
0040A8EB 33D2 XOR EDX, EDX ; MFCtest_.0040CBAD
0040A8ED 8B5D 0A MOV EBX, DWORD PTR SS:[EBP+A] ; MFCtest_.0040CB46


but [edx] == 000000 at this point
DS:[0040CBAD]=00000000

Hero
April 8th, 2005, 03:01
Thanks blabberer
I get that log then if you want,you can delete it.
In addition I can't see anything abnormal for MFCTest_p log,Do you see any?
The main problem is that in some MFC programs DLLs like "msvcrt",Program use
has an strange use of IT.It gets the address of FirstThunk from IT for some
functions and then use data that is written on that address.
This will make trouble for my protector,Because I used IT table redirection.Then
I should use previous IT table for this DLL.Then Simply I create the needed
IMAGE_IMPORT_DESCRIPTOR after my program main IT for protected program
and then sets its FirstThunk to FirstThunk of previuos IT table in another section(
I should use this becuase I can't change all program use of msvct).But now this
program Crashs.
Is it possible this happen because I use two sections for saving my IT table
IMAGE_IMPORT_BY_NAME(one is the previous IT for msvrt and the other one
for my main IT table?

sincerely yours

blabberer
April 8th, 2005, 03:17
as i stated i did not look further apart from loading both in ollydbg
and during the fleetin glance that i took at the debugstring i saw some
add to list string by ollydbg that states import lookuptable address out of blah blah also during stepping i noticed that i faced a single step exception
which i think shouldnt apaart from these observations i did not look further

bilbo
April 8th, 2005, 04:25
Hero,

I don't understand exactly what have you done (you should have also provided some source code to better clarify your imports obfuscation process, but maybe it is too valuable to give to us )...

Anyway, be warned that the address you get from some system DLL is NOT ALWAYS the imported function entrypoint!

E.g (XPSP1):
KERNEL32!RtlUnwind shows the address (taken from imports table) 0x77EB3ADA; but there isn't any code at all at that location. There is just a simple ASCII string, null terminated: "NTDLL.RtlUnwind", a sort of redirection...

In fact, if you execute
Code:
GetProcAddress(LoadLibrary("KERNEL32", "RtlUnwind";

you will not get 0x77EB3ADA, but 0x77F50C44, which - you already can guess it - is the address of NTDLL!RtlUnwind.

Amazing, isn't it?
Best regards, bilbo

Hero
April 8th, 2005, 11:05
Hi bilbo
Thanks for that notification!
But I should say that rerirection will not affect me,Because my main algorithm
is this:
1-Add a section to file with a sub routine that gets an address for encoded name
of function that I need.
2-I decode name of that function,Then using LoadLibrary and GetProcAddress I will
find and run it.
3-The important phase is changing the value that is refered by FirstThunk of
IT table to address of my program that generate needed address for decoding
function,and eliminating IMAGE_IMPORT_DESCRIPTOR of main program.

I think you get what happened now!I will add a redirection to program!
(I think after completing this protector it is no need for writing its cracking tutorial
because I said anything here for this phase of protector! )
Now I get problems from msvrt DLL in MFC programs.For get my problem you can
simply run MFC_test.exe in ollydbg and see how program is using this DLL.
Accessing this DLL is deferent to normal use of IT table in some places.

sincerely yours