I know that generally the object file has code, data, heap and stack sections.
But I want to know how this is arranged in windows executables and Linux executables.
I searched on internet and found some structure.
I understood .text is for code and .data is for global variables.
I want to know here is the stack and heap in both Linux and Windows platform?
Can anybody tell me the executable file structures??
Thanks in advance...
This is the specification that Microsoft has released:
http://msdn.microsoft.com/en-us/windows/hardware/gg463119
Also this is a good reading on the subject:
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
EDIT:
Stack/Heap are in-memory structures which are created/modified during run-time so in essence they are not in the file itself - they can't be. Think of them as a special place in memory where each and every program can store run-time data and by run-time data I mean variables. function invocations, return values and all the nitty-gritty stuff that are hapening on the low level.
Related
Is it possible to build a position independant code for windows ?
I am not talking about a dll, i am talking about an executable (PE).
What i want to do is that functions (main for example) which are in the program should be mapped at a different memory address between 2 executions.
Thanks
You should read up on the image base relocation directory in a PE file. I was wondering the same thing you are asking now a while back. From the research I had done I couldn't find any compiler that generates completely base independent code. I ended up writing my program entirely in x86 asm with some tricks to load strings etc independent form the address. I can tell you its not worth the trouble. Just remap all the addresses to your target location.
I suggest you start reading this
https://msdn.microsoft.com/en-us/library/ms809762.aspx
You should also check out Icezilon's (not sure how you spell his name) tutorials. They're very helpful
I have a question about calling the routine ZwReadVirtualMemory from my driver. I noticed it is not exported by ntokskrnl after dumping the EAT. How and where can I find the virtual address for this routine?
Is it located in the ssdt? if so, does not patchguard prevent me from reading there anyway? Or is that only for writing.
Also, this is for windows 7 x64.
Thanks!
ZwReadVirtualMemory is not exported from kernel. But you can find it in SSDT. Use ntdll trick. Don't worry about PatchGuard. It prevents only from code modification, reading is ok.
Also take into consideration that ZwReadVirtualMemory is not the only way to read virtual memory.
Bear in mind that SSDT on win 64 doesn't hold pointers to functions. It holds offsets which are relative to the start of nt!KiServiceTable. Also one of the viable ways of finding SSDT is to perform some sort of pattern scan in order to locate. Basically for 64 bits just forget with tinkering freely with the SSDT. For more information read this
Furthermore - patchguard is just for modification of system-critical components.
I am writing a scriptable game engine, for which I have a large number of classes that perform various tasks. The size of the engine is growing rapidly, and so I thought of splitting the large executable up into dll modules so that only the components that the game writer actually uses can be included. When the user compiles their game (which is to say their script), I want the correct dll's to be part of the final executable. I already have quite a bit of overlay data, so I figured I might be able to store the dll's as part of this block. My question boils down to this:
Is it possible to trick LoadLibrary to start reading the file at a certain offset? That would save me from having to either extract the dll into a temporary file which is not clean, or alternatively scrapping the automatic inclusion of dll's altogether and simply instructing my users to package the dll's along with their games.
Initially I thought of going for the "load dll from memory" approach but rejected it on grounds of portability and simply because it seems like such a horrible hack.
Any thoughts?
Kind regards,
Philip Bennefall
You are trying to solve a problem that doesn't exist. Loading a DLL doesn't actually require any physical memory. Windows creates a memory mapped file for the DLL content. Code from the DLL only ever gets loaded when your program calls that code. Unused code doesn't require any system resources beyond reserved memory pages. You have 2 billion bytes worth of that on a 32-bit operating system. You have to write a lot of code to consume them all, 50 megabytes of machine code is already a very large program.
The memory mapping is also the reason you cannot make LoadLibrary() do what you want to do. There is no realistic scenario where you need to.
Look into the linker's /DELAYLOAD option to improve startup performance.
I think every solution for that task is "horrible hack" and nothing more.
Simplest way that I see is create your own virtual drive that present custom filesystem and hacks system access path from one real file (compilation of your libraries) to multiple separate DLL-s. For example like TrueCrypt does (it's open-source). And than you may use LoadLibrary function without changes.
But only right way I see is change your task and don't use this approach. I think you need to create your own script interpreter and compiler, using structures, pointers and so on.
The main thing is that I don't understand your benefit from use of libraries. I think any compiled code in current time does not weigh so much and may be packed very good. Any other resources may be loaded dynamically at first call. All you need to do is to organize the working cycles of all components of the script engine in right way.
actually i want to make a long code but i have some trouble on some subroutines that are at the end of my code like the space i have is not enough, so i found something like breaking my code in sessions like .data .stack .model small etc. so breaking my code in sessions like these will give me a solution? how linker translate these sessions so that can work on long codes?
what kind of model types exist?
i am working with 8088, so if you know any 16 bit editor,compiler,debugger that i can use in windows i'd appreciate. thanx
Well, you have asked a lot of questions, but I suppose that the main question is how memory models work when it comes to compiling&linking of assembly code. Actually, I've no experience with 8088 processor, but I guess it's not very different than 8086, as it has to work in real mode.
OK, when you're writing an assembly code you've to choose memory model that your program is going to be in. It's done In your assembly by .model directive (AFAIR both TASM and MASM used it).
This directive can have following parameters: TINY, SMALL, MEDIUM, COMACT, LARGE and HUGE. Each of them defines memory model of your program. TINY memory model means that your code and your data are going to be one segment. Other models allow you to declare code & data in separate segments. Or even declare a few segments that contain code (in case they exceed 64KB limit). That'd be for a starter.
Now, having all that said, we need to be note that different memory models change the way we're addressing data. If you chose TINY memory model your code and data are in the same segment. But in SMALL model they are not. So all your ASM instructions that access DATA segment are to have proper segment register set (DS).
I have a question about how to store the assembly language in memory, when I compile the C-code in assembly, and run by "step", I can see the address of each instruction, but is there a way to change the start address of the code in the memory?
Second question is, can I break the assembly code into two?
That is, how to store the two parts in separate memory sections?
is there a way to do that?
I am curious about how the machine store the assembly code.
I am working on a MACBOOK Pro, duo core.
For the first question, can we change the offset value? or the linker and loader can not be controlled by the user? I am a litter confuse with your answer, it seems that we can not change it?
For the second question, I think what you are talking about is "input section", even if your have many ".text" input sections in your codes, after being assembled, they will become one ".text" "output section".
And the output section is the actual code stored in memory.
And I am wondering if I can control its position.
I am using the knowledge of DSP assembly, I think the mechanisms are same.
I'm not completely following either of your questions, but I'll guess.
For the first one, you're asking how to change where the executable is positioned in memory? ELF files have a preferred offset that the linker will try to use first, but the loader is usually free to position the sections anywhere if the base offset isn't available. If the image is non-relocatable and the preferred offset is unavailable, the loader will fail and the program won't run
As for your second question, you want to modify the assembly so code will be in different sections? How to do that depends on the assembler you're using; in gas you use the section pseudo-op:
.section new-section-name
The code following that directive will be in the specified section