Hi everybody !

My problem is that I want to load a library (DLL)
that resides in memory. Actually this
questions is targeted at those amongst you
who have got some deeper knowledge of the
Win32 Sub-system. Concerning dynamic loading
of libraries you would either statically link a DLL's
library to the final executable or load the DLL
at runtime via LoadLibrary() and then get the
the address/handle via GetProcAddress of the
relevant function.
What I want to do is to load a DLL without using
the mentioned functions. Win32 is doing quite a lot
_behind the scenes_ - For Example RVA to Offset
calculation and such stuff is done via APIs
that are rather undocumented. IAT patching is also
done in the background - without any user interaction
respectively user code being involved in that process.
Although I do know a couple of functions that are
executed I don't know everything what's going on
behind LoadLibrary() and GetProcAddress().
In particular I need those functions that are involved
with memory mapped files - DLLs are mapped when
being executed. So that I would be able to
load an image of a DLL that's been loaded into memory
without the usual functions.

Thanks for all comments/ideas (if any)


regards

MikeJ
Posted on 2002-04-10 14:25:46 by MikeJ
Ahhhh..this makes for a great learning process!

For starters I would recommend that you use softice to set a break point on the LoadLibrary and/or GetProcAddress function; looking up the arguments and usage inside your Win32 API docs; take notes of the param's passed in; perform some single stepping and then repeat for each new function that you uncover. Soon enough you will have the answers that you are looking for and so much more as this technique will help you un-lock the secrets of Windows.

To help kick you off, I would recommend that you include the following exports in your softice session:
(1) Kernel32.dll
(2) User32.dll
(3) GDI32.dll
(4) Ntoskrnl.dll
(5) Hal.dll

If you run into difficulties and / or have questions about undocumented functions that you find then post back here

:alright:
Posted on 2002-04-10 14:57:16 by madprgmr
I'd rather have a good look in a win32 API reference + PE docs than
tracing through microsoft's code.

The steps in loading a PE file aren't too bad, and there's a couple
of ways to do it. Easiest is to create a file mapping, look at SizeOfImage,
VirtualAlloc a buffer, and copy in the stuff according to section VAs and
such. Then you'll need to apply relocs (unless you can alloc pehdr.imagebase),
fix up imports... and you're done. For standard PEs anyway.

Perhaps one can use CreateFileMapping with a Copy-On-Write flag instead
of loading into an additional buffer... haven't looked into this.
Posted on 2002-04-10 15:41:40 by f0dder
(5) Hal.dll
I doubt this dll has anything to do with the loading of dlls, it is the Hardware Abstraction Layer dll, it sits under the kernel and provides an interface to the hardware (therefore it can be different on different machines running the same OS).
Posted on 2002-04-10 18:39:47 by sluggy
I doubt this dll has anything to do with the loading of dlls


With full realization of what the dll is for, it does not hurt to have a core componentd of Windows listed under the Exports section of SoftIce when performing Windows system level debugging. Should on the off chance that you single step into a section that references a area of this dll wouldn't be better to see that symbolic through SoftIce than as a hex number ? Besides it takes two seconds to add in and the overhead for it is about zilch.

However, if you are just installing SoftIce (and then uninstalling) to look at this one issue then yes there is no point in adding this dll; but if you are leaving SoftIce on the system for future debugging then it is my opinion that at best, adding this DLL could not hurt an may actually be of benefit.

To each his own.
Posted on 2002-04-10 19:35:56 by madprgmr
Okay, first - thanks so far.

Concerning sICE and the BPX(s) you are suggesting-
yes, would be admittedly an idea...Personally,
I have had a thorough look at imagehlp.dll - this
is the DLL that's responsible for PE-file handling.

So, I am quite aware of the fact that I need to proceed
the subtleties of the PE-files. I do know that the
PE format is quite well documented. But actually
I was not going to re-implement everything.
I am sure that Micro$oft's sub-system provides the
corresponding functionality. Well, it's just way
too undocumented. Win NT5 is practically passing
most kernel32 function calls to NTLOADKRNL.

