Can I rely on these GitHub repository files?
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
New contributor
add a comment |
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
New contributor
3
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
14
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
23 hours ago
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
19 hours ago
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
10 hours ago
add a comment |
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
New contributor
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
reverse-engineering c++ github
New contributor
New contributor
edited yesterday
Peter Mortensen
70049
70049
New contributor
asked yesterday
mcruz2401mcruz2401
9615
9615
New contributor
New contributor
3
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
14
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
23 hours ago
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
19 hours ago
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
10 hours ago
add a comment |
3
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
14
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
23 hours ago
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
19 hours ago
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
10 hours ago
3
3
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
14
14
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
23 hours ago
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
23 hours ago
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
19 hours ago
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
19 hours ago
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
10 hours ago
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
10 hours ago
add a comment |
3 Answers
3
active
oldest
votes
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.
New contributor
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
add a comment |
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.
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
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
yesterday
1
Reproducible builds solve this problem.
– forest
23 hours ago
add a comment |
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.
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
add a comment |
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
});
}
});
mcruz2401 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
New contributor
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
add a comment |
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.
New contributor
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered 23 hours ago
DavidmhDavidmh
28615
28615
New contributor
New contributor
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
add a comment |
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
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
16 hours ago
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
16 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
@TobySpeight good point, I shall investigate and correct.
– Davidmh
10 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
…and even a honest author might be unknowingly infected by some malware.
– spectras
5 hours ago
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
1 hour ago
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
1 hour ago
add a comment |
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.
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
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
yesterday
1
Reproducible builds solve this problem.
– forest
23 hours ago
add a comment |
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.
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
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
yesterday
1
Reproducible builds solve this problem.
– forest
23 hours ago
add a comment |
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.
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.
answered yesterday
PolynomialPolynomial
101k32249342
101k32249342
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
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
yesterday
1
Reproducible builds solve this problem.
– forest
23 hours ago
add a comment |
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
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
yesterday
1
Reproducible builds solve this problem.
– forest
23 hours ago
32
32
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
Even that isn't going to be reliable across optimization levels.
– chrylis
yesterday
40
40
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
yesterday
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
yesterday
1
1
Reproducible builds solve this problem.
– forest
23 hours ago
Reproducible builds solve this problem.
– forest
23 hours ago
add a comment |
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.
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
add a comment |
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.
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
add a comment |
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.
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.
answered 18 hours ago
Dmitry GrigoryevDmitry Grigoryev
7,6462144
7,6462144
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
add a comment |
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
3
3
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
Of course, Ken Thompson may disagree.
– Jörg W Mittag
16 hours ago
1
1
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
@JörgWMittag If you can't trust trust, who can you trust?
– apsillers
15 hours ago
add a comment |
mcruz2401 is a new contributor. Be nice, and check out our Code of Conduct.
mcruz2401 is a new contributor. Be nice, and check out our Code of Conduct.
mcruz2401 is a new contributor. Be nice, and check out our Code of Conduct.
mcruz2401 is a new contributor. Be nice, and check out our Code of Conduct.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
3
If you're able to compile from source, then just use your computer version.
– Daisetsu
yesterday
14
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
23 hours ago
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
19 hours ago
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
10 hours ago