OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:35 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Executable Loader Assistance
PostPosted: Mon Jun 05, 2017 8:12 pm 
Offline

Joined: Mon Jun 05, 2017 5:01 pm
Posts: 2
I'm trying to learn more about all of the duties that an executable Loader is charged with performing generally and the order in which it might perform them. I am not currently building my own OS (yet), however I am a malware analyst and malware often screws with the executable format and it's headers to thwart analysis, detection, and/or even to prevent it from loading on some machines and not on others.

The thing is, there's a ton of documentation out on the Windows PE file format but obviously as it's closed-source, there is not a lot about the PE loader other than what's in the book Windows Internals. I figured, in order to get this figured out, I could try and learn about writing my own exec loader (and write one if it's feasible).

What I do know is that it essentially reads metadata about the file, uses that metadata to allocate stack/heap memory, static memory, set up the sections and eventually hooks execution into a thread at the code entry-point. I even know quite a bit about the PE format and its structs, but w/o knowledge of the loading process, I'm half-blind. One of the questions I have is, is an OS exec loader its own "module" or is it just a collection of routines which are generally found in the kernel that happen to be involved in the process? Feel free to link or suggest relevant material and please excuse my ignorance. I'm new but I love assembly and C so I'm happy to be here.


Top
 Profile  
 
 Post subject: Re: Executable Loader Assistance
PostPosted: Mon Jun 05, 2017 8:18 pm 
Offline
Member
Member
User avatar

Joined: Sat Dec 27, 2014 9:11 am
Posts: 901
Location: Maadi, Cairo, Egypt
If your question is how the kernel itself loads executables, i.e. how does the kernel executable loader work, I'd say that this loader should be built-in to the kernel binary itself, regardless of the kernel's design. For a monolithic kernel, it would be common sense to have as much as possible inside the kernel. For a microkernel, this should also be inside the kernel's binary, as the system will move as many things as possible to user mode and thus requires a way to execute modules; this would be the executable loader.

So all in all, the kernel's executable loader should be built-in to the kernel binary for any kernel design choice. Without it, probably no other modules can be loaded.

If you want some code to look at for a PE loader, then maybe you can take a look at React OS. It's free and open source, and aims to be binary compatible with Windows.

_________________
You know your OS is advanced when you stop using the Intel programming guide as a reference.


Top
 Profile  
 
 Post subject: Re: Executable Loader Assistance
PostPosted: Mon Jun 05, 2017 9:11 pm 
Offline

Joined: Mon Jun 05, 2017 5:01 pm
Posts: 2
Like this: https://svn.reactos.org/svn/reactos/tru ... iew=markup ???

Thank you sir! Definitely never would have found that if it weren't for what you just told me. :)


Top
 Profile  
 
 Post subject: Re: Executable Loader Assistance
PostPosted: Tue Jun 06, 2017 10:52 am 
Offline

Joined: Sun Apr 16, 2017 4:45 pm
Posts: 6
mainscreenturnon wrote:

That's the boot loader. Since ntoskrnl.exe is a PE binary itself, you need a PE loader before the kernel is loaded to load the kernel. The actual PE loader used when the OS is up and running can be found here:

https://svn.reactos.org/svn/reactos/tru ... iew=markup


Top
 Profile  
 
 Post subject: Re: Executable Loader Assistance
PostPosted: Tue Jun 06, 2017 12:03 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Note also that for most designs in which memory protection is used, even a user-space loader needs to invoke the kernel in order to set the loaded code as executable (and, in almost every case, read-only). This is especially common for virtual memory systems with multiple address spaces.

In fact, if there are no internal relocation patches to be handled, most loaders don't actually load the executable code themselves at all, but instead tell the kernel to treat the .text section(s) of the file as a set of executable swap pages. The virtual memory system handles the actual loading and unloading, using the same mechanism that it would for any page fault (though it usually does have a way to have it load at least part of code without actually triggering a page exception, for the sake of performance).

For multiple-address-space systems, this obviates most of the need for load-time relocation patching in the first place, because it can simply map the executable's entry point to address zero in the current process' memory map. This means that the compiler or assembler can generate absolute addresses for modules that are entry points without needing to mark any relocation information. Relocation of static libraries can be resolved during linking to form a single executable image.

If a shared library uses relative addressing exclusively (or dynamically resolves non-relative addresses through a pointer table), then the library image (regardless of whether it is in memory already or not) can then mapped to wherever the program expects it to be, too.

I mention this less for the OP's sake (if they are a malware expert, they probably already know this) as for that of those searching the forum in the future. It is something a lot of people fail to understand - I certainly didn't for the longest time - so it can use some explication. Comments and corrections welcome.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Executable Loader Assistance
PostPosted: Tue Jun 06, 2017 5:54 pm 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
omarrx024 wrote:
I'd say that this loader should be built-in to the kernel binary itself, regardless of the kernel's design. For a monolithic kernel, it would be common sense to have as much as possible inside the kernel. For a microkernel, this should also be inside the kernel's binary, as the system will move as many things as possible to user mode and thus requires a way to execute modules; this would be the executable loader.

So all in all, the kernel's executable loader should be built-in to the kernel binary for any kernel design choice. Without it, probably no other modules can be loaded.

If a micro-kernel aims to move as much as possible to user processes, instead of having stuff in the kernel, then why would the process loader be an exception? In practice everyone decides how much to move back to micro-kernel for performance considerations, but I can't see a reason why the loader must or even should be in the micro-kernel. For monolithic it probably is natural to have it in the kernel.

As for the OP, this (free) Linkers and Loaders book may be of some interest: http://www.iecc.com/linker/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 76 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group