questiona about exe (again)

[fir]

some times ago it was discussed and i know thet here are probably not much many people knowing that things but maybe some

if you load exe program into memory it is typically loaded under adress 0040_0000 (which is 4 MB skiping from begining)

header is typically loaded under 0040_0000,
code is typically loaded under 0040_1000, and data is loaded after that (in small hello worlds it will be 0040_2000),
consts after that, static empty ram area is reserved after that, then imports and other sections also somewhere after that

still i am not sure as to one thing.. in exe
i think you dont necessary need relocations
(or am i wrong?) So this would mean that in
such exe adresses may be fixed (and they in fact would have some values like 004x_xxxx and so on (may be obviously bigger but in small exe this kind of values))

is this really the case? no relocations and this kind of fixed values there?


<yet maybe second a bit more hard of this question -> if realocations are present are
they only a list of adresses in ram where you need to add "base adress" of image (as i heard) or yet something other to that?>

tnx

[Alf P. Steinbach]

Visual Studio projects default to using randomized load addresses. It's
a Windows loader feature. Things can end up pretty much anywhere, in
order to foil hackers' attempts.


Cheers & hth.,

- Alf

[fir]

i dlls - but i talk on exes here (need to know that as i write my own simple basic x86 assembler that wuld flush to disk only exes right now)

[Vir Campestris]

On 19/08/2017 13:12, fir wrote:
> W dniu sobota, 19 sierpnia 2017 14:02:57 UTC+2 użytkownik Alf P. Steinbach napisał:

<snip>

>> Visual Studio projects default to using randomized load addresses. It's
>> a Windows loader feature. Things can end up pretty much anywhere, in
>> order to foil hackers' attempts.
>>
>>
> i dlls - but i talk on exes here (need to know that as i write my own simple basic x86 assembler that wuld flush to disk only exes right now)

No, it applies to EXEs too.

You can link DLLs to fixed addresses; but that reduces their usefulness
as the address may not be available in all programs.

AIUI you don't _have_ to write the relocation records, but your program
will be less secure. Randomised load addresses defend against some kinds
of malware, especially buffer overflow attacks.

Andy

[fir]

well i think if you would like to get
exe able to be realocated you would need to update a lot of internal references (all references reaching to .code .data .bss .consts and even .imports meybe even yet some)

im not sure hovewer if in present assembly such adressing is non-relitive it is like real 004X_XXXX
pointers or some amount is by reliative offsets pointing back or forward?

with all that relative adressing you could move all axe up and down virtual
ram sopace and that would work with no
any fixups (it is not needed however,
im not quite convinced that this movin
is really needed)

relative adressin btw would be usefull mostly probably when one would need to optimise code for size, in that case relative adressing would reduce code size but probably in todays x86 reality it is not practical


could someone remember me: as far as i remember calls are non-relative (fixed adress).. but what with loops, when code makes loop is this conditional jump rather to fixed adress or relative -N byted back? same with ifs, do they -+M bytes back/forward or are they rather to fixed code adress?

[fir]

note some curiosity - as far as i know
from that above (i mean i know that
pe file is loaded and mapped under
0x0040_0000 in memory (where exe header
is alos mapped afaik

by something like

int * p = 0x00400077; //check real adres in PE docs
printf("stack size %d", *p);

you could acces to quite usable though hacky information on your program without usage of no api at all

im not sure as to this but probably, for example you could be able to dump
binary of teh code by starting from
0x00401000 and so on

ps. without checking the pe heder and found at which offset what info is i quickly tested if i will find 'MZ' at
0x00400000

int main()
{

char* a = (char*) 0x00400000;
printf("%c%c", *a, *(a+1));

retirn 0;
}
output: MZ , there is

[Bo Persson]

On 2017-08-20 23:14, fir wrote:
> note some curiosity - as far as i know
> from that above (i mean i know that
> pe file is loaded and mapped under
> 0x0040_0000 in memory (where exe header
> is alos mapped afaik
>
> by something like
>
> int * p = 0x00400077; //check real adres in PE docs
> printf("stack size %d", *p);
>
> you could acces to quite usable though hacky information on your program without usage of no api at all

But why?

You can get stack info by calling GetCurrentThreadStackLimits and see
exactly where the stack is allocated.



Bo Persson

[fir]

to undestand internals - whot is very good..
those people denying this are - like i probably could say - like those all homofobs and racists who deny other kind of truth (that being racist or homofobe has big elements of being nonsense).. thus should i call em 'internalfobs' or what?

[fir]

to quote Kurt Cobain ->

'living with internalfobs, oh no'

[Vir Campestris]

On 20/08/2017 21:47, fir wrote:
> well i think if you would like to get
> exe able to be realocated you would need to update a lot of internal references (all references reaching to .code .data .bss .consts and even .imports meybe even yet some)
>
> im not sure hovewer if in present assembly such adressing is non-relitive it is like real 004X_XXXX
> pointers or some amount is by reliative offsets pointing back or forward?
>
> with all that relative adressing you could move all axe up and down virtual
> ram sopace and that would work with no
> any fixups (it is not needed however,
> im not quite convinced that this movin
> is really needed)
>
> relative adressin btw would be usefull mostly probably when one would need to optimise code for size, in that case relative adressing would reduce code size but probably in todays x86 reality it is not practical
>
>
> could someone remember me: as far as i remember calls are non-relative (fixed adress).. but what with loops, when code makes loop is this conditional jump rather to fixed adress or relative -N byted back? same with ifs, do they -+M bytes back/forward or are they rather to fixed code adress?

I don't recall whether all the call instructions on x86 are absolute,
but I'm pretty sure some of the jumps are relative and some absolute.
Bit you ought to be looking at x64 anyway - the 64 bit extended
architecture - which has many more addressing modes. x86 is NOT todays
reality for most purposes.

And you really need to take this to a group that deals with the process
and operating system you are interested in. I write cross platform C++,
and I certainly do NOT know the answers to those questions on all the
processors I use.

Andy

[fir]

you shouldnt envelope whorter meanings in longer words in what you wrote only two first lines were meaningful, (where you said its PROBABLY mixed), well maybe it is mixed i will inspect it some day (seem not much important anyway)