Can I rely on these GitHub repository files? Unicorn Meta Zoo #1: Why another podcast? Announcing the arrival of Valued Associate #679: Cesar ManaraWhich file encryption algorithm is used by Synology's Cloud Sync feature?GitHub pages and same originDoes GitHub have an endpoint for reading a users GPG keys?API credentials visible when creating Github pages website?Why host third party libs instead of relying on CDN, Nuget, GitHub?Making an API repository private vs publicHow does Github preserve versioning integrity?How does Github authentication work (command line, api)?Is it a good idea to upload your gnupg files to github?How could malicious code changes in a GitHub pull request be masked by an attacker?

How to keep bees out of canned beverages?

What *exactly* is electrical current, voltage, and resistance?

Raising a bilingual kid. When should we introduce the majority language?

Does using the Inspiration rules for character defects encourage My Guy Syndrome?

Why does Java have support for time zone offsets with seconds precision?

What is the ongoing value of the Kanban board to the developers as opposed to management

How would you suggest I follow up with coworkers about our deadline that's today?

Is a self contained air-bullet cartridge feasible?

What is a 'Key' in computer science?

What is the term for extremely loose Latin word order?

TV series episode where humans nuke aliens before decrypting their message that states they come in peace

What is /etc/mtab in Linux?

Was Objective-C really a hindrance to Apple software development?

Why aren't road bicycle wheels tiny?

What is the definining line between a helicopter and a drone a person can ride in?

Getting AggregateResult variables from Execute Anonymous Window

/bin/ls sorts differently than just ls

Why I cannot instantiate a class whose constructor is private in a friend class?

Retract an already submitted Recommendation Letter (written for an undergrad student)

Does every subgroup of an abelian group have to be abelian?

Why does the Cisco show run command not show the full version, while the show version command does?

Why isn't everyone flabbergasted about Bran's "gift"?

When does Bran Stark remember Jamie pushing him?

Why is arima in R one time step off?



Can I rely on these GitHub repository files?



Unicorn Meta Zoo #1: Why another podcast?
Announcing the arrival of Valued Associate #679: Cesar ManaraWhich file encryption algorithm is used by Synology's Cloud Sync feature?GitHub pages and same originDoes GitHub have an endpoint for reading a users GPG keys?API credentials visible when creating Github pages website?Why host third party libs instead of relying on CDN, Nuget, GitHub?Making an API repository private vs publicHow does Github preserve versioning integrity?How does Github authentication work (command line, api)?Is it a good idea to upload your gnupg files to github?How could malicious code changes in a GitHub pull request be masked by an attacker?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








21















I recently found the GitHub repository https://github.com/userEn1gm4/HLuna, but after I cloned it I noted that the comparison between the file compiled (using g++) from source, HLuna.cxx, and the binary included in the repository (HLuna) is different: differ: byte 25, line 1. Is the provided binary file secure?



I've already analyzed that in VirusTotal without any issues, but I don't have the expertise to decompile and read the output, and I've previously executed the binary provided without thinking about the risks.










share|improve this question



















  • 3





    If you're able to compile from source, then just use your computer version.

    – Daisetsu
    Mar 25 at 5:05






  • 18





    It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

    – PTwr
    Mar 25 at 8:27






  • 1





    There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

    – apsillers
    Mar 25 at 13:09







  • 1





    How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

    – Johnny
    Mar 25 at 21:35

















21















I recently found the GitHub repository https://github.com/userEn1gm4/HLuna, but after I cloned it I noted that the comparison between the file compiled (using g++) from source, HLuna.cxx, and the binary included in the repository (HLuna) is different: differ: byte 25, line 1. Is the provided binary file secure?



I've already analyzed that in VirusTotal without any issues, but I don't have the expertise to decompile and read the output, and I've previously executed the binary provided without thinking about the risks.










