A Day in the Life of the Win32 Loader

[MassacreAL]

CMD Prompt: Good morning sir! I am your command prompt today That was a flawlessly executed logon. How may I help you today?

USER: Good morning to you too computer. I think today I want to do some data retrieving.

CMD Prompt: A wonderful choice sir! A finer day it couldn't be for looking over your data. How will you have it today? Sunny side up? Once over lightly?

USER: I think I'll use Microsoft Access. Would you kindly load Access please?

CMD Prompt: Most certainly sir! An excellent choice! One moment while I load it.

CMD Prompt: Oh, Win32 loader? Would you please load that ACCESS.EXE file that I notice in the Office directory? My user desires to play with it a bit now.

LOADER: No problem. Shouldn't take but a jiff.

<pause>

CMD Prompt: Any problems?

LOADER: No sir, not a one. It's just that I'm surprised to see that ACCESS.EXE uses 21 DLLs. Quite an unusual number for a Win32 program. Most EXEs only use 3 or 4 DLLs. This one really sets a record! But no problem - I just love to map in all these DLLs. After all - that's my primary purpose in life.

<pause>

LOADER: Well, that should do it. They're all mapped in.

CMD Prompt: Then we can start her up now?

LOADER: Well not quite. I just noticed that these DLLs invokes some other DLLs. Oh well, I guess I'll have to go load them too. At least we'll only have to load those DLLs that this program really needs.

CMD Prompt: How many DLLs does it require?

LOADER: Oh my gosh! It references 1477 DLLs! Another record! I can't believe it! Oh well, here goes...

LOADER: The first one it wants is MSO9.DLL. That should be an easy one.

<pause>

LOADER: Oh no! Not more! MSO9.DLL just called LoadLibrary on another 20 DLLs!

CMD Prompt: Have you enough room for them all?

LOADER: No sweat. This is a virtual memory machine. And this disk I/O is real fast. I'll have it in a minute.

<pause>

LOADER: There. Now on to the other DLLs. Next comes USER32.DLL. Guess it's important that we be able to use all this data.

CMD Prompt: Yup. What next?

LOADER: Now we'll need a database manager, so I guess we'll just have to go off and load ODBC32, the database management system.

CMD Prompt: Sounds reasonable.

USER: How's it coming there computer?

CMD Prompt: No sweat. It'll be just another moment.

LOADER: And now we'll load ODBCCU32.DLL.

CMD Prompt: But I thought you just brought in your database manager?

LOADER: Yes, but this one is the relational database system. It's a whole different ballgame.

CMD Prompt: Well, hurry it along.

LOADER: Okay. Next comes ODBCJT32.DLL, the relational database manager.

CMD Prompt: But how does that differ from ODBC32.DLL?

LOADER: I don't know. I just load'em. They tell me to load and I load.

CMD Prompt: Well, I hope that's it for database managers.

LOADER: Not quite. There's still MSJET40.DLL. This company specializes in its excellent collection of managers.

CMD Prompt: Great! I guess that's it then.

LOADER: Not on your life! Do you think our user merely wants to query his data? What if he wants a chart using his data?

CMD Prompt: Oh.

LOADER: Didn't think of that did you? I guess we'll just have to go load MSCHART20.OCX.

CMD Prompt: I guess so.

USER: But I don't plan to do any charting today. I just wanted to prepare a short report.

LOADER: Sorry. MSCHART20.OCX comes with this program. It's a free option.

CMD Prompt: What next?

LOADER: Hmm. Looks like a request to bring in VBAR332.DLL, the VBA run-time library.

CMD Prompt: Why would they want that? Is Access written in VBA?

LOADER: No, but the VBA run time library has many precious gems of useful routines that one might wish to call... Guess, I'll just go load it now.

CMD Prompt: Good thing you don't also need the Java run-time library too.

LOADER: Now you've done it! You've given me the evil eye. Either that or I just got up out of the wrong side of the bed this morning. Here look at this: this DLL is also requesting MSVBVM60.DLL and MSVCRT.DLL. Oh! and now look: It wants OLEAUT32.DLL too!