And mapping the file itself isn't a problem - as already
said CreateFileMappingA etc. is the way to go.
But I want to work only with/in memory. Sure, I could
easily dump the memory area to a file on disk
and call the DLL then the old fashioned way.

Unfortunately imagehlp.dll is not everything I need-
though, it does offer some basic functions that are
useful for the said purpose.

I have already considered to use sICE - but
actually it should be possible to get all information
without spending an hour or so in sICE just to
find the underlying functions - despite from that
there's still the problem to determine the passed
parameters. Which to solve would take an additional
hour...
Posted on 2002-04-10 19:44:19 by MikeJ
hi,

loading a pe in memory, for run, is easy, as already was said. just alloc the mem, parse the imports and relocs, jmp to entrypoint and most files will run ok.

but anybody know how one can make to load the resources? is not enought have they be in memory, in the right place, when you call, as example, CreateWindowExA().

seens that some work is done in the loader. anybody have any tip?

ancev
Posted on 2002-04-10 19:54:56 by ancev

hi,
loading a pe in memory, for run, is easy, as already was said.


The point is not only loading the PE file but doing
everything that's done by windows in the
background. IAT patching and so on.



just alloc the mem, parse the imports and relocs, jmp to entrypoint and most files will run ok.


Okay, fine -
though, it's not only about parsing but also
CHANGING data...
how do you PARSE the imports and relocations ?
I don't mean to do that all manually with
a good PE documentation - that approach is
definitely possible. Would take some time...
no, what I want to do is to use WINDOW'S
libraries to do all this stuff for me.



but anybody know how one can make to load the resources? is not enought have they be in memory, in the right place, when you call, as example, CreateWindowExA().seens that some work is done in the loader. anybody have any tip?


You name it: the *LOADER* does quite a lot
of stuff _behind the scenes_ !
But if you've got everything in the DLL - the
code and the data/resources then it shouldn't
be a problem to load the res.
Posted on 2002-04-10 20:02:48 by MikeJ
I agree with f0dder. The PE header contains every information necessary to map the dll into memory. After mapping all sections were done, you have to fix up imports (walk the import entries, load the import dlls, obtain the addresses of the import functions and fill them in import address table), handle relocations if necessary, and update the data directories to reflect the RVA of the corresponding data such as the resource.

However, loading the dll with this method doesn't add the dll to the internal module list maintained by Windows.

To study how Windows loads dll, I recommend that you disassemble LoadLibrary with IDA and then take a look at the real thing under SoftICE for something that is not clear from just looking at the dead listing.
Posted on 2002-04-10 20:10:25 by Iczelion

I agree with f0dder. The PE header contains every information necessary to map the dll into memory.


Sure, it does - otherwise it couldn't work ;-)




After mapping all sections were done, you have to fix up imports (walk the import entries, load the import dlls, obtain the addresses of the import functions and fill them in import address table), handle relocations if necessary, and update the data directories to reflect the RVA of the corresponding data such as the resource.


Yeah, I do know what to do in theory quite well.
And I did also consider in the past to do all that
stuff manually. But that's way too much effort
if you take into account that all this stuff is
also done by windows and can probably be
accessed via "undocumented" function calls.




However, loading the dll with this method doesn't add the dll to the internal module list maintained by Windows.



okay, that's understandable - but can probably
also easily be covered by calling the corresponding
function - IF existing ;-)




To study how Windows loads dll, I recommend that you disassemble LoadLibrary with IDA and then take a look at the real thing under SoftICE for something that is not clear from just looking at the dead listing.


Yes, I see - thanks for all the suggestions, but as you
might have noticed I am not so much in favour of
disassembling and reverse engineering windows'
inner life...
By the way...thanks for the opportunity to talk
to such a prominent guy like you Iczelion :-)
Posted on 2002-04-10 20:26:14 by MikeJ
since you were talking about dll/image loading 'n stuff i had a little question too: dlls are shared in memory is what my is told. but dlls do often import functions too. but the addresses of these functions are not always the same in every processes address space. for example, if my.dll imports a function from bla.dll in one processes, and in another process too, but if bla.dll has in the two processes another baseaddress because it is relocated.