share|improve this question



















  • 3





    If you're able to compile from source, then just use your computer version.

    – Daisetsu
    Mar 25 at 5:05






  • 18





    It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

    – PTwr
    Mar 25 at 8:27






  • 1





    There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

    – apsillers
    Mar 25 at 13:09







  • 1





    How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

    – Johnny
    Mar 25 at 21:35













21












21








21


2






I recently found the GitHub repository https://github.com/userEn1gm4/HLuna, but after I cloned it I noted that the comparison between the file compiled (using g++) from source, HLuna.cxx, and the binary included in the repository (HLuna) is different: differ: byte 25, line 1. Is the provided binary file secure?



I've already analyzed that in VirusTotal without any issues, but I don't have the expertise to decompile and read the output, and I've previously executed the binary provided without thinking about the risks.










share|improve this question
















I recently found the GitHub repository https://github.com/userEn1gm4/HLuna, but after I cloned it I noted that the comparison between the file compiled (using g++) from source, HLuna.cxx, and the binary included in the repository (HLuna) is different: differ: byte 25, line 1. Is the provided binary file secure?



I've already analyzed that in VirusTotal without any issues, but I don't have the expertise to decompile and read the output, and I've previously executed the binary provided without thinking about the risks.







reverse-engineering c++ github






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 25 at 7:19









Peter Mortensen

71249




71249










asked Mar 24 at 23:14









mcruz2401mcruz2401

11115




11115







  • 3





    If you're able to compile from source, then just use your computer version.

    – Daisetsu
    Mar 25 at 5:05






  • 18





    It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

    – PTwr
    Mar 25 at 8:27






  • 1





    There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

    – apsillers
    Mar 25 at 13:09







  • 1





    How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

    – Johnny
    Mar 25 at 21:35












  • 3





    If you're able to compile from source, then just use your computer version.

    – Daisetsu
    Mar 25 at 5:05






  • 18





    It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

    – PTwr
    Mar 25 at 8:27






  • 1





    There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

    – apsillers
    Mar 25 at 13:09







  • 1





    How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

    – Johnny
    Mar 25 at 21:35







3




3





If you're able to compile from source, then just use your computer version.

– Daisetsu
Mar 25 at 5:05





If you're able to compile from source, then just use your computer version.

– Daisetsu
Mar 25 at 5:05




18




18





It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

– PTwr
Mar 25 at 8:27





It takes lots of effort for builds to be reproducible (deterministic) due to nature of legacy tools (because no one cared about that in past). Debian is trying to be deterministic since 2014, still not done :)

– PTwr
Mar 25 at 8:27




1




1





There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

– apsillers
Mar 25 at 13:09






There is a relevant post (full disclosure: mine) on OpenSource.SE with several helpful links about deterministic and non-deterministic builds: Is there any way to assert that source code corresponds to compiled code?

– apsillers
Mar 25 at 13:09





1




1





How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

– Johnny
Mar 25 at 21:35





How do you know you can trust the source code in the repo? Do you audit every single line of code? (the 175 line source code file you linked to is small enough that you can audit it, but if it were 10,000 or 100,000 lines of code, is the source code any safer than the published binaries?)

– Johnny
Mar 25 at 21:35










3 Answers
3






active

oldest

votes


















22














Polynomial tells you what may happen, and how to solve it. Here I will illustrate it:



I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used:



GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)
> GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)
> gcc 8.2.1 20181105


Some of the private names used are also different:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_@ | _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_


And some sections seem to be shuffled, so the diff cannot match them exactly.



Even on the same computer, without optimisation and -O3 shows different files:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendE | _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev


Even shuffling of internal data:



