Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> BinDiff: you can't patch software without disclosing vulnerabilities

That’s why Microsoft has been obfuscating its binary builds for at least the last two decades so that even the two builds from the same source would produce very different blobs.



Sounds dubious, do you have a citation? The disassembly looks very straightforward for a lot of Windows code.


They're not encoded, but the code blocks are shuffled. That's why disassembly does look straightforward, but it used to thwart BinDiff at the time.


If I understand correctly, that is just randomness comes from parallel compiling and linking.

If you saying there is a whole step just scrambling blobs, i will be very surprised.


That sounds a lot like US9116712, but I don't think its ever been publicly said that Windows does this.


What made you believe this is the case? any examples/links/etc.?


It was a part of our Windows build process when I was at Microsoft. I only assumed that they would keep doing it, but they might have as well dropped the practice.


I don't see how that can be useful when Microsoft publishes debug symbols for almost everything.


All the while, Linux is going towards reproducible builds (Debian just announced it as a policy). This is of course the only sane way for FOSS, and, I believe, the only sane long term approach in any case. Security by obscurity, while not worthless, is just a thin mitigation layer. By the way, build-time randomization is ineffective in light of AI analysis---it needs to be per-binary-run, in the style of KASLR.


How are they obfuscated?


See my sibling comment.


Everything I can find says they are not obfuscating




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: