Section flags

[Baboon]

Hi !

I would like to know something ...
Do GoAsm or GoLink have an option which permits to change the section flags ?

Readable / writeable / executable etc ..

I'm working on a self modifiing code and it's boring to have to change the section flags with LordPe at each compilation ...


[EDIT] : Does Goasm will be able to compile instructions like "retn 4*5" in the future ?
I often used this kind of instruction but GoAsm don't support it ...

but it compile these instructions :

#define _4fois5 4*5
retn _4fois5

:/

[Baboon]

I have found an other bug with Goasm
It compile : "push [esp + 4 + 3*4]" in "push [esp+0x1C]"
0x1C = 32 = (4+3)*4

:dazzled:

[wjr]

Not really a bug - from the Arithmetic section of the GoAsm manual:

GoAsm can perform limited arithmetic... in operands to code instructions... Arithmetic in brackets is carried out first, otherwise calculations are carried out in strict left-to-right order.

Once you know this, it doesn't take long to get used to other variations for the above:
push [esp + 4*4]
push [esp + 4*(1+3)]
push [esp + 4 + (3*4)]

[Baboon]

Thank you !
My apologize for this silly post ...

But I'm always interrested in the possibility of change the section flags, if anybody have an idea ..

[donkey]

Hi Baboon,

Even if you decide to over-ride the attributes of the CODE section, it will make little difference since Windows will not let you write to it anyway. You must do the override programmatically.

Donkey

[BlackVortex]

Wrong, also : Thread resurrection !

Anyway, I'm experimenting with making a simple crypter and I need ERW attributes in my code section, so I have to PE-edit my own executable after each asm+linking.   :(
It works fine if I do.

Other linkers, like polink and fasm allow specifying the attributes.

Ideas ?

EDIT: I could do a VirtualProtect, hmmm.
EDIT 2: How can I easily use polink instead of golink ?

[Ghandi]

Sorry to hijack the thread but i have a question that has bugged me since i read about it on the GoAsm website.

GoAsm automatically adds the attributes to suit the processor and Windows. A code section is given the attributes read, execute, code. A data section is given the attributes read, write, initialised data. A const section is given the attributes read, initialised data (you won't be able to write to a const section). Uninitialised data has the attributes read, write, uninitialised data.
Except to add the shared attribute, you can't override these attributes yourself. This is because to do so is pointless in the Windows system which has control over the attributes of the section as loaded and running. For example even if you give a code section the write attribute, Windows will not allow you to write to it. Also Windows will not permit you to execute code in a data section. You can change this behaviour however, by calling the API VirtualProtect at run-time.

Why is it that some people think that you have to programatically modify the attributes of a section to be able to write to it? I am speaking of MASM32 here but the same has been said about it, that you can specify that a section is writeable in its attributes but it wont allow you to write to it. This is just not correct! DEP might prevent executing data but a code section with a writeable flag permits writing, just look at any exe protector that uses self-modifying code.

The commandline switch "/SECTION:" enables us to set the flags, like: "/SECTION:/.text,erw". This will make the .text1 section writeable as well, without any further 'tweaks' or modifications. No access violations or crashes, unless you muff something up with your self-modifying code. Jeremy chooses not to allow it, from what i've read, but MASM32 allows you to set the section flag characteristics then the rest is up to Windows.

If you like using GoAsm however, you could always code it into your crypter so that it changes section characteristics when it crypts the code, unless you were planning on manually encrypting them each time?

HR,
Ghandi

[dedndave]

it would be simple enough to write a little app that would alter the PE header flags for a section
but, i figure it is best to enable writing to only the areas you intend to write to - not the whole code segment
i think there is a bit of a security issue if the whole segment is write-enabled
not to mention - it catches the programmers mistakes - well - my mistakes  :P
i have seen 0xc0000005 a few times - it is usually my fault

[Ghandi]

Agreed with the exceptions Dave, but that is the beauty of MASM, we can code whatever we like as long as we stick to the basic 'rules' which govern the Win32 environment. If we want to make an exe with a writeable code section we can, if we want to write a bloated executable we can, etc.

VirtualProtect isnt an exact thing to use either, it affects more than the requested memory unless it begins on a page boundary and ends before another ends:

Code Select Expand


The size of the region whose access protection attributes are to be changed, in bytes.
The region of affected pages includes all pages containing one or more bytes in the range from the lpAddress parameter to (lpAddress+dwSize).
This means that a 2-byte range straddling a page boundary causes the protection attributes of both pages to be changed.


So if we call VirtualProtect on a page beginning at 0x00401000, with a size of 0x1000, it will only affect the page from 0x00401000 to 0x00401FFF (according to MSDN)

But if we were to call VirtualProtect on 0x00401800, with a size of 0x1000, it will affect the page at 0x00401000 as well as the page at 0x00402000 which means that the minimum size affected with VirtualProtect is 0x1000 bytes and something as small as a 2 byte request can change the permissions of 2 whole pages. Once again, according to MSDN. I havent tested this myself thoroughly so i can't comment.

Still, for operations where writeability is only needed on a small section of memory, VirtualProtect would still be the better choice unless you're trying to obscure the fact you are changing code, imho.

HR,
Ghandi