Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Self-Mutating x86_64 C Program (2013)

shanetully.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Writing a Self-Mutating x86_64 C Program (2013)

#11

Post by saagarjha »

AnanasAttack wrote: post #7
saagarjha wrote: post #4

Earlier quoted context omitted.

The real issue with self-modifying code is that it's basically a security bug waiting to happen, plus you have other complications like having to flush the instruction cache on architectures like ARM. Generally, the benefits are not worth it unless except for very specific cases.

I've seen points like these made before, but never really understood how. Can you give an example of self-modifying code becoming a security issue?

Self modifying code is not a security issue in and of itself, but it requires memory that is writable and executable (though, not necessarily at the same time). This is usually a bad idea because it makes arbitrary code execution much easier if your code has unrelated bugs in it, because it provides attackers a place to write shellcode and get it to run.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#12

Post by benj111 »

pantalaimon wrote: post #9
benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

> Are there any languages that could actually make use of self modifying code? Kernel livepatching (and by that ftrace) would come to mind.

Would they not just write a new patched page, and swap out the original?

Seems less error prone?

Re: Writing a Self-Mutating x86_64 C Program (2013)

#13

Post by bloak »

saagarjha wrote: post #5
AnanasAttack wrote: post #3

Earlier quoted context omitted.

>Are there any languages that could actually make use of self modifying code? JIT languages already do this.

JIT languages don't use self-modifying code, they generate new code at runtime and execute that.

Sometimes they will also make small changes to code that was generated earlier, typically by changing a branch instruction to point somewhere else.

Dynamic linkers may do that, too, though glibc doesn't normally do it, as far as I know: it prefers to update a pointer to code: same result without needing memory that is both writable and executable and without having to invalidate the instruction cache.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#14

Post by pjc50 »

benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

Self-modifying Lisp, perhaps? Do Turing tapes count?

Really the main use of these techniques (and the article has a telltale in its use of the word "shellcode") is injecting code into a program that was not originally intended to be modifiable. Usually (although not always) across a security boundary.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#15

Post by benj111 »

pjc50 wrote: post #14
benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

Self-modifying Lisp, perhaps? Do Turing tapes count? Really the main use of these techniques (and the article has a telltale in its use of the word "shellcode") is injecting code into a program that was not originally intended to be modifiable. Usually (although not always) across a security boundary.

Turing tape, good point! Now where's my infinitely long piece of paper...

By self modifying lisp, I take it you mean modifying the lisp data (/code? (/data?)) structure itself? On a lisp machine would that count as self modifying???

Re: Writing a Self-Mutating x86_64 C Program (2013)

#16

Post by benj111 »

bloak wrote: post #13
saagarjha wrote: post #5

Earlier quoted context omitted.

JIT languages don't use self-modifying code, they generate new code at runtime and execute that.

Sometimes they will also make small changes to code that was generated earlier, typically by changing a branch instruction to point somewhere else. Dynamic linkers may do that, too, though glibc doesn't normally do it, as far as I know: it prefers to update a pointer to code: same result without needing memory that is both writable and executable and without having to invalidate the instruction cache.

From my delve into such things, in Linux at least the linker is a binary called before the program runs, so its a separate program potentially modifying the code. Interesting philosophical question whether that's still self modifying though.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#17

Post by SomeHacker44 »

benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

LISP macros are compile time self modifying code. So are many other macro systems.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#18

Post by benj111 »

benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

I may have found an esolang that is selfmodifying. Although there are probably many many more.

Befunge:

https://esolangs.org/wiki/Befunge

Re: Writing a Self-Mutating x86_64 C Program (2013)

#19

Post by pjc50 »

benj111 wrote: post #15
pjc50 wrote: post #14

Earlier quoted context omitted.

Self-modifying Lisp, perhaps? Do Turing tapes count? Really the main use of these techniques (and the article has a telltale in its use of the word "shellcode") is injecting code into a program that was not originally intended to be modifiable. Usually (although not always) across a security boundary.

Turing tape, good point! Now where's my infinitely long piece of paper... By self modifying lisp, I take it you mean modifying the lisp data (/code? (/data?)) structure itself? On a lisp machine would that count as self modifying???

Yes, that was to some extent the point of using the same representation for code and data (homoiconicity) in Lisp - the ability to edit the code from inside itself. I'm not sure how widely this is used outside the macro system and development environments.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#20

Post by benj111 »

SomeHacker44 wrote: post #17
benj111 wrote: post #2

Are there any languages that could actually make use of self modifying code? Machines wouldn't have the same problems reasoning about it as humans would. Or is it a question of compilers not being good enough until processor tech made the optimisation not worth it?

LISP macros are compile time self modifying code. So are many other macro systems.

Yes, but so are C macros.

I mentioned lisp machines in a prior answer, I don't know enough about them to say whether they would allow self modifying lisp code though.

Post reply on HN