Malware, Computer Viruses, Firmware Trojans and Antivirus Scanners
Your support makes
all the difference!
We believe security software like Kicksecure needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 10 year success story and maybe DONATE!
- Virus is often used as a synonym for malware.
- Computer infections include viruses, trojan horses, spyware, ransomware and other categories of malware.
- Malware stands for malicious software. A computer virus is a an undesirable program running on the user's computer often without their consent or even without their knowledge.
- Preventing malware infections is very important because malware can steal your identity, passwords, accounts, impersonate you, steal all your private data, you risk getting SWATTed and more.
- Computer security, a computer that is free of malware, requires a security concept. Just only installing an antivirus scanner is insufficient.
- Detection and removal of malware is a hard problem. The utility of antivirus tools is actually rather limited. A much safer security concept needs to focus on prevention of malware infections, not on malware detection.
The Importance of a Malware Free System
Malware has malicious intent and can potentially: 
- View and take snapshots of the desktop.
- Peruse files and folders.
- Gain access to protected data when decrypted.
- Exfiltrate, corrupt or destroy data (particularly financial and personal information).
- Plant fabricated evidence.
- Damage operating system functionality.
- Encrypt the data of a drive(s) and demand payment for decryption (ransomware).
- Display unwanted advertising.
- Install unwanted software.
- Install persistent rootkits or backdoors.
- Track browsing and other behaviour.
- Remotely turn on webcams and microphones.
- Create "zombie" computers which form part of a botnet for spam email, DDOS attacks or the hosting of illicit / illegal material which might result in getting SWATted.
- Record everything a user types, sends and receives.
The integrity of the host is a critical part of the system's Trusted Computing Base. If the host system is compromised by malware, so is every virtual machine (VM).
- Kicksecure is based on Debian and using the Linux kernel. There exists much less malware for Linux generally.
- Kicksecure comes with many security features.
- The more you know, the safer you can be. See Documentation.
Targeted Malware vs Off-The-Shelf Malware
Targeted malware is the opposite of off-the-shelf malware. Targeted malware is specifically crafted against a known target to attack a specific system or limited amount of systems only. The goal is to avoid detection by not being installed on too many systems where qualified people might detect the malware and publish the findings.
On the other hand, off-the-shelf malware attempts to spread in bulk against larger groups or the general public with the goal of taking over as many systems as possible. It should be noted that malware tools are widely available, with proof-of-concept ransomware even existing on GitHub at the time of writing. For example, the "DemonWare" tool can be utilized to create malicious payloads for ransomware, adware or general malware purposes on the Windows, Linux and macOS platforms: 
Your Ransomware As A Service (RAAS) Tool for all your hacking needs. ... This was made to demonstrate ransomware and how easy it is to make. It works on Windows, Linux and MacOS. It's recommended to compile payload.py to EXE to make it more portable. ... This script does not get detected by any anti-virus. Self made scripts go undetected 99% of the time. It's easy to write something nasty like ransomware, adware, malware, you name it. ... I recommend a VPN that allows port forwarding (For example; PIA VPN) when using this outside your network, or better, a cloud computer hosted elsewhere, like Amazon AWS. The conclusion of this project is that it is easy to brick a system and earn money doing it. This script doesn't use any exploits to achieve its goal, but can easily be coded into it as a nice feature.
Malware creators are likely to utilize existing software samples to create more pernicious tools with features like: greater payload customization (custom files), man-in-the-middle and DNS poisoning (website redirection), email payloads and email spoofing, anti-virus or other detection warnings, focused data gathering (passwords or other sensitive files), detection of mounted drives (for encryption), encrypted transfer of traffic between payloads and malicious servers, and much more.
The Utility of Antivirus Tools
Antivirus products and personal firewalls are not drop in solutions for a secure host. Malware can often stay undetected and evade scans, while application level personal firewalls are often circumvented.  Polymorphic code and rootkits essentially render antivirus products helpless.  
The following paragraph is currently being discussed.
Antivirus tools are actually worse than useless. In the case of sophisticated and targeted attacks, the antivirus software can serve as a pathway to exploiting a system's kernel, since they almost always run with administration level privileges.  Some antivirus software also harms privacy by sending system files back to the company servers for analysis.  The software also actively conducts man-in-the-middle attacks on secure SSL connections, enabling very sensitive information to be inspected. 
Preventing Malware Infections
The optimal scenario is to avoid infection by malware in the first place. Once malicious code has accessed a system, it is next to impossible to contain. Sensible steps include: hardening the operating system, carefully vetting programs and files that are retrieved from the Internet, using hypervisors (virtualizers) to isolate software that processes untrusted data, and periodically deleting and recreating virtual machines that are used for sensitive operations. 
In the event a system compromise is strongly suspected or confirmed, the ultimate goal is to re-establish a trusted, private environment for future activities -- see Compromise Recovery for techniques to recover from Kicksecure ™ (host or VM) infections.
Detecting Malware Infections
Detecting off-the-shelf (standardized) malware is a very hard problem and conceptually a lost cause. If uncustomized malware is widespread enough, then it has a chance of being detected by a technician. Targeted malware might also get detected by a technician, but the likelihood is low unless they are lucky or gifted.
Non-technical users do not have many good options. They can either:
- Spend a few years to rapidly increase their knowledge base of operating systems, network protocols, package analysis, programming, disassembly etc., and then try their luck.
- Pay exorbitant sums to a technician to try and find system malware, even though there is no certainty of success.  
- Or seek the voluntary assistance of a technician to find malware, if they are both a high value target and have a reasonable rationale for why they are likely compromised. 
Valid Compromise Indicators versus Invalid Compromise Indicators
If trivial changes are noticed on your system -- such as a duplicate desktop icon -- this is not evidence of malware, a hack or leak. Similarly, if warning or error messages appear that are difficult to understand, in most cases there is no need for panic. If something unexpected occurs such as the appearance of a "htaccess file in home directory", or graphical glitches emerge in some applications, then it is more likely a harmless bug and/or usability issue rather than a compromise. Never in the history of malware analysis, security researchers relied on unexpected occurrences such as duplicate desktop icons. Malware analysis is a skill requires studying malware detection techniques. It's not a skill that can be causally picked up by pure observation and guesswork.
Skilled attackers do not leave such obvious traces of their breach. An infection by tailored malware is more plausible in this scenario and this is virtually impossible to detect by reading random messages in system logs. Even malware that is bought off-the-shelf (malware building toolkits) are unlikely to be discovered by cursory inspections.  Rootkit technology is no doubt a standard feature of the various programs.
Strange files, messages or other system behavior could feasibly relate to an attacker wanting the user to find something. However, the likelihood of this kind of harassment is considered low. Script kiddies ("skiddies") are unskilled attackers who uses scripts or programs to conduct attacks on computer systems and networks, most often with juvenile outcomes. For example, they might use programs to remotely control poorly-secured Microsoft Windows desktops, trolling their victims from an open, forced chat window, opening their DVD drive and so on. It is improbable that skiddies can achieve similar exploits against Linux, Xen or BSD platforms.  Sophisticated attackers (which are likely to use tailored malware) generally avoid detection, unless the user is unlucky enough to be a victim of Zersetzung (a psychological warfare technique).
Every forum post and support request requires time that could otherwise be directed to Kicksecure ™ development. Unless there is genuine evidence of a serious and credible problem, there is no need for a new post. See also Support Request Policy (rationale). Developers and the Kicksecure ™ community at large do not have enough time to explain every message that Linux might report. In most cases, they are not important and outside the control of Kicksecure ™ developers.
False-Positive Antivirus Reports
When an antivirus program reports having found a virus or other issue, it doesn't necessarily mean that there is an actual issue. According to AV comparatives and many other sources, there are false-positive reports, also known as false alarms. For example, you can see the results of the False Alarm Test March 2022. A virus or issue found report is, at best, an indication that there could be an issue, but there is no definitive proof.
Furthermore, the usefulness of antivirus reports is limited because, for most (if not all) commercial vendors of antivirus software, it is not easy or even impossible for the user and outside developers to get in contact with a malware analyst at the antivirus company to receive further information, virus confirmation, bug reports, and so forth.
This issue is exacerbated by commercial antivirus software and their database, which are usually closed source or even obfuscated. Therefore, even outside developers have a hard time investigating virus reports.
Proofing an Actual Security Vulnerability
To prove that there is an actual security issue, more than a report by an antivirus scanner is required. This is due to the possibility of false alarms by antivirus software.
Proof of actual vulnerabilities could include showing a code issue in the source code, in the disassembly, malicious behavior in a debugger, a capture of the network traffic from a packet analyzer or proof of concept (PoC) exploit.
Attribution of Security Vulnerabilities to Software
If a file is reported as infected by a virus scanner it does not necessarily follow that the reported file is the origin of the virus. This is due to file-infecting viruses.
What is a file-infecting virus? A file-infecting virus is a type of malware that infects files with the intent to cause permanent damage, make them unusable or spread itself to make detection and removal of the virus harder. A file-infecting virus injects its own code into different files.
False-Positive Log Reports
Reminder: Kicksecure ™ is not perfect. The security issues facing society are great, but there are few volunteers who are seriously investing the effort to challenge and resolve them.
Users with a serious intention to research these issues are encouraged to assist in accordance with their skills. Testing, bug reporting or even bug fixing are laudable endeavors. If this process is unfamiliar, understand that about thirty minutes is required per message / identifier to ascertain if the discovered result  is a false positive, regression, known or unknown issue.
It is unhelpful to ask questions in forums, issue trackers and on various mailing lists with concerns that have already been discussed, or which are known issues / false positives. In all cases, please first search thoroughly for the result that was found. Otherwise, the noise to signal ratio increases and Kicksecure ™ development is hindered. Users valuing security don't want this, otherwise this would violate the aforementioned assumption.
If something is identified that appears to be a Kicksecure ™-specific issue, please first read the Free Support Principle before making a notification.
Once a user is infected with very sophisticated malware that modifies low-level firmware, it is extremely difficult to detect in almost all cases.
Firmware infections should not be confused with hardware/circuit trojans, which are malicious modifications made to machine components during the manufacturing process. Despite their sophistication, circuit trojans are not immune to detection. 
Virtualizers and Hardware Compromise
Virtualizers like Qubes, VirtualBox and KVM cannot absolutely prevent the compromise of hardware. Running all activities inside VMs is a very reasonable approach. However, this only raises the bar and makes it more difficult and/or expensive to compromise the whole system. It is by no means a perfect solution.
No distribution of Linux, BSD, Xen or any other variant can solve the issue of needing to dispose of potentially infected hardware. Hardware-specific issues can really only be fixed at the hardware level. At best, software interventions can only provide workarounds.
The Promise of Libre Firmware
The problem is no hardware exists that consists of entirely Libre firmware. It is very difficult to analyze the firmware of hardware, wipe potentially compromised versions, or overwrite firmware with a most-likely-clean version.
Even if a user wholly depended on Libre firmware, this would only make verification easier but it could not stop infection. Disassembling hardware components -- BIOS, disk controllers, CPU, Intel AMT and so on -- and flashing them with clean versions offline is extremely difficult. It is simply cheaper and more convenient to buy new hardware.
The bundling of undesirable anti-features like DRM in closed firmware is further evidence that Libre firmware is needed, in addition to Libre hardware designs.
A hypothetical stateless computer   would solve the problem of malware persistence, but it still could not protect against the damage (data-exfiltration) caused by successful exploitation.
Non-Freedom Software (precompiled binaries) should be avoided. because it is easier to hide backdoors. Freedom Software (source-available) should be preferred becuase it is more difficult to hide backdoors.
Table: Finding Backdoors in Freedom Software vs Non-Freedom Software
|Non-Freedom Software (precompiled binaries)||Freedom Software (source-available)|
|Original source code is reviewable||No||Yes|
|Compiled binary file can be decompiled into disassembly||Yes||Yes|
|Regular pre-compiled binaries||Depends ||Yes|
|Obfuscation (anti-disassembly, anti-debugging, anti-VM)  is usually not used||Depends ||Yes |
|Price for security audit searching for backdoors||Very high ||Lower|
|Difference between precompiled version and self-compiled version||Unavailable ||Small or none |
|Reverse-engineering is not required||No||Yes|
|Assembler language skills required||Much more||Less|
|Always legal to decompile / reverse-engineer||No  ||Yes |
|Possibility of catching backdoors via observing incoming/outgoing Internet connections||Very difficult ||Very difficult |
|Convenience of spotting backdoors||Lowest convenience ||Very high convenience |
|Difficulty of spotting "direct" backdoors   ||Much higher difficulty ||Much lower difficulty |
|Difficulty of spotting a "bugdoor" ||Much higher difficulty ||Lower difficulty|
|Third parties can legally release a software fork, a patched version without the backdoor||No ||Yes |
|Third parties can potentially make (possibly illegal) modifications like disabling serial key checks ||Yes||Yes|
|Software is always modifiable||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|
|Benefits from population-scale scrutiny||No||Yes|
|Third parties can benefit from debug symbols during analysis||Depends ||Yes|
|Display source code intermixed with disassembly||No||Yes |
|Effort to audit subsequent releases||Almost same ||Usually lower |
|Forum discussion: Finding Backdoors in Freedom Software vs Non-Freedom Software|
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 composed of obfuscated binaries is exponentially more difficult.         
To further improve the situation in the future, the Freedom Software community is working on the Reproducible Builds project. Quote:
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.
Several free software projects already, or will soon, provide reproducible builds.
It is theoretically possible to discover malware by comparing an already used/booted, supported VM image such as a VirtualBox
.ova image or Qubes template with the original. However, at the time of writing this is infeasible for Kicksecure ™ developers.
Quote security researcher, Joanna Rutkowska, founder of Qubes OS:
The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised. True, there is a number of conditions that can warn us that the system is compromised, but there is no limit on the number of checks that a system must pass in order to be deemed “clean”.
Professional malware audits require a completely different skill set to software development, such as forensic and research capabilities, along with a laboratory facility. An analogy is expecting a professional chef to identify the source and quality of every ingredient used in an already cooked meal; this expectation is completely unrealistic. Like most, if not all Linux distributions, Kicksecure ™ relies upon many different software packages which are developed by countless independent parties; see Linux User Experience versus Commercial Operating Systems to learn more about the Linux organizational structure.
The likelihood of discovering purposeful modifications is low until fully reproducible builds (or at least Verifiable Builds) are available. Presently there is not a single Linux distribution installation whose image can be re-built deterministically by independent third parties. That means introduced modifications cannot be easily discovered during the compilation process. As the Reproducible Builds project has stated:
The motivation behind the Reproducible Builds project is therefore to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process.
As the Qubes OS project has stated:
(A “rebuilder” is a program that takes a binary and its purported source code as inputs, along with any applicable metadata, and attempts to build an identical binary from the source code. The goal is to check whether the binary was really compiled from its claimed source code.)
Proper malware audit capabilities are conditional upon several key milestones:
- Completion of Debian's Reproducible Builds project -- 91% of packages currently build reproducibly in Debian
- All packages build reproducibly in Debian and other Linux distributions.
- The Linux distribution policy mandates package repoducibility.
- Independent package rebuilders become available.
- Note that reproducible package builds are not equivalent to reproducible installed packages. 
- The Reproducible Builds project works towards reproducible installation CD/DVD images. 
- Independent installation image rebuilders become available.
- Reproducible VM images become feasible.
- Independent VM image rebuilders become available.
- Auditing already used (VM) images is increasingly feasible.
To date only the first milestone has been partially accomplished. Completing the remaining prerequisite milestones will probably take many years of difficult engineering work.
Watering Hole Attacks
It should be noted that advanced malware can infect a user's computer via a Watering Hole Attack. This vector has similarities to the software version of a Supply Chain Attack, and these methods are not mutually exclusive: 
A watering hole attack is a malware attack in which the attacker observes the websites often visited by a victim or a particular group, and infects those sites with malware. A watering hole attack has the potential to infect the members of the targeted victim group. Although uncommon, a watering hole attack does pose a significant threat to websites, as these attacks are difficult to diagnose.
In the case of Kicksecure ™ users, any future attempt would logically target hosted content on GitHub, SourceForge, various forum locations, mirrors, popular documentation links, and frequently visited security and anonymity sites like Tails, The Tor Project and so on.  The hope is that developers, contributors and general users of the software become infected with stealthy malware that is immune to detection.
The attack involves a few steps:  
- Zero-day or other vulnerabilties target the website software.
- The code redirects visitors to a different site that serves "malvertisments" or malware masquerading as legitimate software.
- Once installed, the malware can infect various members of the targeted group.
It should be noted that advanced adversaries are capable of gaining knowledge about the behavioral patterns of target groups -- where they congregate, topics of research, related interests, and handle mapping of anonymous networks. This generic browsing and membership knowledge, along with observed security practices, greatly narrows the number of specific sites that need be targeted and the suitable attack mode. One way to mitigate this threat is to rigorously inspect websites for malicious code.
Interested readers can learn about six recent watering hole attacks targeting the US, China, banks and other entities here.
- Mental Model
- Threat Modeling
- Disaster Recovery
- Factory Reset
- Operating System Software and Updates
- System Hardening Checklist
- Firmware Security and Updates
- Open-source Hardware
- ↑ https://en.wikipedia.org/wiki/Malware
- ↑ https://github.com/junseul/Ransomware_RAASNet/blob/master/RAASNet.py
- ↑ https://www.grc.com/lt/leaktest.htm
- ↑ https://arstechnica.com/security/2014/05/antivurus-pioneer-symantec-declares-av-dead-and-doomed-to-failure/
- ↑ A botnet author brags in this thread of writing unbeatable malware and trolling antivirus vendors.
- ↑ https://theintercept.com/2015/06/22/nsa-gchq-targeted-kaspersky/
- ↑ https://www.schneier.com/blog/archives/2017/10/more_on_kaspers.html
- ↑ https://bugs.chromium.org/p/project-zero/issues/detail?id=978
- ↑ For instance, in Kicksecure ™ for Qubes this would involve the occasional deletion and recreation of Kicksecure ™ and Kicksecure ™ AppVMs.
- ↑ The salary costs for a security researcher / malware analyst over an extended period rule this out for most individuals.
- ↑ https://forums.whonix.org/t/document-recovery-procedure-after-compromise/3296/12
- ↑ Only a select group of people fall into this group, for instance, whistleblowers targeted and infected by targeted viruses. Experts might be located who are willing to conduct analysis pro bono; later publicizing their findings for the public benefit.
- ↑ Interested readers can verify these claims by researching off-the-shelf malware building toolkits. They are dangerous to install for inexperienced users, but there is a wealth of information online such as screenshots and video tutorials.
- ↑ It is unclear if script kiddie programs are readily available for attacking non-Microsoft Windows users.
- ↑ From a browser test website, in a log file and so on.
- ↑ https://en.wikipedia.org/wiki/Hardware_Trojan#Detection
- ↑ https://blog.invisiblethings.org/2015/12/23/state_harmful.html
- ↑ https://github.com/rootkovska/state_harmful/blob/master/state_harmful.md
- ↑ Some use binary obfuscators.
- ↑ https://resources.infosecinstitute.com/topic/anti-disassembly-anti-debugging-and-anti-vm/
- ↑ Some use obfuscation.
- ↑ An Open Source application binary could be obfuscated in theory. However, depending on the application and the context -- like not being an Open Source obfuscator -- that would be highly suspicious. An Open Source application using obfuscators would probably be criticized in public, get scrutinized, and lose user trust.
This is because non-freedom software is usually only available as a 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 source code that is well-written, well-commented, and easily readable by design.
- ↑ 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
- ↑ Decompilation is often expressly forbidden by license agreements of proprietary software.
- ↑ Skype used DMCA (Digital Millenium Copyright Act) to shut down reverse engineering of Skype
- ↑ Decompilation is always legal and permitted in the license agreements of Freedom Software.
- ↑ 29.0 29.1 This is very difficult because most outgoing connections are encrypted by default. At some point the content must be available to the computer in an unencrypted (plain text) format, but accessing that is not trivial. When running a suspected malicious application, local traffic analyzers like Wireshark cannot be trusted. The reason is the malicious application might have compromised the host operating system and be hiding that information from the traffic analyzer or through a backdoor. One possible option might be running the application inside a virtual machine, but many malicious applications actively attempt to detect this configuration. If a virtual machine is identified, they avoid performing malicious activities to avoid being detected. Ultimately this might be possible, but it is still very difficult.
- ↑ It is necessary to decompile the binary and read "gibberish", or try to catch malicious traffic originating from the software under review. As an example, consider how few people would have decompiled Microsoft Office and kept doing that for every upgrade.
It is possible to:
- Audit the source code and confirm it is free of backdoors.
- Compare the precompiled binary with a self-built binary and audit the difference. Ideally, and in future, there will be no difference (thanks to the Reproducible Builds project) or only a small difference (due to non-determinism introduced during compilation, such as timestamps).
- ↑ An example of a "direct" backdoor is a hardcoded username and password or login key only known by the software vendor. In this circumstance there is no plausible deniability for the software vendor.
- ↑ List of “direct” backdoors in wikipedia.
One interesting “direct” backdoor was this bitcoin copay wallet backdoor:
If more than 100 BTC, steal it. Otherwise, don’t bother.
- ↑ Requires strong disassembly auditing skills.
- ↑ If for example hardcoded login credentials were 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 by an auditor.
- ↑ A "bugdoor" is a vulnerability that can be abused to gain unauthorized access. It also provides plausible deniability for the software vendor. See also: Obfuscated C Code Contest.
- ↑ Such issues are hard to spot in the source code, but even harder to spot in the disassembly.
- ↑ This is forbidden in the 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 the concept immediately above. Pre-compiled proprietary software is often modified by third parties for the purposes of privacy, game modifications, and exploitation.
- ↑ For example, Intel ME could not be disabled in Intel CPUs yet. At the time of writing, a Freedom Software re-implementation of Intel microcode is unavailable.
- ↑ Some may publish debug symbols.
- How does objdump manage to display source code with the -S option?
- ↑ It is possible to review the disassembly, but that effort is duplicated for subsequent releases. The disassembly is not optimized to change as little as possible or to be easily understood by humans. If the compiled version added new optimizations or compilation flags changed, that creates a much bigger diff of the disassembly.
- ↑ After the initial audit of a source-available binary, it is possible to follow changes in 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 audit effort for subsequent versions is lower.
The consensus is the assembler low level programming language is more difficult than other higher level abstraction programming languages. Example web search terms:
Source code written in higher level abstraction programming languages such as C and C++ are compiled to object code using a compiler. See this article for an introduction and this image.
Source code written in lower level abstraction programming language assembler is converted to object code using an assembler. See the same article above and this image.
Reverse engineering is very difficult for a reasonably complex program that is written in C or C++, where the source code is unavailable; that can be deduced from the high price for it. It is possible to decompile (meaning re-convert) the object code back to C with a decompiler like Boomerang. To put a price tag on it, consider this quote -- Boomerang: Help! I've lost my source code:
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.
The following resources 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
- IDA pro asm instructions change
- Why there are not any disassemblers that can generate re-assemblable asm code?
- Recompile the asm file IDA pro created
- Superset Disassembly: Statically Rewriting x86 Binaries Without Heuristics
- GitHub: Guide to disassemble - disassemble.md
- How to disassemble a binary executable in Linux to get the assembly code?
- Use GCC and objdump to disassemble any hex to assembly code
1. Take a hello world assembler source code.
nasm -felf64 hello.asm
ld hello.o -o hello
4. objdump (optional).
objdump -d hello
5. Exercise for the reader: disassemble
The GNU Hello program source file
hello.cat the time of writing contains
objdump -d /usr/bin/helloon Debian buster has
hello. To accomplish that, the following steps A. to D. need to be done.
A. Update the package lists.
sudo apt update
B. Upgrade the system.
sudo apt full-upgrade
C. Install the
aptcommand line parameter
--no-install-recommendsis in most cases optional.
sudo apt install --no-install-recommends hello
The procedure of installing
objdump -d /usr/bin/hello
- Consider all the Debian package maintainer scripts. Clearly these are easier to review as is, since most of them are written in
bash. Review would be difficult if these were converted to a program written in C, and were closed source and precompiled.
- Similarly, it is far preferable for OnionShare to stay Open Source and written in python, rather than the project being turned into a precompiled binary.
- Python: 77 - 92 - 108
- Python: 51 - 79 - 107
- C: 56 - 80 - 100
- C: 49 - 80 - 112
- Malware reverse engineering: 101 - 124 - 149
- Assembler: 81 - 104 - 131
- Malware Analyst: 75 - 115 - 141
Quote research paper Android Mobile OS Snooping By Samsung, Xiaomi, Huawei and Realme Handsets:
Reverse Engineering A fairly substantial amount of non-trivial reverse engineering is generally required in order to decrypt messages and to at least partially decode the binary plaintext. 1) Handset Rooting: The first step is to gain a shell on the handset with elevated privileges, i.e. in the case of Android to root the handset. This allows us then to (i) obtain copies of the system apps and their data, (ii) use a debugger to instrument and modify running apps (e.g. to extract encryption keys from memory and bypass security checks), and (iii) install a trusted SSL root certificate to allow HTTPS decryption, as we explain below. Rooting typically requires unlocking the bootloader to facilitate access to the so-called fastboot mode, disabling boot image verification and patching the system image. Unlocking the bootloader is often the hardest of these steps, since many handset manufacturers discourage bootloader unlocking. Some, such as Oppo, go so far as to entirely remove fastboot mode (the relevant code is not compiled into the bootloader). The importance of this is that it effectively places a constraint on the handset manufacturers/ mobile OSes that we can analyse. Xiaomi and Realme provide special tools to unlock the bootloader, with Xiaomi requiring registering user details and waiting a week before unlocking. Huawei require a handset-specific unlock code, but no longer supply such codes. To unlock the bootloader on the Huawei handset studied here, we needed to open the case and short the test point pads on the circuit board, in order to boot the device into the Huawei equivalent of Qualcomm’s Emergency Download (EDL) mode. In EDL mode, the bootloader itself can be patched to reset the unlock code to a known value (we used a commercial service for this), and thereby enable unlocking of the bootloader.
Decompiling and Instrumentation On a rooted handset, the Android application packages (APKs) of the apps on the /system disk partition can be extracted, unzipped and decompiled. While the bytecode of Android Java apps can be readily decompiled, the code is almost always deliberately obfuscated in order to deter reverse engineering. As a result, reverse engineering the encryption and binary encoding in an app can feel a little like exploring a darkened maze. Perhaps unsurprisingly, this is frequently a time-consuming process, even for experienced researchers/practitioners. It is often very helpful to connect to a running system app using a debugger, so as to view variable values, extract encryption keys from memory, etc.
The research paper describes in far more detail the highly complicated technical challenges of reverse engineering.
/varare auto generated at package installation time.