that means that the IAT is not shared because they differ?
Posted on 2002-04-11 04:55:45 by roeldebikkel
When DLL's are shared in memory it means that every 4KB page which was unmodifyed will be really shared, while any page modifyed will use 4KB of your process's memory.
In the whole there will be a big saving of memory anyway.

So, to explain it differently: if you load a shared DLL then (ideally) you dont use any memory.. but as soon as you modify any part of it, that corresponding page will not be shared anymore but will use some other memory. It's all transparent to your process, though.
Posted on 2002-04-11 06:23:59 by Maverick



Yes, I see - thanks for all the suggestions, but as you
might have noticed I am not so much in favour of
disassembling and reverse engineering windows'
inner life...
By the way...thanks for the opportunity to talk
to such a prominent guy like you Iczelion :-)


Wtf is it you want? If you wanna know what windows does when loading a dll, go to the source ... rip out the code and study it. You say you know what it does in theory, so I take it you want to know every step it takes. In what other way than looking at the code behind - as you like to refer to it - could you find out? Hopefully you're not waiting for someone to spoonfeed you commented code on windows' loadlibrary function and it's colleagues.
If you know the theory of what windows does, studying it in person is not a problem. Neither would it be much of a problem to implement it yourself, if that's what you want.

Fake
Posted on 2002-04-11 09:08:21 by Fake51


Wtf is it you want?


Well, first of all: thank you very much for
being sooo kind to reply to this posting !!
Second, I appreciate your interest in knowing
what I want.




If you wanna know what windows does when loading a dll, go to the source ... rip out the code and study it.


Okay, thank you very much for this great idea.
Though, we are unlikely to have much in common
you can assume that I also got a brain. And yes,
ocassionally I even use it. My initial posting was
actually supposed to be rather clear: I was seeking
for the information of Windows' subsystem that
is not that easily available. And admittedly I am
somehow satisfied with the responses I received
since the same question didn't have that many
responses in another forum. The idea to get all
the necessary information manually by using a
decent debugger and lots of time was my very
first idea. But I did find other information on
the windows subsystem, and on functions that
the API redirects to, that is why I thought asking
if there is additional info couldn't hurt.





You say you know what it does in theory, so I take it you want to know every step it takes.


Cool down fake, nobody urged you to read
this posting, nobody asked you to reply to
it, and even more important: nobody wants
you to despair because of my posting. TRANQUILO
hombre :-)

No, I didn't look for a step by step guide.
Actually, I insinuated several times that I am
not going to take that approach, regardless
whether others write the corresponding
source or I do. I mentioned that I am looking
for the EXACT functions behind the said
API calls. By no means I was going to make
anybody else do my work. Rather, I was merely
asking if there is any documentation on that topic.
So, there is no reason for you to panic and screw everything up.




In what other way than looking at the code behind - as you like to refer to it - could you find out?


Okay, somehow I feel forced to mention that I
watched this board and its threads for a while
and I find it rather sad how some "wannabe-coders"
react so fu***in' aggressively towards certain
postings. I am not a newbie, luckily - otherwise
I might feel pretty discouraged by people like you.

It cannot be right to pretend so much annoyance
and importance. Think about it - PLEASE.
Even if those people are "real" coders they
still don't have the right to react the way some
tend to do here. The objective of such a board is not to
block eachother, not to create barriers - rather
you ought to support and assist eachother. If
you can't do that, or maybe if you don't want to,
no problem - but then I would really recommend
you to STFU. Intimidating newbies is not only stupid
and arrogant but also superflous and a waste of time.
The time of everbody who reads those lines !




Hopefully you're not waiting for someone to spoonfeed you commented code on windows' loadlibrary function and it's colleagues.


OMG ...
Okay, I just thought about it thoroughly - maybe
I was too vague. But I am quite sure that
my question didn't appear too stupid or naive.
Nor did I ask anybody to do any assignment :-)



