#16
|
||||
|
||||
I did it simpler. I coded a stub for the real dll: a new dll exposing the same methods of the original dll, eventually through export forwarding if you don't know the original DLL prototypes.
from matt Pietrek.. Quote:
The patched code does these things: -load the original renamed library (with a leading _ ) -initialize the exports I would to overwrite (if any) through GetProcAddress. -patch the memory of the DLL (through the handle returned by loadLibrary). -exit from Dllmain in the case I wanted to change some of the original Dll's export behaviour I also coded a function with the same prototype of the original one, which do required tricks and after call the original export. Doing this way I was able to easily code a loader for a asprotected dll which pathces in memory all the nags and insert some missing code, stolen by asprotect.
__________________
Ŝħůb-Ňìĝùŕřaŧħ ₪) There are only 10 types of people in the world: Those who understand binary, and those who don't http://www.accessroot.com |
#17
|
|||
|
|||
...
Well,actually there are a few Methods.
You could go and "hook" the Loadlibrary Call that loads the dll, thus obtaining the dll loadaddress. from that you can walk the export table to get your functions and/or calculate any needed distance values. Another Method would be to use toolhelp/psapi functions. you can locate your main app and get its loaded modules this way. you will also get baseaddress/size whatever and can just read your dll out that way easiely The "handmade" export forwarding will work too,but i guess its more work to the thing already needed. |
#18
|
||||
|
||||
Hmm...
The problem is I know nothing about API hooking. After 3 years, I decided to write a universal loader. This time ABEL didn't help me. It's my first coding in VC++. OK, I'm writing an universal loader for a license manager program which its kernel is a DLL. Some programmers put this DLL in the resource of their application. It's packed with ASPACK and sometimes with ASPR. So, I think the method of Shub-Nigurrath won't work for my purpose. I think if the DLL is in resource, LoadLibrary is not usefull. Because DLL name may be changed from an application to other one and its addresses may be changed. [NtSC], If program loads several DLL and lock-DLL name is variable, is it usefull to use API hooking? (Could you plz write a short example of using API hooking or toolhelp/psapi functions?) So I've used FindWindow, GetWindowThreadProcessId and then OpenProcess to get DLL process handle for reading and writing. But I don't know how to get its Base address and/or one of its EXPORTs address. (I've alot of problem with reading PE header file in VC++, too) Is there any short and precise method? |
#19
|
|||
|
|||
...
Basically.. yes. Api Hooking can be a good Thing to use (if the Dll is extracted/loaded a normal way). This means, the Dll is extracted to a Folder and then loaded with the common Win32 Apis (LoadLibrary for example).
A good Package therefor is the ApiHooks Package from EliCZ for example. Also Yodas "Hoko" Package is available with atleast 1 Global Hook for free,maybe you should consider to use those. Atleast playing with such stuff you should read more about the PE-Structure (its a hard way,but will work out in the end Anyway,what kind of dll/protection do we talk about here? |
#20
|
||||
|
||||
Instead of hooking, I'v a better idea.
After appearing the registration from (created by DLL), we are sure that DLL is extracted/loaded completely. Its better to get the list of imported DLLs and get the address of serial-check function by GetProcAddress in one loop. Now, how could I get the import list? only DLLs names. My problem about reading PE headers almost solved. If i could find any address from the loaded DLL, I could find its PE header by a simple search algo. The license manager is : CoLock hxxp://www.colock.com/ It's a funny license manager !! Last edited by Newbie_Cracker; 03-12-2005 at 04:06. |
#21
|
|||
|
|||
Basically a very old asm-snippet of the stuff you need to sort...
get_modules: cmp [modbuffer],0 jz nofreemod Call GlobalFree, [modbuffer] nofreemod: mov [modsize],04000h Call GlobalAlloc, 0040h, [modsize] mov [modbuffer],eax mov [modpointer],eax mov ecx,[P_Info+8] mov [ProcEth32ProcessID],ecx push ProcEth32ProcessID ;th32ProcessID push TH32CS_SNAPMODULE ;dwFlags call CreateToolhelp32Snapshot mov [hSnapshot],eax lea edi,ModuleEntry push edi ;lpme mov dword ptr [edi],SIZEOFMODULEENTRY push eax ;hSnapshot call Module32First call copy_modinfo next_mod: push edi ;lpme push hSnapshot ;hSnapshot call Module32Next or eax,eax jz mod_done call copy_modinfo jmp next_mod mod_done: push hSnapshot call CloseHandle xor eax,eax ret copy_modinfo: pushad mov edi,[modpointer] mov ecx,edi push ecx mov eax,[ModEmodBaseAddr] ; get imagebase mov [edi+30h],eax mov eax,[ModEmodBaseSize] ; get sizeofimage mov [edi+34h],eax lea eax,ModEszModule ; get name of module call copy0 pop ecx mov eax,ecx call lowercase_buffer add ecx,040h mov [modpointer],ecx popad ret Just look what apifunctions are used and port it to ur c-code. that should be enough.. basically you workout all the loaded modules from within a given processinfo! so..using such a snippet will obtain a list of the loaded modules.. u can increase the search for ur "special" dll by skiping "known" dll modules. doin this , you can create a table with system librarys and just ignore them. non standard dlls u examine by obtaining the export table. you can get the addresses of the exported functions and do a search for whatever in that memory-area. hope it helps, cheers |
#22
|
|||
|
|||
I think I have a similar question, or maybe I am just re-phrasing the previous question:
What I want to do is to ask Windows, "where is the library <whatever.dll> loaded in memory?" (I think). My intent is to, for example, compile a prog on Win98, examine the prog with a hex editor, and see a reference call to a library function whereby the function is located at MyAddress1. Then, when I compile the same program under WinXP and view it with the hex editor, the function is located at MyAddress2. Obviously, the DLL has been re-located and the address's within the exe (after loading into memory) have been adjusted accordingly. Therefore, I think I want to ask of the specific Windows OS (XP in this case), "where did you move the DLL to", so I can manually change these address's myself. I tried using "LoadLibrary" within my program, but that just a) loads the library within the context of my progarm, and b) gives me the address of that load....NOT the one in Windows. What am I missing? sarge Last edited by Sarge; 05-11-2005 at 02:10. |
#23
|
|||
|
|||
MAybe this will help you :http://www.woodmann.com/yates/lad.txt
bye NeO |
#24
|
|||
|
|||
@Sarge, that is exactly why NTSC said hooking LoadLibrary would be usefull. Hook the procedure, check arguments. If program is trying to load "mytarget.dll" then call real LoadLibrary, and that is imagebase you need. Now, also send it to program. If its not one you need, then just send it to program. You can make new section for your code so all is executed in target context, but you have to write your code in "delta offset", meaning, relocatable in memory.
And a question from me to someone here. Maybe NTSC knows... How to gain write access to space of a loaded dll? Eg, user32 in win9x? In NT we can use VirtualProtect. In win9x there is an undocumented procedure i found in some source, that looks like was taked from yoda. It works, but i have problem when i want to write my code relocatable. Then, i need to GetProcAddress of that undocumented function. That function is VxDCall4. It has no real name so i cant get by name, and when i try to GetProcAddress by ordinal i get error |
#25
|
|||
|
|||
Hello newbie_cracker,
Quote:
Regards, Sope. |
#26
|
|||
|
|||
@sarge - Just take a Module Snapshot either with Toolhelp or PSAPI Functions and you will get the BaseAddresses etc., Size whatever of the Modules belonging to the specified Address. I think that is what you focused? You cannot "guess" or take a specific LoadAddress since indeed the System "can" relocate a DLL everytime somewhere else. Look at the Code Snippet i posted its all there..
@nikola - What you focus is a global Hook under 9x. Under NT you change or better modify the DLL Context specific, under 9x if you go with the VXDCalls you do it globally. (Equal to modifications with a Sys/KMD under NT). Iam sure Yates has some good Code Examples on his Page about But i would prefer NT,since the Process specific Modifications are easier realizeable there. Cheers |
#27
|
|||
|
|||
@NTSC, yes, i realised that on first win98 crash But i didnt think that would be problem. I could just check PID and if its of my process i go on. I just wanted to know how to find address of that VXDCall :/ One i use when i link my loader is from lib. But i need to be able to find it on the fly.
Tnx for answer tho |
#28
|
|||
|
|||
well i saw some article in codeproject.com on w9x api hooking i dont have a link
right now but you should be able to locate all articles by artemis (i think i remember right ) it was titled some thing like systemwide hooks on w9x if you cant locate post ill try to grep my bookmarks |
#29
|
|||
|
|||
NTSC, Nikola:
Thanks, guys, for the support....I think I need to study up on that, as that's a new one for me. If you dont' mind, I'll go the PM route to you, so I don't tie up this thread. Thanks sarge |
#30
|
|||
|
|||
@ Nikola...
Maybe traverse Exports / or Check Dllbase & use hardcoded Address / or even "borrow" original Function Code. Well,depends on what purpose you need the Code i guess |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Loader and Patch Dll file in C# | mcr4ck | Source Code | 0 | 06-19-2022 23:59 |
Creating a Loader for DotNet Apps? | bball0002 | General Discussion | 2 | 09-24-2009 22:06 |
modify UPX | feisu | General Discussion | 15 | 06-27-2003 04:24 |