(Then, there's my contribution: NISC -- the Null Instruction Set Computer! It's a revolutionary architecture, in that die sizes and TDP can be scaled down, seemingly arbitrarily, with no loss in functionality. In fact, NISC can transcend the solid state entirely, and be implemented directly on the quantum foam of the vacuum!
Another benefit: NISC machines are entirely immune to all buffer overflow and use after free exploits! In fact, they are free of all exploits, whatsoever!)
That's just the "wrong" spin! NISC computers exhibit the same performance characteristics under DDOS attacks of immense scale. Increase the scale of the DDOS attack, and the performance graph remains flat! And by flat, I don't mean with a small slope or slight wobbles. I mean completely flat!
> Things attackers can't do only matter if they'd need to do them.
BUT, by the same token, things attackers can do don't matter either! NISC computers: So advanced, they make all attackers meaningless!
> Q: Why did you make this? A: I thought it would be funny.
But if you look at the serious attempts to implement OISC, you'll find that the "single instruction" has so many parameters, some might think it might as well be a big family of instructions.
Yea this isn't a true OISC setup, but it's very close and still completely impressive that this technique even works. That you can influence all necessary registers like this and accomplish arithmetic isn't immediately obvious.
> This is thought to be entirely secure against the Meltdown and Spectre CPU vulnerabilities, which require speculative execution on branch instructions.
> The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.
1. This is the simplest one - if the memory being accessed is in a cache (L1/L2, or page in TLB), the function will take a significantly shorter time to execute. If movfuscator achieves conditional execution by manipulating index registers to perform idempotent operations, this will be very easy to detect.
2. Prefetching - if movfuscator reads memory sequentially with a detectable stride, prefetching will shorten the execution time.
3. Write combining - if the code writes to nearby addresses (same cache line), the CPU will combine them to a single write. This will cause a measurable timing difference.
EDIT: One more: Store forwarding - if the code writes to a memory address and reads it soon, the CPU may bypass the memory access (and even cache access) completely.
I wonder what the final binary sizes are in comparison to normal GCC compilation, as well as execution speed.
I can't believe you made a floating point emulator just for this as well! Quite impressed.
That being said, if this can increase difficulty of sidechannel attacks and branch prediction, maybe it'd actually make sense for very isolated parts of some services.
I agree, I can see how it certain special circumstances/services this could be very useful.
However, I still expect someone to compile Quake with it by the end of the year.
If mov is Turing Complete it seems like there'd be a big win here... You could parallelize this massively.
Edit: can someone explain why this is being down voted please, because this is a legit question
I'm asking because I don't know; can you elaborate on why that is?
Aren't most modern GPUs similar in that they're designed to just shit out triangles as fast as possible, massively parallel?
Might as-well suggest we use a single letter, instead of 26.
..... .. ..
.. .. .. ..
.. .. ....
.. .. .. ..
..... .. ..
............. ......... ....... ........ ....................
....................... ............... ................. ...........
(Also no, GPUs are not the same at all)
Exactly such an idea was proposed for parallel signal processing quite a while back, actually. Look up One Instruction Set Computer.
> The disadvantage of an MISC is that instructions tend to have more sequential dependencies, reducing overall instruction-level parallelism.
Actually, One Instruction Set Computers were proposed for this very application! (Also mentioned elsewhere, but is applicable in a serious way here.)
TL/DR obfuscation by translating a program to "mov" instructions is susceptible to static analysis and thus fully reversible.
Care to elaborate? The author of Movfuscator is very experienced and capable at reverse engineering. In one of his video talks he hits some Movfuscated code with some tools and says he doesn't know of anything that can deobfuscate it. That may have changed since then -- I'd be curious to know.