If you know the theory of what windows does, studying it in person is not a problem. Neither would it be much of a problem to implement it yourself, if that's what you want.


Okay, again: thank you very much for your posting -
but you could have saved the time...
Posted on 2002-04-11 10:12:07 by MikeJ
Easy, MikeJ.

As for using windows APIs to do PE loading... I suppose NT and 9x
handle this very differently, and if anything is exported it's probably
NT native (undocumented) stuff. And still I doubt it. Just guesses, though.

Thing is, there isn't really that much work involved in writing a PE
loader (except for some stuff like resources, and perhaps a few of
the very rarely used features of the PE format). If you had started
writing code before posting, you'd probably have something running now ;).
Now, how do you want to load the image? I suppose it's a DLL...
is it in a file, or included somewhere in your own executable image?
This will obviously affect the loading method...
Posted on 2002-04-11 10:23:24 by f0dder

Easy, MikeJ.


EASY =)

Originally posted by f0dder
As for using windows APIs to do PE loading... I suppose NT and 9x
handle this very differently,


Certainly they do

Originally posted by f0dder
and if anything is exported it's probably
NT native (undocumented) stuff.


yep, that's why I asked if anybody has got some
lines on that stuff.



Originally posted by f0dder
And still I doubt it. Just guesses, though.


ya, I see and think the same

Originally posted by f0dder
Thing is, there isn't really that much work involved in writing a PE loader (except for some stuff like resources, and perhaps a few of the very rarely used features of the PE format).


Okay, I see your point - fact is that I was actually
looking for the "How is Windows doing it (*exactly*)" and not
"how can I do it myself".
I do know that the PE format is quite well documented
and you can probably write something useful
in a small amount of time. Anyway, due to the lack
of details you cannot epect it to be too compliant.
Sure, the DO IT YOURSELF approach would have
the advantage of platform independence amongst
windows systems...



Originally posted by f0dder
If you had started
writing code before posting, you'd probably have something running now ;).


Yes, I see what you mean. But referring to my last
posting: way too many smileys to be serious.
It was simply the way Fake responds to a posting
as if had been knocking on his door for the last two
weeks. And his assumptions are likewise expressing kind of annoyance.


Originally posted by f0dder
Now, how do you want to load the image?


In general I was interested in the approach.
The DLL itself might be a custom ressource for
example.

Originally posted by f0dder
I suppose it's a DLL...


yes

Originally posted by f0dder
is it in a file, or included somewhere in your own executable image?


- well rather the latter.


Originally posted by f0dder
This will obviously affect the loading method...


Sure it will.
An easy example:

1) Load Resource (the DLL)
2) Load the DLL that is contained in the Resource
3) Make it usable by the system/own process
4) Call functions
5) Unload DLL
Posted on 2002-04-12 02:53:46 by MikeJ
f0dder, MikeJ got Mack
Worse than YOU...Posted on 2002-04-12 12:38:51 by cmax
"How is Windows doing it (*exactly*)" and not "how can I do it myself".


Ok at this point I must admit that I am totally confused here so let me see if I have I this correct:

You want to know exactly how Windows at the system level goes about loading and making available a DLL but you are not looking for the SoftIce method of figuring this out nor are you looking for someone to give you a fully commented code snippet of a Windows system level debugging session focused on just that. Also, you are not interested in developing a PE loader of your own.

Am I on the right track ? If I am then here is the point in which I get really lost as the only way that I see for you to get
"How is Windows doing it (*exactly*)"
is for someone to invest the time to look at those "undocumented calls" (either with SoftIce or a static Disassembler) and figure out exactly what they do and why (thusly making them, to a point, no longer undocumented).

:confused:
Posted on 2002-04-12 12:39:25 by madprgmr


You want to know exactly how Windows at the system level goes about loading and making available a DLL


which subsystem functions are used by
LoadLibrary/GetProcAddress.



but you are not looking for the SoftIce method of figuring this out


