Movfuscator – A single-instruction C compiler | Hacker News Reader

Movfuscator – A single-instruction C compiler

github.com

191 pointsvasili11153 comments

Previously on Battlehacker Newslactica: https://news.ycombinator.com/item?id=10021259

Saw this recently after reviewing some Defcon 23 videos. The author goes into detail about how it's working and some other fun stuff regarding anti-reverse-engineering.

2015 DEFCON 23 - Chris Domas - Repsych: Psychological Warfare in Reverse Engineering https://www.youtube.com/watch?v=HlUe0TUHOIc

And a paper by him: https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

See also: Demovfuscator

https://kirschju.re/demov

Since we are joking, assuming that the MOV instruction exists on many CPU's, could the input for this compiler be considered a needed "portable assembly language"?

http://cr.yp.to/qhasm/20050129-portable.txt

I wonder what happens to performance of same code.

For large applications performance will undoubtedly nosedive.

Yep one might just write some key verification code in it but keep rest of the app in GCC

Some slides here: https://recon.cx/2015/slides/recon2015-14-christopher-domas-...

Not sure I understand how that is possible. How would you implement a boolean "and" with only "mov"? If you can only move stuff around, how do you read and compare things?

If you look at turing machines they're pretty minimal, just a state machine reading/writing state on a tape

Repo includes a good set of slides: https://github.com/xoreaxeaxeax/movfuscator/blob/master/slid...

Indirect memory accesses serve for conditional execution

Here's the macro for boolean and: https://github.com/xoreaxeaxeax/movfuscator/blob/master/poc/...

You should be careful with this, you'll wear a hole in your instruction set.

Dumb question, could that actually happen? Could you actually use a particular set of transistors so much with this that they break?

This wouldn't do any noticeable damage. Modern CPUs have excellent thermal management. As far a wear goes, a hot spot in chip would in theory slightly decrease the long life span of a CPU.

If you expanded your question to hardware in the computer, then yes you can easily cause damage. BIOS’s can be flashed to make the system unbootable or overclock/stress components. Back in the bad old days of Linux, you could easily damage your monitor with the wrong xorg.conf settings.

Your question got me thinking what’s the MTBF of modern CPUs? My google-fu failed me finding any reliable source of this, but I’m sure it’s long, 10+ years.

> Back in the bad old days of Linux, you could easily damage your monitor with the wrong xorg.conf settings

You could also damage a floppy drive making it read/write, for many times, few sectors outer the common limits. Being there, done that.

But after so many discussions on online forums that it was impossible to cause physical damage using software (other than overwriting firmwares), I gave up and kept this (and the asm code) deep inside my heart.

And bringing it up still gives me chills that those discussions will return right now...

Sounds close to

http://www.catb.org/jargon/html/W/walking-drives.html

Your question got me thinking what’s the MTBF of modern CPUs? My google-fu failed me finding any reliable source of this, but I’m sure it’s long, 10+ years.

Probably decreasing, and soon not much longer than warranty period... the transistors have gotten so small that they're on the threshold of barely working even in normal operation.

As for older CPUs, they could definitely last many decades because of the lower stresses of larger process sizes, and they were designed with much higher margins.

Do you have anything to back this up?

