OSDev.org

Here is the situation: I have found that simply using compilers and linkers isn't very beneficial for me to understand executables at a system level; so I have been coding a few EXEs completely by hand to better see the system behavior, and better and really grasp the workings of a system itself, be it Linux, Windows, etc, and then use that knowledge on my own. I need information on how to do this with ELF/Linux binaries for 32 and 64 bits.

I have been reading the ELF specification, but without much success.

Below I have attached 3 Win32 programs with source code.

They show what I can do until now:

- I can manually create the skeleton of a Portable Executable program fully using 32-bit NASM assembly and macros
- I can use icons (implying I used icon resources of the "rsrc" section)
- I can import functions from DLLs using the "import section", only WinAPI but presumably other "normal" DLLs
- I can use Unicode strings but have to code them manually (how is it supposed to be correctly done in an assembly or a C source file?)



This is what I need or can't do right now:

- I definitely don't know how to call things/frameworks/etc. specific to C++; how to implement it in assembly and/or which conventions? Where are they?
- I can't setup startup routines that handle command lines, etc.
- I cannot create DLLs
- I can't create drivers manually but need to do so, but don't know where to find information
- I understand the memory and heap usage only to a completely basic level
- I need this kind of information for ELF too, where to find it in such detail?

And most important: knowing what I have done and cannot do by now, what should be the next thing I should master, and that I can return later to show you the results and achieve progress?

By the way, I learned a lot about the PE format here:

TinyPE

And also thanks to Matt Pietrek articles, and the pecoff_v8 specification.

And this is the GWIOPM driver, which I am trying to duplicate, but by hand, to use it as a way to truly understand stuff fully and nearer to the "true" OS level:

http://www.grahamwideman.com/gw/tech/De ... gwiopm.zip
http://www.grahamwideman.com/gw/tech/De ... /index.htm

For instance, to use driver APIs and functionality, what DLLs, or exactly what and how should I import, etc?

I'll also try to publish information about what I've achieved with PE executables when I clear out a lot of misconceptions I have identified from what I documented in the process; although you can browse the included assembly NASM source code and their included precompiled binaries.

Why would you do that, in the first place?

I think reading ELF documentation is enough to understand whats going on.

Nah, I don't think he's that stupid. The 0.(9) != 1 claim, the thread about the USB spec, this, and many other posts have convinced me that the OP is a troll.

Hi ~ ,


You might find this interesting . http://www.muppetlabs.com/~breadbox/sof ... eensy.html

--Thomas

Nessphoro wrote:Why would you do that, in the first place?

I see that it's an excellent way to fully understand how executables work, because I would have to implement an "executable image interpreter" in a kernel-to-be sooner or later. And I can immediately test the results in an existing OS like Linux or Windows. Then the only thing to reimplement would be another API, and the rest of process/memory/OS functions to run the application, library or driver.

Nessphoro wrote:I think reading ELF documentation is enough to understand whats going on.

With previous experience sure it is. But maybe not, like in my case, where I have never achieved it successfully before. That's why I need a source code example of each binary type: Executable, dynamic/shared library, driver, etc..., that includes assembly source code for the full image header, file format structures, machine code and resources, to the point where only NASM is needed; and linkers, "external help" and the like are completely left out of this matter (that's what a kernel would need to do anyway).

Or at least pointers as to where to go, or what to learn next, given you now know what I can do in practice up to this point.

Thomas wrote:Hi ~ ,


You might find this interesting . http://www.muppetlabs.com/~breadbox/sof ... eensy.html

--Thomas

I think you're right. I had seen it before, but I will read it more seriously. Thanks.

My first impression was that the full program, along with the full structure of the ELF file wasn't presented (I wasn't even able to use assembly at that time); but giving it a new rapid look seems that it's there.

After that, only drivers, libraries, 64-bit executables and understanding the effects of each ELF/PE field would be left to do, I think.

I have been reading the ELF specification, but without much success.

You may want to read that specification again with an existing ELF file and a hex editor for reference, then you can see how things relate. ELF is much simpler (and for the same reasons, more powerful) in design when compared to PE. In contrast, windows deserved to be hacked and therefore gets much more attention on the level you seem to be looking for.

Then again, training the skill to read documentation is essential. The ELF specification is not as verbose or forgiving as, for example, the Intel manuals. At some point, you will have to learn to live with it because it scores pretty much average on worlds entire collection of documentation.

Try writing your own objdump and compare the output to the real one. You can do that in much smaller steps compared to having the entire file format correct before you can actually try it.