flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Main > Self-modifying COFF

Author
Thread Post new topic Reply to topic
donn



Joined: 05 Mar 2010
Posts: 52
Self-modifying COFF
Can I self-modify a

Code:
section '.text' code readable writeable executable

section in a COFF during execution?

For example, can I copy some instructions over into a function at a particular label? This seems possible during runtime, as long as I reserve enough space in the function.

Any limitations anyone is aware of?


Thanks!
Post 10 Mar 2017, 19:26
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 127
As long as the section is writeable, yes you can use self-modifying code.

I'm not aware of any "limitations" except that doing so often is slow (cache / pipeline flushing etc). But of course, if you do a rare change such as from a setting or input, the result could actually be faster if it's ran many times (no conditionals for that setting if you "hardcode" it into the code by modifying it). Just don't modify code within an inner loop or something Smile

I assume COFF is the PE executable right? (cause I've used self-modifying code on Windows binaries just fine...)
Post 10 Mar 2017, 23:14
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14463
Location: Eta Argus
Many AVs will panic when they see SMC. So there is that "problem" that you might encounter.

But otherwise the x86 CPU will do-the-right-thing and correctly handle SMC without a problem. Even the caches and pipelines are properly snooped and flushed when required.
Post 11 Mar 2017, 02:37
View user's profile Send private message Visit poster's website Reply with quote
donn



Joined: 05 Mar 2010
Posts: 52
Awesome! That's certainly a valid concern regarding the inner loops. Copying the instructions is a lot different from conditions and addressing.

MS COFF is Windows, Common Object Format I think, linkable also. Yes. I was a bit worried the x86 might perform some modifications of its own or cache incorrectly and get confused.

Will try this soon...
Post 11 Mar 2017, 16:14
View user's profile Send private message Reply with quote
Xorpd!



Joined: 21 Dec 2006
Posts: 160
I am myself curious as to your results, although unfortunately too lazy to check just now. I thought that if you linked a bunch of *.OBJ files together that all segments with the same name got concatenated into a single segment.

But does that mean that your segment becomes no longer writeable because it's linked with other non-writeable segments or that that other segments become writeable thus creating a security hole?

In Windows you can map pages as writeable at run-time with VirtualAlloc and VirtualProtect. In 32-bit Windows you can link the FASM.DLL into your application and assemble code at run-time as well. No such luck in 64-bit Windows.
Post 12 Mar 2017, 16:05
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14463
Location: Eta Argus
All linkers I've used will not merge sections that are not the same is all respects. So if you have differing write-permission flags then you get two sections.
Post 12 Mar 2017, 16:21
View user's profile Send private message Visit poster's website Reply with quote
Xorpd!



Joined: 21 Dec 2006
Posts: 160
I didn't know that. I tried an example *.OBJ file:

Code:

format MS64 COFF

section '.text' code readable writeable executable
public test1
test1:
   mov RAXtest2
   ret

section '.text' code readable executable
public test2
test2:
   mov RAXtest1
   ret

section 'stuff' code readable executable
public test3
test3:
   mov RAX100
   ret

section 'more' code readable executable
public test4
test4:
   mov RAXtest3
   ret



So when you call test4 it gives you a pointer to the code of test3 and when you call test1 it gives you a pointer to the code of test2. Using these pointers to copy the test3 code into test2, the program crashes. However, if we instead call test2 first to get a pointer to the code of test1 and then copy the code of test3 into test1, the program runs and test1 now returns 100. So this worked with LINK.exe, although it whines with a LNK4078. Nice to know Smile
Post 13 Mar 2017, 05:09
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14463
Location: Eta Argus
There might be some command line switches that allow forcing the merge? But would it use the most restrictive or the most permissive setting for the flag?
Post 13 Mar 2017, 05:17
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.