A binary file is broadly defined as a file containing a sequence of arbitrary bytes. The name is related to the fact that bytes consist of bits, i.e. binary digits. Operating systems and programming libraries may provide for special processing of text files as opposed to binary files. For example, in MS-DOS and Windows, the C standard input-output library is implemented in such a way that when the file is opened in “text” mode, the sequence of characters rn is read as a single character n. Also, the ^Z character there is treated as the end of a text file, so anything after that character is ignored when reading the file in text mode. But if the file was opened in “binary” mode, then reading and writing occurs strictly byte by byte, without any transformations. In the narrow sense of the word, binary files are opposed to text files. At the same time, from the point of view of technical implementation at the hardware level, text files are a special case of binary files, and thus, in the broadest sense of the word, any file can be defined as a binary file.
Binary format is a format in which information is written using a sequence of bytes. It is called binary because all entries inside the file are made using only “1” and “0”. This format is also called binary, which is not a mistake. The binary format is the opposite of the text format. Conventionally, any information for a computer can be recorded either in binary or text format. By the way, code written in any programming language is a text format. The text format is understandable by humans, and the binary format is understandable by computers. But if you dig “deeper” into the comparison of text and binary format and look from the technical implementation, then you can find out that the text format is, in fact, a kind of binary format. Any text file is converted to binary so that it can be “read” by a computer. And any text character corresponds to a binary combination of characters, so technically every format used in a computer is binary.
Dorothy2 is a platform designed to analyze suspicious binaries. Its main advantages are a very flexible modular environment and an interactive research structure with a special focus on network analysis. In addition, it is able to recognize newly spawned processes by comparing them with a previously created baseline. Static binary analysis and improved system behavior analysis will be introduced in future releases. Dorothy2 analyzes binaries using predefined analysis profiles. Using profiles allows the researcher to perform analysis on a set of binaries using different environments. As you know, some malicious programs are configured to work only in a certain environment. CSIRT can only use them to test suspected malware in an environment that mirrors that of its customers. Sources can also be configured to be automatically analyzed by specific profiles. The analysis profile consists of the following elements: A specific type of OS sandbox. A specific OS version of the isolated software environment. A specific OS language is sandboxed. Fixed analysis waiting time. Number of screenshots requested. List of supported extensions and how they should be implemented by the guest OS. The framework consists of five modules that can be executed separately.
HaboMalHunter is a subproject that can be used for automated malware analysis and security assessment on a Linux system. The tool helps security analysts efficiently and effectively extract static and dynamic features from malware. The generated report provides essential information about the process, file I/O, network and system calls.
BinAbsInspector is a static analyzer for automated reverse engineering and vulnerability scanning in binaries, which is a long-term research project incubated at Keenlab. It is based on an abstract interpretation supported by Ghidra. It runs on Pcode Ghidra instead of assembly. It currently supports x86, x64, armv7 and aarch64 binaries. You can run BinAbsInspector in headless mode, GUI mode, or using docker.
Сwe_checker is a set of checks to detect common classes of errors such as null pointer dereferences and buffer overflows. These classes of errors are formally known as Common Weakness Lists (CWEs). The checks are based on a variety of analysis methods, ranging from simple heuristics to data flow analysis based on abstract interpretation. Its main purpose is to help analysts quickly find potentially vulnerable code paths. Its main focus is ELF binaries, which are commonly found in Linux and Unix operating systems. cwe_checker uses Ghidra to parse the binaries into one common intermediate representation and implements its own analysis of this IP. Consequently, analyzes can be performed on most CPU architectures that Ghidra can parse, making cwe_checker a valuable tool for firmware analysis.
BinCAT is a static binary code analysis toolkit designed to aid in reverse engineering directly from IDA or using Python for automation. It has: value analysis (registers and memory), pollution analysis, type reconstruction and propagation, reverse and forward analysis of usage detection after free and double releases. So is the source file and /bin/cat – the self-extracting file is executed. You can erase /bin/cat after making sure that /bin/cat works fine. This utility is most useful on systems with very small disks.