CMD Prompt: You never know when our user might want to do some scripting. He might need to embed a WinWord document you know. Better safe than sorry.

USER: What's taking so long?

CMD Prompt: (still trying to be pleasant) We're almost there now. Shant be much longer. After all, you want a user-friendly system don't you?

LOADER: That's right. I guess that's why I've been instructed to load HLP95EN.DLL. You never know when the user might request some on-line help so we've got to have our help system ready to answer his questions.

CMD Prompt: That's nice. I'm sure our user will appreciate that.

LOADER: And oh yeah - we'll need GDI32.DLL too, the screen package. Only the best on this system. Can't let our user make do without fancy graphics!

CMD Prompt: A wonderful thought. But will GDI32.DLL be enough?

LOADER: No. you're right of course. We'll also have to bring in COMCTL32.DLL. GDI32.DLL is only the low level graphics. COMCTL32.DLL will really let our user edit his data in style.

USER: But I wasn't planning to change the data today. Just one simple report...

CMD Prompt: Keep your shirt on. When this program finally comes up, it will really blow your mind.

CMD Prompt: But loader, will COMCTL32.DLL really be enough? Aren't web views the big thing these days?

LOADER: Right you are CMD, baby. Guess we'll need MSHTML.DLL, the HTLML display component. Won't take but another moment. (sigh) I think that was the last one.

CMD Prompt: Great! Then I can report back that we're ready to go?

LOADER: One second. Let me make one last check...

CMD Prompt: Never pays to be hasty.

LOADER: Ah nuts! Some of these new DLLs that we just loaded are requesting further attention. It looks like they too want to load other DLLs.

CMD Prompt: Don't we have enough DLLs? That's been 16 already!

LOADER: Well, security is an important issue too. Wouldn't want our user to lose any data. Look here: USER32.DLL wants us to bring in ADVAPI32.DLL. Guess I'll just have to load another one...

USER: (getting impatient) What's taking so long?

CMD Prompt: We're putting all the pieces together for you now. Shouldn't be much longer.

USER: Putting them together? Doesn't it come all assembled?

CMD Prompt: Not to worry. There's no extra charge for installation.

LOADER: There. And now what? Look at this: USER32.DLL also wants us to load MSVCRT.DLL, the common run-time library.

CMD Prompt: But didn't you already load MSVCRT.DLL?

LOADER: Right on baby! Let me just look around.

<pause>

LOADER: Oh there it is. We have it mapped into memory already. I guess I'll just throw this request away.

CMD Prompt: Do you get many of these redundant requests?

LOADER: Yeah, they happen all the time. Nothing to worry about. You get used to it. Look here, GDI32.DLL wants MSVCRT.DLL too; and so does ADVAPI32.DLL, and VBAR332.DLL, and MSVBVM60.DLL, and ...

CMD Prompt: Well hurry it along please.

LOADER: ... and MSJET40.DLL and ODBCJT32.DLL and ... Oh and look at this duplicate request for USER32.DLL and OLE32.DLL and OLEAUT32.DLL and SHELL32.DLL and ...

CMD Prompt: SHELL32.DLL? I don't remember seeing that one before. What is it and who wants it?

LOADER: Oops, you're right. I almost overlooked this request by SHELL32.DLL. It's easy to overlook this one; it's so small. Only contains a few wrapper functions.

CMD Prompt: Guess it should be easy to load then?

LOADER: On the contrary. This one attempts to load the entire C++ RTL! Imagine that. Oh well. That's life. Fortunately, I've already brought in most of the C++ RTL. Let's see now, what else will we need? Oh yes, COMDLG32.DLL. Can't imagine how we overlooked that one.

CMD Prompt: Is that it then?

LOADER: Yup. That's it. She's all here. You can go start her up!

USER: (pounding on keyboard) Where's my data!

CMD Prompt: Please use voice input sir! Those ctrl-C's are MOST annoying. They cause the most insidious interruptions to what I'm trying to do. We're starting your process now.

USER: It's about time.

CMD Prompt: There. How's that? Lovely data isn't it?

USER: I wouldn't know. Where's my window?

CMD Prompt: I don't know. Let me look into it.

