about
De-anonymizing programmers from binaries (2017) (arxiv.org)
103 points by pvitz on Aug 8, 2022 | hide | past | pdf | 27 comments on HN

In plain words: By turning compiled programs back into readable code and reading habits in the machine instructions, a tool can match a binary to its writer. It picked the correct writer 96% of the time among 100 candidates, and kept working after obfuscation and compiler cleanup.

Abstract · When Coding Style Survives Compilation: De-anonymizing Programmers from Executable Binaries

The ability to identify authors of computer programs based on their coding style is a direct threat to the privacy and anonymity of programmers. While recent work found that source code can be attributed to authors with high accuracy, attribution of executable binaries appears to be much more difficult. Many distinguishing features present in source code, e.g. variable names, are removed in the compilation process, and compiler optimization may alter the structure of a program, further obscuring features that are known to be useful in determining authorship. We examine programmer de-anonymization from the standpoint of machine learning, using a novel set of features that include ones obtained by decompiling the executable binary to source code. We adapt a powerful set of techniques from the domain of source code authorship attribution along with stylistic representations embedded in assembly, resulting in successful de-anonymization of a large set of programmers. We evaluate our approach on data from the Google Code Jam, obtaining attribution accuracy of up to 96% with 100 and 83% with 600 candidate programmers. We present an executable binary authorship attribution approach, for the first time, that is robust to basic obfuscations, a range of compiler optimization settings, and binaries that have been stripped of their symbol tables. We perform programmer de-anonymization using both obfuscated binaries, and real-world code found "in the wild" in single-author GitHub repositories and the recently leaked Nulled.IO hacker forum. We show that programmers who would like to remain anonymous need to take extreme countermeasures to protect their privacy.

Aylin Caliskan, Fabian Yamaguchi, Edwin Dauber, Richard Harang, Konrad Rieck, Rachel Greenstadt, Arvind Narayanan
arXiv:1512.08546 · cs.CR · submitted Dec 28, 2015 · updated Dec 18, 2017
abstract · pdf · html · 15 pages

add comment on HN
Also discussed: Dec 2017 (4 points, 0 comments)

Related:

De-anonymizing programmers from executable binaries - https://news.ycombinator.com/item?id=16598962 - March 2018 (39 comments)

When coding style survives compilation: De-anonymizing programmers from binaries - https://news.ycombinator.com/item?id=10806956 - Dec 2015 (67 comments)

Not directly relevant but it got me thinking:

Has anyone tried to use the source code and white paper to figure out who Satoshi Nakamoto might be?

If you can figure it out from binaries, surely there is a lot more info. And you have the github and the blogosphere to compare.

I bet everything he has ever done including the Bitcoin Whitepaper has been analysed very precisely. Satoshi must be an expert in hiding.
> Satoshi must be an expert in hiding.

There are allegations that Satoshi may have accidentally slipped up and leaked IP address that was not a Tor exit-node or other anonymous-proxy.

Could either be Satoshi fucking up and not using Tor all the time (has happened to other 'anonymous' entities) or perhaps they needed a clearnet connection for some reason and managed to use another internet connection not attached to any identifiers that would lead back to them despite that.

he's dead.
One point in favour of that theory is he has billions of dollars in bitcoin and has never attempted to spend any of it. Or maybe has lost the keys.
Two of the top candidates for Satoshi are known to have died as well: Hal Finney and Len Sassaman.
If he or she were dead, but their writing and code is extant, presumably they could still be identified.
This uses 600 'candidate' programmers. But I wonder how much harder it becomes when on e.g. an arbitrary piece of github gist code. As the number of candidates increases (with many writing the same styles) I'd imagine the problem becomes enormously more difficult.
With copilot I'm sure the data exists and it's a matter of modeling it out. The fact you can't configure co-pilot to do celebrity coding by fine tuning it to a particular person or organizations repositories is actually surprising to me.
This is a good point.

The confidence level of the identification will be reduced as the sample size increases.

I am thinking of a future when every piece of code can be traced back to a common ancestor because everyone is using a tool like copilot and there is no identifying signature. De-anonymization is only going to become more difficult.
How effective is, say, movfuscator against this?

https://github.com/xoreaxeaxeax/movfuscator

That's a good point. In general there's probably a ton of easy ways to adverserially rewrite the binary against a deanonymizer like this. You could probably even make a program that rewrites your own code into someone elses style to frame them.
Their experiment with different optimization level is with symbol information intact and they did not mention whether they have debug information enabled. Stripping the binary but with no optmimization reduces accuracy by 24%, but they did not mention the accuracy of O3 + stripped binary, so I guess it is probably not that good as this is so obvious that they should have tried.

Interesting research anyway.

Also lto might have a severe impact there.
Basically , to outsmart this algorithm you can use deniability attack

You just say that someone imitated your style. It's not like binary has cryptographic signature of person who compiled it, even then you can say that someone stole your private key.

This is very interesting in terms of threatintel and attributing malware to attackers.
Must be pretty brain-dead malware programmers to be IDed based on this.
I don't even want to know what the GDPR-implications of this are..
None. There is a difference between actually storing personal data and it being possible to forensically analyze data not eligible for protection and potentially correlate other similar data that in turn is tagged with metadata.

The second party has the obligation not the first. Ultimately all risk of exposure of personal data derives from the second party. For example if you mail in an executable to a client and put some code on github under your own real name the holder of the exe has no obligation because it is impossible for your identity to be exposed by it or indeed an infinite number of similar executables.

It is only when combined with your github profile where you willingly shared a work sample and your real info that you could possibly be exposed.

Hinges on how loosely a data protection authority is willing to read "filing system" because screw you, I'd think.
Technically, it means that any system holding binaries is capable of holding data identifying a user, which has crazy gdpr implications.

Practically I don't expect this to have any impact beyond state surveillance, where obtaining a binary for a virus (or, you know, drm-defeat code) can identify its creator against any public code they would have posted elsewhere.

Most malware is packed and/or obfuscated. I'd imagine this defeats fingerprinting relatively handily since the binary is rewritten. I'm sure this technique is used to catch particularly dumb adversaries, but against anyone with a hint of operational security it wouldn't work at all. Moreover, what's stopping a determined adversary from rewriting the binary with a signature that matches another person? Using this as a targeting method would have a lot of collateral damage.
Anyone whose job it is to evade detection will pull their output through a scrambler. What this will catch is small-time criminals, probably in minority groups (frequently categorised as "high risk" by police).
But is a developer a user? I think saying that is quite the jump.
This implies compilers are not as efficient as they could be and work needs to be done on that. Style in a binary is waste.

If it's true.

Are they sure it's not from text within the programs or other fingerprints?

I wish they gave examples of the fingerprints. It's hard to even know how to move forward without that.