Avoid Non-Freedom Software
(Redirected from Avoid nonfree software)
Table: Finding Backdoors in Freedom Software vs Non-Freedom Software
|Non-Freedom Software (precompiled binaries)||Freedom Software (source-available)|
|Can view original source code||No||Yes|
|Compiled binary file can be decompiled into disassembly||Yes||Yes|
|Regular pre-compiled binaries.||Depends. Some use binary obfuscators.||Yes|
|Usually not using obfuscation [archive] (anti-disassembly, anti-debugging, anti-VM )||Depends. Some use.||Yes |
|Price for security audit looking for backdoors||very high ||lower|
|Difference of precompiled version versus self-compiled version||unavailable ||small or none |
|No requirement for reverse-engineering [archive]||No||Yes|
|Assembler language skills required||much more||less|
|Always legal to decompile / reverse-engineer||No  ||Yes |
|Possibility catching backdoors through observing incoming and outgoing internet connections||very difficult ||very difficult |
|Convenience of spotting backdoors||lowest convenience ||very high convenience |
|Difficulty of spotting a "direct" backdoors   ||much higher difficulty ||much lower difficulty |
|Difficulty of spotting a bugdoor ||very much higher difficulty ||lower difficulty|
|Third parties can legally software fork [archive], release a patched version without the backdoor||No ||Yes |
|Third parties can possibly make (possibly legally questionable) modifications such as disabling serial key checks ||Yes||Yes|
|Can always modify the software||No ||Yes|
|Third parties can use static code analysis tools||No||Yes|
|Third parties can judge source code quality||No||Yes|
|Third parties can find logic bugs in the source code||No||Yes|
|Third parties can find logic bugs in the disassembly||Yes||Yes|
|Can benefit from worldwide wisdom of the crowd||No||Yes|
|Third parties can benefit from debug symbols [archive] during analysis||Depends. Some may publish debug symbols.||Yes|
|Display source code intermixed with disassembly||No||Yes |
|Effort to audit subsequent releases||almost same ||usually lower |
|forum discussion [archive]|
Spotting backdoors is already very difficult in Freedom Software where the full source code is available to the general public. Spotting backdoors in non-freedom software, obfuscated binaries is much exponentially more difficult.        
Reproducible builds are a set of software development practices that create an independently-verifiable path from source to binary code.
Whilst anyone may inspect the source code of free and open source software for malicious flaws, most software is distributed pre-compiled with no method to confirm whether they correspond.
This incentivises attacks on developers who release software, not only via traditional exploitation, but also in the forms of political influence, blackmail or even threats of violence.
This is particularly a concern for developers collaborating on privacy or security software: attacking these typically result in compromising particularly politically-sensitive targets such as dissidents, journalists and whistleblowers, as well as anyone wishing to communicate securely under a repressive regime.
Whilst individual developers are a natural target, it additionally encourages attacks on build infrastructure as an successful attack would provide access to a large number of downstream computer systems. By modifying the generated binaries here instead of modifying the upstream source code, illicit changes are essentially invisible to its original authors and users alike.
The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a “correct” result, highlighting any deviations as suspect and worthy of scrutiny.
This ability to notice if a developer has been compromised then deters such threats or attacks occurring in the first place as any compromise would be quickly detected. This offers comfort to front-liners that they not only can be threatened, but they would not be coerced into exploiting or exposing their colleagues or end-users.
- Miscellaneous Threats to User Freedom
- Whonix ™ Policy on Non-Freedom Software
- non-freedom, proprietary, closed source firmware, CPU microcode and drivers
- Why Whonix ™ is Freedom Software
- Changed "back door" to "backdoor".
- https://www.techrepublic.com/article/open-source-vs-proprietary/ [archive]
- https://resources.infosecinstitute.com/topic/anti-disassembly-anti-debugging-and-anti-vm/ [archive]
- An Open Source application binary could be obfuscated in theory but depending on the application, the context (it's not an Open Source obfuscators) that would be highly suspicious. An Open Source application using obfuscators would probably be criticized in public, get scrutinized, loose user trust.
Because for non-freedom software which is usually only available as pre-compiled, possibly obfuscated binary (using an anti-decompiler):
- auditors can only look at the disassembly and cannot compare a pre-compiled version from the software vendor with a self-compiled version from source code.
- there is no well written, well commented, easily readable by design source code.
- Since there is no source code, one cannot self-build one's own binary.
- small: for non-reproducible builds (or reproducible builds with bugs)
- none: for reproducible builds
- License agreements of proprietary software often expressively forbid decompilation.
- Skype used DMCA (Digital Millenium Copyright Act) to shut down reverse engineering of Skype [archive]
- Decompilation is always legal, permitted in the license agreements of Freedom Software.
- This is very difficult since nowadays by default most outgoing connections are encrypted by default. At some point the content must be available to the computer unencrypted, in plain text, but accessing that is not trivial. When running a suspected malicious application, one cannot trust local traffic analyzers such as wireshark since the malicious application might have compromised the host operating system and hiding that information from the traffic analyzer or through a backdoor. An option might be running the application inside a virtual machine but many malicious applications actively attempt to detect virtual machines and if detected, avoid doing malicious things to avoid detection. Ultimately this might be possible, but very difficult.
- One has to decompile the binary and read "gibberish" or try to catch malicious traffic originating from the software under review. How many people decompiled for example Microsoft Office and kept doing that for every upgrade?
- Audit the source code to be free of backdoors.
- Compare the precompiled binary with a self-build binary, audit the difference. Ideally, and in future, no difference (thanks to reproducible builds project) or small difference (due to non-determinism introduced during compilation such as timestamps).
- "direct" backdoor: Such as a hardcoded username and password or login key only known by the software vendor. No plausible deniability for the software vendor.
- List of “direct” backdoors in wikipedia [archive].
One interesting “direct” backdoor was this bitcoin copay wallet backdoor.
If more than 100 BTC, steal it. Otherwise, don’t bother.
- https://www.synopsys.com/blogs/software-security/malicious-dependency-supply-chain/ [archive]
- https://github.com/dominictarr/event-stream/issues/116 [archive]
- https://github.com/dominictarr/event-stream/issues/116#issuecomment-441759047 [archive]
- Requires strong disassembly auditing skills.
- If for example hardcoded login credentials where in the published source code, that would be easy to spot. If the published source code is different from the actual source code used by the developer to compile the binary, that difference would stand out when comparing pre-compiled binaries from the software vendor with self-compiled binaries from by an auditor.
- bugdoor: A vulnerability that can be abused to gain unauthorized access. Provides plausible deniability for the software vendor. See also Obfuscated C Code Contest [archive].
- Such issues are hard to spot in the source code but even harder to spot in the disassembly.
- Forbidden in license agreement. Due to lack of source code, no serious development is possible.
- Since source code is already available under a license that permits software forks and redistribution.
- This entry is to differentiate from above legally software fork. Precompiled proprietary software is often modified by third parties such as for purposes of privacy, game modding, exploitation.
- For example, Intel ME could not be disabled in Intel CPUs yet, neither is there a Freedom Software re-implementation of Intel Microcode at time of writing.
objdump[archive] with parameter
- How does objdump manage to display source code with the -S option? [archive]
- One could review the disassembly but for subsequent releases that’s duplicating the effort. The disassembly isn’t optimized to change as little as possible or to be human understandable. If the compiled added new optimizations, compilation flags changed, that creates a much bigger diff [archive] of the disassembly.
- After the initial audit of a source-available binary, one can follow changes of the source code. To audit any newer releases, an auditor can compare the source code of the initially audited version with the new version. Unless there was a huge code refactoring or complete rewrite, the effort the audit subsequent versions is lower.
The assembler low level [archive] programming language is more difficult than other higher level abstraction [archive] programming languages according to most people saying discussing it on the internet. Example web search terms:
Source code written in higher level abstraction programming languages such as C and C++ are compiled to object code [archive] using a compiler. See this article [archive] for an introduction and this image [archive].
Source code written in lower level abstraction programming language assembler is converted to object code using an assembler. See same article and this image [archive].
Given a reasonably complex program that was written in C or C++, where the source code is unavailable, reverse engineering is very difficult. That can be deducted from the high price for it. It is possible decompile (meaning re-convert) the object code back to C with a decompiler such as for example Boomerang [archive]. Quote Boomerang: Help! I've lost my source code [archive], which is putting a price tag on it:
How much will it cost? You should expect to pay a significant amount of money for source recovery. The process is a long and intensive one. Depending on individual circumstances, the quality, quantity and size of artifacts, you can expect to pay upwards of US$15,000 per man-month.
Try to solve the question of how to disassemble a binary (byte code) into assembly source code and re-assemble (convert) to binary?
- Tricks to Reassemble Disassembly [archive]
- https://stackoverflow.com/questions/6327862/ida-pro-asm-instructions-change [archive]
- Why there are not any disassemblers that can generate re-assemblable asm code? [archive]
- https://reverseengineering.stackexchange.com/questions/3203/recompile-the-asm-file-ida-pro-created [archive]
- https://www.researchgate.net/publication/323249543_Superset_Disassembly_Statically_Rewriting_x86_Binaries_Without_Heuristics [archive]
- https://gist.github.com/jarun/ea47cc31f1b482d5586138472139d090 [archive]
- How to disassemble a binary executable in Linux to get the assembly code? [archive]
- Use GCC and objdump to disassemble any hex to assembly code [archive]
nasm -felf64 hello.asm
ld hello.o -o hello
4. objdump (optional).
objdump -d hello
5. Exercise for the reader: disassemble
The GNU Hello [archive] program source file
hello.c[archive] at time of writing contains
objdump -d /usr/bin/helloon Debian buster has
objdump -d /usr/bin/hello
- See for example how difficult it was to reverse engineer Skype. Skype Reverse Engineering : The (long) journey ;).. [archive]
- Take all the Debian package maintainer scripts. Are these easier to review as is, most of them are written
bashor if these are converted to a program written in C, closed source, precompiled?
- Do we prefer if OnionShare stays written in python, Open Source or do we prefer the project turned into a precompiled binary?
- Take all the Debian package maintainer scripts. Are these easier to review as is, most of them are written
- salary comparison
- How much does a security audit cost reverse engineering vs source-available?
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.