meanwhile I should consider that ;-)
Well, actually I expect some documentation
to exist. I've already found some good docs
on the NT subsystem.
A listing of some functions like presented at http://cn.geocities.com/cntsu00/xpcalllist.htm can be also quite useful. Now I've found a whole ebook, gonna check that out, though I do consider to do it manually.



nor are you looking for someone to give you a fully commented code snippet of a Windows system level debugging session focused on just that.


Okay, don't get me wrong - if that code/doc
exists already I would appreciate somebody to
post it here - because I couldn't find much
information on the details so far...




Also, you are not interested in developing a PE loader of your own.

it's just that such a PE loader would have to be
fully Win32 compliant which makes the things more
complicated, as already mentioned by f0dder - regarding ressource loading etc.






Am I on the right track ? If I am then here is the point in which I get really lost


lol, people can be so caring



as the only way that I see for you to get is for someone to invest the time to look at those "undocumented calls" (either with SoftIce or a static Disassembler) and figure out exactly what they do and why (thusly making them, to a point, no longer undocumented).


Okay, I see what you mean, but actually
I am quite confident that those fu***ing functions
are SOMEWHERE documented, concerning the
ebook I talked about, I found it at:
http://ftp.selab.org/ebook/NT_Filesys_internals/
(hope this is no W*_ RE*)


Thanks for your suggestions and offers !
Posted on 2002-04-12 13:11:58 by MikeJ
Long time ago i've needed to force a dll to register it, bcoz regsvr32.exe failed. To make a LoadLibrary first u must to 'align' the dll, i mean that all the virtual offsets and raw offsets in the dll must be the same. the easiest solution i've found is:
make a mapview of file (of course u cannot map the dll into the image base, so later u must to handle all the relocations),
Dmapa is the address that returned the API MapViewOfFileEx of the original dll:

the main idea is loop throught all the sections and read the virtual offset and virtual size (in most cases virtual sizes of sections are greater than raw sizes) if virtual size is greater than
raw size u must add to the new dll the difference (with garbage or else).

CAUTION: those code dont check for errors.

mov ebx,Dmapa
mov ultdir,ebx
add ebx,
xor ecx,ecx
mov cx,
add bx,word ptr
add ebx,20h

mov eax,

sigoCreando:
push ecx
invoke WriteFile,puntArchAlt,ultdir,eax,OFFSET escritos,NULL
test eax,eax
jnz @F
invoke MessageBox,NULL,OFFSET msgerrNoEsc,OFFSET msgbarra,MB_OK or MB_ICONERROR
jmp chau
@@:
mov eax,
add eax,Dmapa
mov ultdir,eax
add ebx,28h
mov eax,
sub eax,
pop ecx
loop sigoCreando

mov eax,
invoke WriteFile,puntArchAlt,ultdir,eax,OFFSET escritos,NULL
test eax,eax
jnz @F
invoke MessageBox,NULL,OFFSET msgerrNoEsc,OFFSET msgbarra,MB_OK or MB_ICONERROR
jmp chau
@@:

those snipped produce a dll that have the same raw address and virtual address. (like an image of the dll running in memory). Once we have the new dll, we make a new MapViewOfFile. Then we must handle all relocations, and must resolve the imports (thats the worst part, and my code works sometime).

Those snipped resolve the relocs.
sigo:
add eax,28h
cmp dword ptr,42000040h
je hayreloc
loop sigo
jmp nohayreloc
hayreloc:

mov eax,
add eax,Dmapa

mov ebx,Dmapa
sub ebx,edi
mov delta,ebx

tablarelocs:
mov ebx,Dmapa

add ebx,

mov ecx,
sub ecx,8
shr ecx,1

add eax,8
relocs:
mov edi,ebx
mov si,word ptr
and si,0FFFh
add di,si

mov esi,
add esi,delta
mov ,esi

inc eax
inc eax
loop relocs

cmp dword ptr,0
je nohayreloc
jmp tablarelocs
Posted on 2002-04-13 10:57:09 by r00t