CMD Prompt: CPU, where's his window?

CPU: We're executing instructions as fast as we can! Oh my god! An exception!

CMD Prompt: An exception! Is that serious?

CPU: My mistake; it's not a hardware exception, it's merely a software exception. Looks like the program signalled.

CMD Prompt: Why'd it do that?

CPU: Well, this program is naturally user friendly, so it wants to start up by displaying a splash screen.

CMD Prompt: So why doesn't it do that?

CPU: Well the dialog template is in a resource, sir.

CMD Prompt: Well get it!

CPU: That's what we're trying to do. You'll have to check with the USER32 system. It takes care of those things.

SYSTEM: Ah, I have the dialog request now. I'll have it up in a moment.

CMD Prompt: Well, how do you get it?

SYSTEM: No sweat, we're just searching for the appropriate resource section.

LOADER: Oh no. I thought I had a deserved rest coming.

SYSTEM: Sorry, just a little bit longer.

USER: WHERE'S MY WINDOW!!!!!

CMD Prompt: Keep your pants on. Just be glad you're not trying to create any threads.

LOADER: Okay, one last time. Which dialog template do you need loaded?

SYSTEM: I'm not sure. Let's try ACCESS.EXE.

LOADER: (struggling) Okay. There it is. I've searched ACCESS.EXE.

SYSTEM: Sorry. It wasn't in that one. Try MSO9.DLL's resources. Maybe it's in there.

LOADER: Okay. (grumble)

SYSTEM: Nope. It wasn't there either. Try MSOWCW.DLL.

LOADER: Look. I'm getting tired of this. Couldn't you just give me the complete list of resource sections to search? I'll keep searching them until we find that damn template. Exactly what dialog are we looking for?

SYSTEM: Not sure yet, all I have is a name, but it's probably something like "DLG_WelcomeToMSAccess".

LOADER: Well...

SYSTEM: Well what?

LOADER: That dialog?

SYSTEM: Oh yeah. Well ODBC32.DLL has just loaded ODBCCP32.DLL, and not to be outdone, MSJET40.DLL wants ODBCBCP.DLL, not to be confused with ODBCCP32.DLL, and MSO9.DLL wants MSOTHUNK.DLL, and RPRCRT4.DLL wants ADVAPI32.DLL, and lots of other guys are asking for ADVAPI32.DLL also - but I'm too smart for them. I'll just get it once and no one will ever know the difference.

LOADER: Working...

SYSTEM: And don't forget MSAEXP30.DLL. The dialog might be in there too.

CMD Prompt: OH NO!

SYSTEM: What is it?

LOADER: Are you all right?

CMD Prompt: An interrupt!

LOADER: An interrupt?

CMD Prompt: That's what I said, an interrupt.

LOADER: Stop what you're doing.

LOADER: Why? Just when I was getting the hang of it.

CMD Prompt: The user has typed ctrl-break.

LOADER: Okay, everything has been suspended. Can I go to sleep now?

CMD Prompt: No, you better stick around in case the user wants to continue. And notify the exit routines to stand by. Also, I need moral support. Maybe if I flash a ^C in front of his eyes, he'll stop looking so angry.

USER: Computer, I'm really getting tired of this.

CMD Prompt: But we were so close...

USER: A likely story.

CMD Prompt: Well what can I do for you instead?

USER: I still want my report. Let's try some other way of retrieving my data.

CMD Prompt: A wonderful idea sir! A finer day it couldn't be for looking over your data. How will you have it today? Sunny side up? Once over lightly?

USER: How about SCRAMBLED?

CMD Prompt: No problem sir. Wait one moment while I load OUTLOOK.EXE...

The curtain falls as the dance begins again...

[Caged Anger]

woa

[JIMINATOR]

nerd humor... :thumbs:

[EXEcution]

LOL The parts I understood were pretty funny.

"LOADER: I don't know. I just load'em. They tell me to load and I load." :D

I'm just wondering what exactly are DLL files and how do they work. From what I've read they are similar to .exe files but in what way?

[MassacreAL]