According to the paper linked in another comment (https://news.ycombinator.com/item?id=12373015), apparently the high-k dielectric nodes used at 45nm and below show ~5x times worse NBTI ageing than non-high-k 45nm PMOS gates, which decides the tolerances that are selected to provide X years of life.

(IANAEE)

Back in the bad old days of Linux, you could easily damage your monitor with the wrong xorg.conf settings.

Back when a certain kind of line printer was commonplace (has a circulating ribbon with the typeface repeated, and n hammers in a line going across the entire width) programmers could sabotage the printer by printing the pattern on the ribbon. This would cause all of the hammers to fire at once, which the machine wasn't designed to withstand.

I've also heard of monitors being broken by having the speaker output the resonant frequency of the glass cover. However, I can't vouch for this one.

Sounds I'll never forget:

* Modem

* Dot matrix printer

* DEC Line printer

    > Back in the bad old days of Linux, you could
    > easily damage your monitor with the wrong
    > xorg.conf settings.

Nit: Back in the old days of Linux there was no xorg.conf, it was called XF86Config

I could never, and I mean never, get a XF86Config to work. Totally turned me off of Linux.

>what’s the MTBF of modern CPUs? My google-fu failed me finding any reliable source of this, but I’m sure it’s long, 10+ years.

It's so long that probably nobody bothers to measure it.

Yes, but you probably need something more sophisticated than just running the same instruction type over and over again: https://dl.acm.org/citation.cfm?id=2744295.2724718

Wow, thanks, that's a fascinating paper! Direct link to pdf: [1].

So it turns out that if a transistor is kept on continuously its threshold voltage gradually increases (Negative-Bias Temperature-Instability (NBTI)), increasing the switching delay. This attack targets transistors along the critical path, increasing the path's delay until it exceeds the allowed tolerance (guardband). Turning the transistor off "heals" it; as a workaround they suggest periodically executing certain nop instructions to ensure critical path transistors spend at least 0.05% of their time turned off. They perform simulations using models of 45nm high-k PMOS transistors to produce their results. A good quote about processor reliability:

   Guardbanding  is  the  current  industrial  practice  to  cope  with  transistor  aging  and
   voltage droops [Agarwal et al. 2007]. It entails slowing down the clock frequency (i.e.,
   adding timing margin during design) based on the worst degradation the transistors
   might experience during their lifetime. The guardbands ensure that enough current
   passes through the processor to keep it above the threshold voltage and in turn ensure
   that the processor functionality is intact for an average period of 5 to 7 years [Tiwari
   and Torrellas 2008]. However, inserting wide guardbands degrades performance and
   increases energy consumption. Hence, processor design companies usually have small
   guardbands, typically 10% [Agarwal et al. 2007]. However, the MAGIC-based attack
   can deteriorate the critical path by 11% and cause erroneous results in 1 month.

This also explains why overclocking a CPU may be a bad idea, although they also show that random instructions don't come close to the worst case ageing.

[1] https://www.researchgate.net/profile/Naghmeh_Karimi/publicat...

Well, I think this can be answered by considering that even under normal conditions there are transistors that are used as much as in your hypothetical scenario. For example, the instruction decoding logic is invoked for every instruction. Since all logic transistors are the same (afaik), I don't think that using one type of instruction would significantly reduce the life-time of your CPU.

Probably not for MOV, given x86 uses it a heck of a lot anyway, so surely processors are already equipped to handle it.

You should also regularly rotate your CPU in its socket, to ensure all the cores wear evenly.

Uhm, not really, but you might make 20 smaller ones.

http://x86.renejeschke.de/html/file_module_x86_id_176.html

That is hilarious.

Could this be used for creating a ROP Gadget that overcomes ASLR on 64 bit machines?

How does it get past aslr? You still need to find addresses of the movs, don't you?

But MOV is not really a single instruction. I would be more impressed by a single opcode compiler.

How do we do arithmetic if we can only do movs?

I know! Lookup tables!

ELI5 please. What does this mean for a developer?

Nothing - it's simply an intellectual exercise. It uses the MOV instruction exclusively to create a working program.

Further reading - http://www.cl.cam.ac.uk/%7Esd601/papers/mov.pdf

It might find some use in DRM, malware, and other exploits as it would make reverse engineering/decompiling/analysis somewhat more challenging.

Someone made something very clever, but it has no practical usefulness whatsoever. It is an interesting intellectual exercise. It's also very impressive that they could pull this off.

I would think it has some practical use as research in OISC (one-instruction set computing) processors, which are like the RISC model (do a smaller set of instructions so you can do them faster) on steroids.

No practical usefulness? It seems rather great for obfuscation, be it for evil (viruses) or good (license key verification -- which is deemed 'good' merely because they're legal, not because they're not a pain in the arse).

Not really. Creating an algorithm for recovering the jumps and the intent of the various MOV patterns would be no more work than it was to write this. Particularly easier because one has access to the obfuscator's code, but I don't think it would be a major hurdle even without the source code.

Same could be said for most binaries: they're just compilations (usually with open source or freely available compilers) of C/C++ code. Shouldn't be too hard to reverse once you got all the patterns worked out.

I see your point though. I'm not very experienced on this and I'm sure some patterns can easily be recovered, but until someone goes through the effort it's still a considerable effort compared to being able to read the program normally, and even when someone does it's questionable whether the original can be recovered with some simple 1:1 translation.

You can stop worrying about branchless code and have it generated automatically! ;)

And for the minimalist, the zero-instruction C compiler

https://github.com/jbangert/trapcc

The MOV mnemonic is more like a family of instructions, isn't it?

Not knowing anything about GPU programming, isn't it similar to Movfuscator in some respects? Both branches are taken and run simultaneously?

just what I need for my next virus

Seems like it would give a large performance penalty. I don't get it.

It's a joke/demonstration that it is possible, not something you're supposed to use.

Obfuscation is surely used in malware.

One instruction set computers (OISC) are more than a joke, I suppose, but I didn't dig far into theoretical computer science and can't say, what's important about them.

I read a comment the other day, that stipulated neurons would be akin to massively parallel single instruction computers.

One instruction set computers (OISC) are more than a joke, I suppose, but I didn't dig far into theoretical computer science and can't say, what's important about them.

They're for highly parallel programable SIMD number crunching. The OISC would allow for easily fabricating a whole heaping bunch of ALUs.

There is a good talk that accompanies the code

source?

youtube.com/watch?v=HlUe0TUHOIc

At about 7 minutes in he is chatting about it but all is a good watch - could only find the YT link sorry

Reply on news.ycombinator.com