Hey everyone,
A few days ago, a friend sent me a sample with the message: "IDA is going nuts on this, but it runs fine." That kicked off a deep dive that ended up revealing a massive blind spot across the entire RE industry.
TL;DR: Two opcodes from a 25-year-old Intel patent (0F 1A and 0F 1B) are valid NOPs that your disassembler probably can't see, making them perfect for anti-RE.
The Story:
These opcodes were reserved by Intel in the 90s to allow new instructions to be added without breaking old software. On older CPUs, they'd just be NOPs. It was a brilliant idea. But somehow, tool developers for IDA, Ghidra, Binary Ninja, etc., just... missed a couple of them.
The result?
IDA Pro sees db 0Fh, 1Ah... and stops analyzing the function.
Ghidra marks it as undefined.
You can literally break static analysis with a single, valid instruction that the CPU executes without a problem.
I've put together a full investigation, a PoC you can compile yourself, and a pre-compiled binary to test your own tools.
Go ahead, throw patched.exe from the repo into your favorite tool and see for yourself. I'm curious to see what you all think.
sim7c00•4mo ago
not a bad find, its not unknown that most disassemblers dont do all the things correct. fun when u find one that breaks the further disass tho.
intel xed is pretty accurate usually but it also doesnt disassemble all possible opcodes.
if you do a jump over some UD but the jmp target is taken from reg value u can also get disassembly to break etc.
its kinda the problem of static analysis. it's not easy to see if someone inserted 1 byte of data, or if it was an unknown opcode u dont handle etc.
definitely fun, will throw off automated tools for analysis especially if you can make the invalid disassembly just call exit or do something valid but short/benign..
ive seen now multiple type of either debug or backdoor instructions on x86 based cpus over the past few years
sapdragon•4mo ago
Yes, but in most cases there is no such large-scale problem, plus we broke even all the popular debuggers here. The jump trick can probably only break Ghydra? But anything can break it(
sapdragon•4mo ago
TL;DR: Two opcodes from a 25-year-old Intel patent (0F 1A and 0F 1B) are valid NOPs that your disassembler probably can't see, making them perfect for anti-RE.
The Story: These opcodes were reserved by Intel in the 90s to allow new instructions to be added without breaking old software. On older CPUs, they'd just be NOPs. It was a brilliant idea. But somehow, tool developers for IDA, Ghidra, Binary Ninja, etc., just... missed a couple of them.
The result? IDA Pro sees db 0Fh, 1Ah... and stops analyzing the function. Ghidra marks it as undefined. You can literally break static analysis with a single, valid instruction that the CPU executes without a problem.
I've put together a full investigation, a PoC you can compile yourself, and a pre-compiled binary to test your own tools.
GitHub Repo with PoC & Research: https://github.com/sapdragon/hint-break
Full Article: https://alder-innocent-b3c.notion.site/THE-25-YEAR-OLD-INTEL...
Go ahead, throw patched.exe from the repo into your favorite tool and see for yourself. I'm curious to see what you all think.
sim7c00•4mo ago
intel xed is pretty accurate usually but it also doesnt disassemble all possible opcodes.
if you do a jump over some UD but the jmp target is taken from reg value u can also get disassembly to break etc.
its kinda the problem of static analysis. it's not easy to see if someone inserted 1 byte of data, or if it was an unknown opcode u dont handle etc.
definitely fun, will throw off automated tools for analysis especially if you can make the invalid disassembly just call exit or do something valid but short/benign..
may also wanna look if they are known unknown, like this stuff: https://x.com/_markel___/status/1373059797155778562
ive seen now multiple type of either debug or backdoor instructions on x86 based cpus over the past few years
sapdragon•4mo ago