i dont know too, i know you can add them to your sorce code and use some functions in them, but dunno why it is like exe. yes, there is main function like in true exe, but dunno how to execute it or anything

[EXEcution]

i dont know too, i know you can add them to your sorce code and use some functions in them, but dunno why it is like exe. yes, there is main function like in true exe, but dunno how to execute it or anything
Maybe the executables files execute them since you can't run .dll files by just double-clicking on them.

[<<Hybrid>>]

Short for Dynamic Link Library, a library of executable functions or data that can be used by a Windows application. Typically, a DLL provides one or more particular functions and a program accesses the functions by creating either a static or dynamic link to the DLL. A static link remains constant during program execution while a dynamic link is created by the program as needed. DLLs can also contain just data. DLL files usually end with the extension .dll,.exe., drv, or .fon.

A DLL can be used by several applications at the same time. Some DLLs are provided with the Windows operating system and available for any Windows application. Other DLLs are written for a particular application and are loaded with the application.

Game cheaters injects own DLLs into original Game DLL with same values as it has and are able to change them inside memory whatever they like,,, and this way hey gets wallhacks, aimbots or whatever... for example if game is designed NOT to render player when its behind the wall, then hacker's DLL will allow client to render it...
Got it? :)

[MassacreAL]

everything i found is this http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/using_run_time_dynamic_linking.asp

but still dont know how to execute dll file with DllMain function(or whathever is it called)

[EXEcution]

Short for Dynamic Link Library, a library of executable functions or data that can be used by a Windows application. Typically, a DLL provides one or more particular functions and a program accesses the functions by creating either a static or dynamic link to the DLL. A static link remains constant during program execution while a dynamic link is created by the program as needed. DLLs can also contain just data. DLL files usually end with the extension .dll,.exe., drv, or .fon.

A DLL can be used by several applications at the same time. Some DLLs are provided with the Windows operating system and available for any Windows application. Other DLLs are written for a particular application and are loaded with the application.

Game cheaters injects own DLLs into original Game DLL with same values as it has and are able to change them inside memory whatever they like,,, and this way hey gets wallhacks, aimbots or whatever... for example if game is designed NOT to render player when its behind the wall, then hacker's DLL will allow client to render it...
Got it? :)
Awesome! Thanks Hyb I understand it much better now. :)
So DLL's can be made in Visual C++?

[MassacreAL]

So DLL's can be made in Visual C++?
yes, or in Borland C++ builder (which i prefer)

