Writing a Self-Mutating x86_64 C Program (2013)
shanetully.com
Writing a Self-Mutating x86_64 C Program (2013)
1–10 of 61 posts
Re: Writing a Self-Mutating x86_64 C Program (2013)
#2Are 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?
Re: Writing a Self-Mutating x86_64 C Program (2013)
#3Are 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?
JIT languages already do this.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#4Are 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 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.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#5Are 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? JIT languages already do this.
JIT languages don't use self-modifying code, they generate new code at runtime and execute that.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#6Are 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 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.
Yes, I was thinking historical examples. When such things were a concern.
Don't forget there can be code size gains also.
BTW I think all modern processors have instruction caches. In ARM it might not automatically flush?
Re: Writing a Self-Mutating x86_64 C Program (2013)
#7Are 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 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?
Re: Writing a Self-Mutating x86_64 C Program (2013)
#8Are 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 harder. (`compile --protect`?)
Re: Writing a Self-Mutating x86_64 C Program (2013)
#9Are 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.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#10Earlier 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?
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.