Diccionario creado! <
MENU <
1. Generador de Diccionarios <
0. Salir <
/*** <
* $$| |$$ |$$| <
* $$| |$$ |$$| * $$| |$$ |$$|
* $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$| * $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$|
* $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$| * $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$|
* $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$|
* $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$| * $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$|
* $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$|
* ---------------------------------------------- * ----------------------------------------------
> -------------------
> Diccionario creado!
> MENU
> 1. Generador de Diccionarios
> 0. Salir
> /***
> * $$| |$$ |$$|



This proves that differing binary files raises many false positives, and doesn't tell you anything about is safety.



In this case, I'd use the version compiled by myself because you have no way to know what version is uploaded, as the author may have forgotten to recompile before the last tweaks.






share|improve this answer


















  • 7





    I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

    – Toby Speight
    Mar 25 at 16:14











  • @TobySpeight good point, I shall investigate and correct.

    – Davidmh
    Mar 25 at 22:06











  • …and even a honest author might be unknowingly infected by some malware.

    – spectras
    Mar 26 at 3:05






  • 2





    Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

    – Kevin
    Mar 26 at 7:20












  • @Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

    – Braiam
    Mar 26 at 14:51


















58














Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.






share|improve this answer


















  • 35





    Even that isn't going to be reliable across optimization levels.

    – chrylis
    Mar 25 at 5:48






  • 44





    Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

    – Jörg W Mittag
    Mar 25 at 7:00






  • 2





    Reproducible builds solve this problem.

    – forest
    Mar 25 at 8:34











  • This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

    – Croll
    Mar 26 at 9:07



















2














If the software is exactly the same at source level, then the question boils down to whether you can trust your compiler, system libraries and various utilities which are used during compilation. If you installed your toolchain from a trusted source and you trust your computer wasn't compromised meanwhile, then there's no reason to suspect that the binary file that you generated will be malicious, even if it differs from the "reference" build.






share|improve this answer


















  • 6





    Of course, Ken Thompson may disagree.

    – Jörg W Mittag
    Mar 25 at 15:52






  • 1





    @JörgWMittag If you can't trust trust, who can you trust?

    – apsillers
    Mar 25 at 16:52






  • 1





    @apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

    – Alex Vong
    Mar 26 at 12:01











Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206000%2fcan-i-rely-on-these-github-repository-files%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









22














Polynomial tells you what may happen, and how to solve it. Here I will illustrate it:



I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used:



GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)
> GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)
> gcc 8.2.1 20181105


Some of the private names used are also different:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_@ | _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_


And some sections seem to be shuffled, so the diff cannot match them exactly.



Even on the same computer, without optimisation and -O3 shows different files:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendE | _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev


Even shuffling of internal data:



Diccionario creado! <
MENU <
1. Generador de Diccionarios <
0. Salir <
/*** <
* $$| |$$ |$$| <
* $$| |$$ |$$| * $$| |$$ |$$|
* $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$| * $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$|
* $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$| * $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$|
* $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$|
* $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$| * $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$|
* $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$|
* ---------------------------------------------- * ----------------------------------------------
> -------------------
> Diccionario creado!
> MENU
> 1. Generador de Diccionarios
> 0. Salir
> /***
> * $$| |$$ |$$|



This proves that differing binary files raises many false positives, and doesn't tell you anything about is safety.



In this case, I'd use the version compiled by myself because you have no way to know what version is uploaded, as the author may have forgotten to recompile before the last tweaks.






share|improve this answer


















  • 7





    I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

    – Toby Speight
    Mar 25 at 16:14











  • @TobySpeight good point, I shall investigate and correct.

    – Davidmh
    Mar 25 at 22:06











  • …and even a honest author might be unknowingly infected by some malware.

    – spectras
    Mar 26 at 3:05






  • 2





    Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

    – Kevin
    Mar 26 at 7:20












  • @Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

    – Braiam
    Mar 26 at 14:51















22














Polynomial tells you what may happen, and how to solve it. Here I will illustrate it:



I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used:



GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)
> GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)
> gcc 8.2.1 20181105


Some of the private names used are also different:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_@ | _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_


And some sections seem to be shuffled, so the diff cannot match them exactly.



Even on the same computer, without optimisation and -O3 shows different files:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendE | _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev


Even shuffling of internal data:



Diccionario creado! <
MENU <
1. Generador de Diccionarios <
0. Salir <
/*** <
* $$| |$$ |$$| <
* $$| |$$ |$$| * $$| |$$ |$$|
* $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$| * $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$|
* $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$| * $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$|
* $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$|
* $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$| * $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$|
* $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$|
* ---------------------------------------------- * ----------------------------------------------
> -------------------
> Diccionario creado!
> MENU
> 1. Generador de Diccionarios
> 0. Salir
> /***
> * $$| |$$ |$$|



This proves that differing binary files raises many false positives, and doesn't tell you anything about is safety.



In this case, I'd use the version compiled by myself because you have no way to know what version is uploaded, as the author may have forgotten to recompile before the last tweaks.






share|improve this answer


















  • 7





    I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

    – Toby Speight
    Mar 25 at 16:14











  • @TobySpeight good point, I shall investigate and correct.

    – Davidmh
    Mar 25 at 22:06











  • …and even a honest author might be unknowingly infected by some malware.

    – spectras
    Mar 26 at 3:05






  • 2





    Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

    – Kevin
    Mar 26 at 7:20












  • @Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

    – Braiam
    Mar 26 at 14:51













22












22








22







Polynomial tells you what may happen, and how to solve it. Here I will illustrate it:



I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used:



GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)
> GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)
> gcc 8.2.1 20181105


Some of the private names used are also different:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_@ | _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_


And some sections seem to be shuffled, so the diff cannot match them exactly.



Even on the same computer, without optimisation and -O3 shows different files:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendE | _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev


Even shuffling of internal data:



Diccionario creado! <
MENU <
1. Generador de Diccionarios <
0. Salir <
/*** <
* $$| |$$ |$$| <
* $$| |$$ |$$| * $$| |$$ |$$|
* $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$| * $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$|
* $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$| * $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$|
* $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$|
* $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$| * $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$|
* $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$|
* ---------------------------------------------- * ----------------------------------------------
> -------------------
> Diccionario creado!
> MENU
> 1. Generador de Diccionarios
> 0. Salir
> /***
> * $$| |$$ |$$|



This proves that differing binary files raises many false positives, and doesn't tell you anything about is safety.



In this case, I'd use the version compiled by myself because you have no way to know what version is uploaded, as the author may have forgotten to recompile before the last tweaks.






share|improve this answer













Polynomial tells you what may happen, and how to solve it. Here I will illustrate it:



I ran both binaries through strings and diffed them. That enough shows some completely harmless differences, in particular, the compiler used:



GCC: (Debian 6.3.0-18) 6.3.0 20170516 | GCC: (GNU) 8.2.1 20181105 (Red Hat 8.2.1-5)
> GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)
> gcc 8.2.1 20181105


Some of the private names used are also different:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_@ | _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSERKS4_


And some sections seem to be shuffled, so the diff cannot match them exactly.



Even on the same computer, without optimisation and -O3 shows different files:



_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6appendE | _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev


Even shuffling of internal data:



Diccionario creado! <
MENU <
1. Generador de Diccionarios <
0. Salir <
/*** <
* $$| |$$ |$$| <
* $$| |$$ |$$| * $$| |$$ |$$|
* $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$| * $$| |$$ |$$| $$| |$$ |$$$$$$| |$$$$$$|
* $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$| * $$$$$$$$ |$$| $$| |$$ |$$ __ $$| ____$$|
* $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$| $$| |$$ |$$| |$$| $$$$$$$|
* $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$| * $$| |$$ |$$|___ $$|_|$$ |$$| |$$| $$___$$|
* $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$| * $$| |$$ |$$$$$$$| $$$$$ |$$| |$$| $$$$$$$|
* ---------------------------------------------- * ----------------------------------------------
> -------------------
> Diccionario creado!
> MENU
> 1. Generador de Diccionarios
> 0. Salir
> /***
> * $$| |$$ |$$|



This proves that differing binary files raises many false positives, and doesn't tell you anything about is safety.



In this case, I'd use the version compiled by myself because you have no way to know what version is uploaded, as the author may have forgotten to recompile before the last tweaks.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 25 at 8:46









DavidmhDavidmh

33615




33615







  • 7





    I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

    – Toby Speight
    Mar 25 at 16:14











  • @TobySpeight good point, I shall investigate and correct.

    – Davidmh
    Mar 25 at 22:06











  • …and even a honest author might be unknowingly infected by some malware.

    – spectras
    Mar 26 at 3:05






  • 2





    Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

    – Kevin
    Mar 26 at 7:20












  • @Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

    – Braiam
    Mar 26 at 14:51












  • 7





    I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

    – Toby Speight
    Mar 25 at 16:14











  • @TobySpeight good point, I shall investigate and correct.

    – Davidmh
    Mar 25 at 22:06











  • …and even a honest author might be unknowingly infected by some malware.

    – spectras
    Mar 26 at 3:05






  • 2





    Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

    – Kevin
    Mar 26 at 7:20












  • @Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

    – Braiam
    Mar 26 at 14:51







7




7





I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

– Toby Speight
Mar 25 at 16:14





I don't think those are different names - what's actually happened is that when the immediately adjoining data are printable, strings grabs slightly more text. nm might be a better tool for extracting identifiers.

– Toby Speight
Mar 25 at 16:14













@TobySpeight good point, I shall investigate and correct.

– Davidmh
Mar 25 at 22:06





@TobySpeight good point, I shall investigate and correct.

– Davidmh
Mar 25 at 22:06













…and even a honest author might be unknowingly infected by some malware.

– spectras
Mar 26 at 3:05





…and even a honest author might be unknowingly infected by some malware.

– spectras
Mar 26 at 3:05




2




2





Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

– Kevin
Mar 26 at 7:20






Protip/warning: GNU Strings was at one point vulnerable to arbitrary code execution if used on a malicious file. So it may be wise to avoid running it on untrusted files, just in case.

– Kevin
Mar 26 at 7:20














@Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

– Braiam
Mar 26 at 14:51





@Kevin any piece of software may be vulnerable to arbitrary code execution if used on a malicious file. That doesn't mean you can't use those tools to examine them, it just mean that you need to airgap the system that runs them.

– Braiam
Mar 26 at 14:51













58














Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.






share|improve this answer


















  • 35





    Even that isn't going to be reliable across optimization levels.

    – chrylis
    Mar 25 at 5:48






  • 44





    Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

    – Jörg W Mittag
    Mar 25 at 7:00






  • 2





    Reproducible builds solve this problem.

    – forest
    Mar 25 at 8:34











  • This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

    – Croll
    Mar 26 at 9:07
















58














Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.






share|improve this answer


















  • 35





    Even that isn't going to be reliable across optimization levels.

    – chrylis
    Mar 25 at 5:48






  • 44





    Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

    – Jörg W Mittag
    Mar 25 at 7:00






  • 2





    Reproducible builds solve this problem.

    – forest
    Mar 25 at 8:34











  • This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

    – Croll
    Mar 26 at 9:07














58












58








58







Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.






share|improve this answer













Compilation is not a directly verifiable deterministic process across compiler versions, library versions, operating systems, or a number of other different variables. The only way to verify is to perform a diff at the assembly level. There are lots of tools that can do this but you still need to put the manual work in.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 24 at 23:20









PolynomialPolynomial

102k36249342




102k36249342







  • 35





    Even that isn't going to be reliable across optimization levels.

    – chrylis
    Mar 25 at 5:48






  • 44





    Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

    – Jörg W Mittag
    Mar 25 at 7:00






  • 2





    Reproducible builds solve this problem.

    – forest
    Mar 25 at 8:34











  • This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

    – Croll
    Mar 26 at 9:07













  • 35





    Even that isn't going to be reliable across optimization levels.

    – chrylis
    Mar 25 at 5:48






  • 44





    Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

    – Jörg W Mittag
    Mar 25 at 7:00






  • 2





    Reproducible builds solve this problem.

    – forest
    Mar 25 at 8:34











  • This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

    – Croll
    Mar 26 at 9:07








35




35





Even that isn't going to be reliable across optimization levels.

– chrylis
Mar 25 at 5:48





Even that isn't going to be reliable across optimization levels.

– chrylis
Mar 25 at 5:48




44




44





Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

– Jörg W Mittag
Mar 25 at 7:00





Even if the compiled object code is 100% identical, there may still be timestamps in the executable file's metadata which cause the resulting binaries to differ even though the code is identical.

– Jörg W Mittag
Mar 25 at 7:00




2




2





Reproducible builds solve this problem.

– forest
Mar 25 at 8:34





Reproducible builds solve this problem.

– forest
Mar 25 at 8:34













This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

– Croll
Mar 26 at 9:07






This is the real answer. Build never supposed to produce the same binary on two different machines even with same OS, compiler version and configuration. It is just stated nowhere, and no one actually assumed this, at least in C++ world. I don't like the accepted answer because it is specific to the app and does not explain this.

– Croll
Mar 26 at 9:07












2














If the software is exactly the same at source level, then the question boils down to whether you can trust your compiler, system libraries and various utilities which are used during compilation. If you installed your toolchain from a trusted source and you trust your computer wasn't compromised meanwhile, then there's no reason to suspect that the binary file that you generated will be malicious, even if it differs from the "reference" build.






share|improve this answer


















  • 6





    Of course, Ken Thompson may disagree.

    – Jörg W Mittag
    Mar 25 at 15:52






  • 1





    @JörgWMittag If you can't trust trust, who can you trust?

    – apsillers
    Mar 25 at 16:52






  • 1





    @apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

    – Alex Vong
    Mar 26 at 12:01















2














If the software is exactly the same at source level, then the question boils down to whether you can trust your compiler, system libraries and various utilities which are used during compilation. If you installed your toolchain from a trusted source and you trust your computer wasn't compromised meanwhile, then there's no reason to suspect that the binary file that you generated will be malicious, even if it differs from the "reference" build.






share|improve this answer


















  • 6





    Of course, Ken Thompson may disagree.

    – Jörg W Mittag
    Mar 25 at 15:52






  • 1





    @JörgWMittag If you can't trust trust, who can you trust?

    – apsillers
    Mar 25 at 16:52






  • 1





    @apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

    – Alex Vong
    Mar 26 at 12:01













2












2








2







If the software is exactly the same at source level, then the question boils down to whether you can trust your compiler, system libraries and various utilities which are used during compilation. If you installed your toolchain from a trusted source and you trust your computer wasn't compromised meanwhile, then there's no reason to suspect that the binary file that you generated will be malicious, even if it differs from the "reference" build.






share|improve this answer













If the software is exactly the same at source level, then the question boils down to whether you can trust your compiler, system libraries and various utilities which are used during compilation. If you installed your toolchain from a trusted source and you trust your computer wasn't compromised meanwhile, then there's no reason to suspect that the binary file that you generated will be malicious, even if it differs from the "reference" build.







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 25 at 13:27









Dmitry GrigoryevDmitry Grigoryev

7,6802244




7,6802244







  • 6





    Of course, Ken Thompson may disagree.

    – Jörg W Mittag
    Mar 25 at 15:52






  • 1





    @JörgWMittag If you can't trust trust, who can you trust?

    – apsillers
    Mar 25 at 16:52






  • 1





    @apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

    – Alex Vong
    Mar 26 at 12:01












  • 6





    Of course, Ken Thompson may disagree.

    – Jörg W Mittag
    Mar 25 at 15:52






  • 1





    @JörgWMittag If you can't trust trust, who can you trust?

    – apsillers
    Mar 25 at 16:52






  • 1





    @apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

    – Alex Vong
    Mar 26 at 12:01







6




6





Of course, Ken Thompson may disagree.

– Jörg W Mittag
Mar 25 at 15:52





Of course, Ken Thompson may disagree.

– Jörg W Mittag
Mar 25 at 15:52




1




1





@JörgWMittag If you can't trust trust, who can you trust?

– apsillers
Mar 25 at 16:52





@JörgWMittag If you can't trust trust, who can you trust?

– apsillers
Mar 25 at 16:52




1




1





@apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

– Alex Vong
Mar 26 at 12:01





@apsillers trusting trust can be countered: schneier.com/blog/archives/2006/01/countering_trus.html

– Alex Vong
Mar 26 at 12:01

















draft saved

draft discarded
















































Thanks for contributing an answer to Information Security Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206000%2fcan-i-rely-on-these-github-repository-files%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bruad Bilen | Luke uk diar | NawigatsjuunCommonskategorii: BruadCommonskategorii: RunstükenWikiquote: Bruad

What is the offset in a seaplane's hull?

Slayer Innehåll Historia | Stil, komposition och lyrik | Bandets betydelse och framgångar | Sidoprojekt och samarbeten | Kontroverser | Medlemmar | Utmärkelser och nomineringar | Turnéer och festivaler | Diskografi | Referenser | Externa länkar | Navigeringsmenywww.slayer.net”Metal Massacre vol. 1””Metal Massacre vol. 3””Metal Massacre Volume III””Show No Mercy””Haunting the Chapel””Live Undead””Hell Awaits””Reign in Blood””Reign in Blood””Gold & Platinum – Reign in Blood””Golden Gods Awards Winners”originalet”Kerrang! Hall Of Fame””Slayer Looks Back On 37-Year Career In New Video Series: Part Two””South of Heaven””Gold & Platinum – South of Heaven””Seasons in the Abyss””Gold & Platinum - Seasons in the Abyss””Divine Intervention””Divine Intervention - Release group by Slayer””Gold & Platinum - Divine Intervention””Live Intrusion””Undisputed Attitude””Abolish Government/Superficial Love””Release “Slatanic Slaughter: A Tribute to Slayer” by Various Artists””Diabolus in Musica””Soundtrack to the Apocalypse””God Hates Us All””Systematic - Relationships””War at the Warfield””Gold & Platinum - War at the Warfield””Soundtrack to the Apocalypse””Gold & Platinum - Still Reigning””Metallica, Slayer, Iron Mauden Among Winners At Metal Hammer Awards””Eternal Pyre””Eternal Pyre - Slayer release group””Eternal Pyre””Metal Storm Awards 2006””Kerrang! Hall Of Fame””Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Bullet-For My Valentine booed at Metal Hammer Golden Gods Awards””Unholy Aliance””The End Of Slayer?””Slayer: We Could Thrash Out Two More Albums If We're Fast Enough...””'The Unholy Alliance: Chapter III' UK Dates Added”originalet”Megadeth And Slayer To Co-Headline 'Canadian Carnage' Trek”originalet”World Painted Blood””Release “World Painted Blood” by Slayer””Metallica Heading To Cinemas””Slayer, Megadeth To Join Forces For 'European Carnage' Tour - Dec. 18, 2010”originalet”Slayer's Hanneman Contracts Acute Infection; Band To Bring In Guest Guitarist””Cannibal Corpse's Pat O'Brien Will Step In As Slayer's Guest Guitarist”originalet”Slayer’s Jeff Hanneman Dead at 49””Dave Lombardo Says He Made Only $67,000 In 2011 While Touring With Slayer””Slayer: We Do Not Agree With Dave Lombardo's Substance Or Timeline Of Events””Slayer Welcomes Drummer Paul Bostaph Back To The Fold””Slayer Hope to Unveil Never-Before-Heard Jeff Hanneman Material on Next Album””Slayer Debut New Song 'Implode' During Surprise Golden Gods Appearance””Release group Repentless by Slayer””Repentless - Slayer - Credits””Slayer””Metal Storm Awards 2015””Slayer - to release comic book "Repentless #1"””Slayer To Release 'Repentless' 6.66" Vinyl Box Set””BREAKING NEWS: Slayer Announce Farewell Tour””Slayer Recruit Lamb of God, Anthrax, Behemoth + Testament for Final Tour””Slayer lägger ner efter 37 år””Slayer Announces Second North American Leg Of 'Final' Tour””Final World Tour””Slayer Announces Final European Tour With Lamb of God, Anthrax And Obituary””Slayer To Tour Europe With Lamb of God, Anthrax And Obituary””Slayer To Play 'Last French Show Ever' At Next Year's Hellfst””Slayer's Final World Tour Will Extend Into 2019””Death Angel's Rob Cavestany On Slayer's 'Farewell' Tour: 'Some Of Us Could See This Coming'””Testament Has No Plans To Retire Anytime Soon, Says Chuck Billy””Anthrax's Scott Ian On Slayer's 'Farewell' Tour Plans: 'I Was Surprised And I Wasn't Surprised'””Slayer””Slayer's Morbid Schlock””Review/Rock; For Slayer, the Mania Is the Message””Slayer - Biography””Slayer - Reign In Blood”originalet”Dave Lombardo””An exclusive oral history of Slayer”originalet”Exclusive! Interview With Slayer Guitarist Jeff Hanneman”originalet”Thinking Out Loud: Slayer's Kerry King on hair metal, Satan and being polite””Slayer Lyrics””Slayer - Biography””Most influential artists for extreme metal music””Slayer - Reign in Blood””Slayer guitarist Jeff Hanneman dies aged 49””Slatanic Slaughter: A Tribute to Slayer””Gateway to Hell: A Tribute to Slayer””Covered In Blood””Slayer: The Origins of Thrash in San Francisco, CA.””Why They Rule - #6 Slayer”originalet”Guitar World's 100 Greatest Heavy Metal Guitarists Of All Time”originalet”The fans have spoken: Slayer comes out on top in readers' polls”originalet”Tribute to Jeff Hanneman (1964-2013)””Lamb Of God Frontman: We Sound Like A Slayer Rip-Off””BEHEMOTH Frontman Pays Tribute To SLAYER's JEFF HANNEMAN””Slayer, Hatebreed Doing Double Duty On This Year's Ozzfest””System of a Down””Lacuna Coil’s Andrea Ferro Talks Influences, Skateboarding, Band Origins + More””Slayer - Reign in Blood””Into The Lungs of Hell””Slayer rules - en utställning om fans””Slayer and Their Fans Slashed Through a No-Holds-Barred Night at Gas Monkey””Home””Slayer””Gold & Platinum - The Big 4 Live from Sofia, Bulgaria””Exclusive! Interview With Slayer Guitarist Kerry King””2008-02-23: Wiltern, Los Angeles, CA, USA””Slayer's Kerry King To Perform With Megadeth Tonight! - Oct. 21, 2010”originalet”Dave Lombardo - Biography”Slayer Case DismissedArkiveradUltimate Classic Rock: Slayer guitarist Jeff Hanneman dead at 49.”Slayer: "We could never do any thing like Some Kind Of Monster..."””Cannibal Corpse'S Pat O'Brien Will Step In As Slayer'S Guest Guitarist | The Official Slayer Site”originalet”Slayer Wins 'Best Metal' Grammy Award””Slayer Guitarist Jeff Hanneman Dies””Kerrang! Awards 2006 Blog: Kerrang! Hall Of Fame””Kerrang! Awards 2013: Kerrang! Legend”originalet”Metallica, Slayer, Iron Maien Among Winners At Metal Hammer Awards””Metal Hammer Golden Gods Awards””Bullet For My Valentine Booed At Metal Hammer Golden Gods Awards””Metal Storm Awards 2006””Metal Storm Awards 2015””Slayer's Concert History””Slayer - Relationships””Slayer - Releases”Slayers officiella webbplatsSlayer på MusicBrainzOfficiell webbplatsSlayerSlayerr1373445760000 0001 1540 47353068615-5086262726cb13906545x(data)6033143kn20030215029