Maybe we can use this method to find Satoshi, if he uses github.
Depending of how much of Satoshi's fingerprint is left and how early they started to version control the code.
When coding style survives compilation: De-anonymizing programmers from binaries
11–20 of 74 posts
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#12Well, this puts a damper on my plan to create a secret identity on the internet under which I release software the way Banksy releases art. Unless I stop publicly writing software for a few years.
My suspicion is that most of these features wouldn't survive in an adversarial setting -- either by consciously changing your coding style or (better) using automated tools to rewrite your source code before compilation to alter the control flow structure (e.g., control flow flattening [1]). http://reverseengineering.stackexchange.com/questions/2221/w...
I am not so sure that the coding style doesn't survive the automated tools. It's also about what features you implement and how you do it.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#13Really neat, especially since the source could be from different languages and compilers. I'd be interested at the deanonymization accuracy within the Go language where there is a widespread adoption of the code formatting tool and seeing if that has any impact.
I write almost exclusively Go these days, and I think most of the people I work with could tell you if I wrote a Go program
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#14Really neat, especially since the source could be from different languages and compilers. I'd be interested at the deanonymization accuracy within the Go language where there is a widespread adoption of the code formatting tool and seeing if that has any impact.
Go embeds paths to libraries and some temporary paths in it's binaries. Feel free to run strings and possibly find the user's home directory and skip deanonymozation of source code.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#15Don't miss the talk by Aylin starting in 50 minutes here: http://streaming.media.ccc.de/32c3/hallg/ (Recording available later ...)
Recordings will be at https://media.ccc.de/b/congress/2015
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#16This statement seems debatable: "Since all the contestants implement the same functionality, the main difference between their samples is their coding style."
All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem".
But this statement seems the most interesting: "By comparing advanced and less advanced programmers’, we found that more advanced programmers are easier to de-anonymize and they have a more distinct coding style."
Beginners tend to think alike, while experts develop an original line of thinking, that is identifiable. The paper could be called "Fingerprints of Thought"...
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#17This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
As a professional, I tend to think a distinct coding style is bad. You should try to write a code that is plain and unsurprising and reproducible. To me, this study gives us another reason that we need a more uniform/standardized methodology and good education for the software industry.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#18Earlier quoted context omitted.
My suspicion is that most of these features wouldn't survive in an adversarial setting -- either by consciously changing your coding style or (better) using automated tools to rewrite your source code before compilation to alter the control flow structure (e.g., control flow flattening [1]). http://reverseengineering.stackexchange.com/questions/2221/w...
I am not so sure that the coding style doesn't survive the automated tools. It's also about what features you implement and how you do it.
Running `strip` on the binary decreased classification accuracy by 12%. They quite correctly point out that this isn't a large drop, but strip is really the lowest of the low hanging fruit when it comes to code obfuscation. I'd expect much bigger drops from anything that's trying to make code harder to fingerprint.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#19Interesting but if your code is open source a lot of people will be contributing to it bringing in their own style. Depending on how popular the code is your fingerprint could be completely hidden amongst hundreds.
If the code is open-source there likely is a history of contributions. But this research is about "De-anonymizing programmers from executable binaries" anyway, so really not an OSS scenario.
Re: When coding style survives compilation: De-anonymizing programmers from binaries
#20This statement seems debatable: " Since all the contestants implement the same functionality, the main difference between their samples is their coding style. " All the (winning) contestants implement the same functionality, yes, but with possibly wildly different approaches/algorithms, so the main difference between code samples is not just "style" but what could be called "general thinking in and around the problem…
As a professional, I tend to think a distinct coding style is bad. You should try to write a code that is plain and unsurprising and reproducible. To me, this study gives us another reason that we need a more uniform/standardized methodology and good education for the software industry.
Writing code that is plain, unsurprising, and reproducible not only is, itself, a style but also still leaves a lot of room for creativity/individuality.