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

21–30 of 61 posts

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

#21

Post by woliveirajr »

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 bet it would be the next level (if it doesn't exists already) to be used by top-level agencies, or by bad guys.

Some code already found in the wild couldn't be decrypted (e.g., stuxnet), has obfuscated connection (e.g. https://news.ycombinator.com/item?id=18864895) and is updated as needed (any C&C that sends new modules to the infected machine). Add some capability to self modify and you can have hard times generating signatures ou behaviours that are traced by "antivirus", firewall, and so on.

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

#22

Post by [deleted] »

benj111 wrote: post #10
AnanasAttack wrote: post #7

Earlier quoted context omitted.

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?

Some (most?) of the problems with c stem from not checking array bounds. Now if you break out of an array bound in read only memory, you cant do much damage, but what happens if you could rewrite the code to do what you want? Theres also the issue that you can have viruses that hide what they're doing until they actually run, so virus scanners cant pick them up. I'm no expert. There maybe other classes of attack.

[deleted]

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

#23

Post by masak »

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?

The (old) MIX programs in The Art of Computer Programming by Knuth were often self-modifying, in the sense that they modified jump addresses at the end of routines to return to the right caller. (That is, they set the address to right after the call.)

The book chose that way to do it because it was standard practice at the time. It quickly fell out of fashion, though. Nowadays, we do it with a call stack, and each stack frame holds a return address. (Which is better anyway, since it allows routines to be re-entrant.)

The newer MMIX architecture (in some of the newer books) don't rely on such self-modification.

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

#24

Post by zozbot123 »

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?

It's not hard to reason about from a formal POV-- by "self-modifying" code, you're basically editing the continuation of the current function/statement. It's just not very useful-- by definition, the extra performance that you might gain from directly self-modifying the program's binary code can't be any higher than the overhead of a good interpreter/JIT. That's just not interesting.

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

#25

Post by JoachimS »

shakna wrote: post #8
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?

Any _good_ reason? Probably not. Any use? ... Yes. Obfuscation. It might be a terrible practice, but has spawned entire languages, including some that have been used on occasion by industry, as well as the puzzle-solving community at large. (Say, integrate it into a `compile --release` flag.) Right off the back of obfuscation, DRM. If the code modifies itself, especially in unexpected ways, then breaking it becomes h…

A lot of the later demo effects on the c64 is using so called "speedcode" which basically is code generating code on the fly to achieve things like dynamically copying data areas. In effect intelligent loop unrolling i asm.

http://codebase64.org/doku.php?id=base:speedcode

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

#27

Post by monocasa »

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?

Microsoft has stubs for self modifying code in their libraries to patch over compat issues.

https://blogs.msdn.microsoft.com/oldnewthing/20110921-00/?p=...

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

#28

Post by rootbear »

I once read about a clever use of self-modifying x86 code. The 8086 and 8088 are nearly identical chips, with the difference being that the 8086 has 16-bit I/O and the 8088 has 8-bit. The only way for a program to know which chip it's running on is to write a bit of self modifying code that takes advantage of this difference in I/O size. Both chips use prefetch, but they prefetch words, not bytes, and 8086 words are 16-bit, so it fetches twice as many bytes as the 8088. Thus, one can modify a location in RAM just after the current instruction and that change will be seen on the 8088, but not the 8086, which has already prefetched the previous value.

This is all from memory of something I read, probably on Usenet, ages ago. My apologies in advance if I messed up the details.

I wonder if any of the various x86 emulators out there get this difference right.

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

#29

Post by tyingq »

rootbear wrote: post #28

I once read about a clever use of self-modifying x86 code. The 8086 and 8088 are nearly identical chips, with the difference being that the 8086 has 16-bit I/O and the 8088 has 8-bit. The only way for a program to know which chip it's running on is to write a bit of self modifying code that takes advantage of this difference in I/O size. Both chips use prefetch, but they prefetch words, not bytes, and 8086 words are…

I think you probably read it in Dr Dobbs: http://www.drdobbs.com/embedded-systems/processor-detection-...

Not exactly what you described, but very similar:

"Differentiating between 8088s and 8086s is trickier. The easiest way I've found to do it is to modify code that's five bytes ahead of IP. Since the prefetch queue of an 8088 is four bytes and the prefetch queue of an 8086 is six bytes, an instruction five bytes ahead of IP won't have any effect on an 8086 the first time around"

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

#30

Post by rootbear »

tyingq wrote: post #29
rootbear wrote: post #28

I once read about a clever use of self-modifying x86 code. The 8086 and 8088 are nearly identical chips, with the difference being that the 8086 has 16-bit I/O and the 8088 has 8-bit. The only way for a program to know which chip it's running on is to write a bit of self modifying code that takes advantage of this difference in I/O size. Both chips use prefetch, but they prefetch words, not bytes, and 8086 words are…

I think you probably read it in Dr Dobbs: http://www.drdobbs.com/embedded-systems/processor-detection-... Not exactly what you described, but very similar: "Differentiating between 8088s and 8086s is trickier. The easiest way I've found to do it is to modify code that's five bytes ahead of IP. Since the prefetch queue of an 8088 is four bytes and the prefetch queue of an 8086 is six bytes, an instruction five bytes a…

Ah, thanks, you're probably right about where I got it from.
Post reply on HN