Hybrid if you wont mind i`ll catch you on msn, you have to tell me about dll injector you told me last time about, its great stuff ;)

[<<Hybrid>>]

okay
@exe: yes mate. Choose File>new Project > Dynamic Link Library > ok

[JIMINATOR]

you wouldn't write a dll file unless you were making a common library for a bunch of other programs to use. you use them, say if you are doing a VB or borland builder project, you don't include the library functions but instead reference a common dll. since most people already have them it makes your distribution code smaller.

note though what i had found in the past is that it makes the memory footprint HUGE! So if you only need a few library functions, that may increase your program exe by 100-200k. but loading the dll loads everything into memory, so that was 1.5 mb gone.

others here will go off about various application frameworks. you can do a tremendous amount very easily with them, but even if your program is tiny it will suck up a huge memory space when it runs.

[Die Hard]

I really enjoyed reading that :funny:

"The user has typed ctrl-break" <-----What can this be used for?

[MassacreAL]

I really enjoyed reading that :funny:

"The user has typed ctrl-break" <-----What can this be used for?
ctrl+break combination was used in DOS, and so you maybe know, in dos could be running only one program at same time. and if you press ctrl+break you terminate this program. at least i hope its true, i wasnt working in dos for ages

[<<Hybrid>>]

i'll keep that in mind Jim. I was never bothered with that actually as i am not a serious programmer, just a freelancer and still learning the basics, plus my memory is over 1GB,, so... what can i do,, just laugh at those 1.5MB :)
anyways maybe somebody has a time to explain getprocaddress and hooking process itself in noob way? becouse whenever i read professional tuts online they are allways full of professional expressions and whatsoever.. just a basic overview

[JIMINATOR]

sorry bud, you really need to get a book (or 10) if you are interested in windows programming.
i think for dlls, they can either be loaded automatically or on call. if the dll is not available for the automatic scenario, then the program will bomb, however it can do error handling with the on call method. the getprocaddress would be used to find a procedure at that point. an example used to be for dialup. there is a dll that handles the connection, winsock, tcpip stack, etc. well behaved programs would not have it as a requirement to run, but instead load it afterwards if they needed to make a dialup connection. there are probably better examples for today's times, as my experiences are probably from 8-12 years ago.

[JIMINATOR]

as for laughing at memory requirements, really that is not good. although many of todays languages are very powerful, they also encourage lots of sloppy and wasteful programming methods. that makes for programs that are slow and bloated. nobody cares any more, since computers are getting faster and memory cheaper, but it should be a concern. Way back in the days people used to write many fantastic games that could fit in a 4K memory space. Those days are long gone. Obviously you can't fit audio or visual content in such a small memory space, and that's fine. Assembly language is a long forgotten art. using one of these higher level languages will suck in lots of support libraries that makes a small program have a huge footprint. Really, if you have never coded in assembly language you would be surprised at how much you can do with how little. (the problem with assembly is interfacing to the OS/Libraries, also that it is difficult to read and maintain.... :) )

[<<Hybrid>>]

wow, ur a programmer? hah wouldnt ever notice that!
well, yeah you are true about them books. i have fair ammount of bookmarks to various ebooks, but never have time for at least one. Right now i am learning from 3dbuzz VTMs on C++ as well as conitecs A6 C scripting... Maybe in a time being i will prove mysleft at least a bit useful for something heheheh
anyways, yeh i perfectly understand what you mean with dial-up, but then again, at least i know what the theme is on about,, not like copy/paste code with some pro explanation and ur ready to go,,, understand it yourself lol. Or hello world with cout <<.. heh useless... no real explanation,,,
people understand better if they know what exactly happens, right? :)

[<<Hybrid>>]

God damnit,, yeh i allready saw ASM's tutorials... only numbers, numbers, numbers... some 10.5f > 24f i++ or whatever will do the job.. hehehe ( yeh i know its a c++,, but i think u know what i am moaning about here :D ) As i went trough unlimited tutorial forums, i noticed that process hookers actually uses ASM mostly, giving me only few variables and lots lots of digits... bah,, thats no use :-)

[EXEcution]

as for laughing at memory requirements, really that is not good. although many of todays languages are very powerful, they also encourage lots of sloppy and wasteful programming methods. that makes for programs that are slow and bloated. nobody cares any more, since computers are getting faster and memory cheaper, but it should be a concern. Way back in the days people used to write many fantastic games that could fit in a 4K memory space. Those days are long gone. Obviously you can't fit audio or visual content in such a small memory space, and that's fine. Assembly language is a long forgotten art. using one of these higher level languages will suck in lots of support libraries that makes a small program have a huge footprint. Really, if you have never coded in assembly language you would be surprised at how much you can do with how little. (the problem with assembly is interfacing to the OS/Libraries, also that it is difficult to read and maintain.... :) )
Coding in mnemonic code sounds kinda hard. From what I've been taught it's only one step up from binary (a BIG step but still) And I'm sure that there are plenty of low-level programmers who specialize in assembly language.

For the audio/visual though you can compress the crap outta them and fit them onto almost any size available. The only downside is that they will end up sounding/looking like crap. :)

[Death Engineer]

I use DLLs in my primary application at work. We use it to bridge between a C library (PortAudio) and our main application (PowerSDR) which is written in C#. In C#, accessing a DLL function is pretty easy. You simply reference the dll name and function and define the function with the appropriate parameters.

[<<Hybrid>>]

DE, can u atleast explain what exactly happens if i inject DLL into another process? does it destroys all memory that looks the same and let sme change values or something like that?

[Death Engineer]

Think of it as just another piece of compiled code. You call a funcion and it executes and spits out an answer. The only difference is that the compiled code is in the dll instead of in your exe. Do some googling. "DLL hell" (the pain of dealing with DLLs and versioning issues) is well documented.