This document discusses methods for bypassing antivirus scanners by encoding malicious files. It begins with an introduction to how antivirus software works and common file formats. It then explains how to find and modify signatures within portable executable (PE) files to evade detection. The document demonstrates implementing a custom encoder that loops through and alters bytes in the text section of a PE file. It also describes how to hijack the entry point and re-route execution to the encoded region. Finally, it shows how to alter the encoder to function as a decoder to execute the encoded file stealthily. The goal is to educate on techniques that could bypass antivirus detection, while noting this is intended for educational purposes only.
This lab document describes using the Metasploit framework to perform exploits against Windows systems. It consists of six sections: installing Metasploit, adding a remote user to Windows XP, gaining remote command shell access to Windows XP, using DLL injection to open a remote VNC connection, remotely installing a rootkit on Windows, and setting up the Metasploit web interface. The document provides background on exploit frameworks and payloads, and guides students through exercises to complete each section.
Black hat 2010-bannedit-advanced-command-injection-exploitation-1-wprgster
This document discusses techniques for exploiting command injection vulnerabilities beyond just getting a shell. It proposes designing a reliable command injection payload stager for Windows using Metasploit. The stager would reuse the established connection to transfer a payload instead of relying on network tools like SSH or FTP, improving reliability. It explores using WScript to execute a VBScript payload instead of debug.exe since it's been removed from newer Windows versions. Encoding the payload is important to avoid filters or out of order execution on multithreaded servers.
This document discusses debugging fundamentals and provides an overview of different debuggers. It summarizes how debuggers like Immunity Debugger, WinDbg, and OllyDbg work to test and troubleshoot target programs. The document also introduces security fuzzers and describes how they work with debuggers to detect vulnerabilities by providing unexpected input data to programs and monitoring for exceptions or memory leaks. An example is provided of using the Immunity Debugger and Infigo FTPStress Fuzzer to analyze and attempt to crash an FTP server.
This document discusses attacking and exploiting antivirus software. It begins by describing how antivirus engines work and how their functionality can increase vulnerabilities. The document then details initial experiments fuzzing 14 antivirus engines, finding remote and local vulnerabilities. Specific vulnerabilities are listed for various antivirus products. Statistics on fuzzing various engines are provided. The document concludes by discussing remote exploitation of antivirus engines, noting that despite ASLR, many engines still have exploitable issues due to non-ASLR modules or RWX pages. The emulators used by antivirus engines are highlighted as a key part that can bypass some protections.
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...Zohar Babin
OSCON 2014 tutorial workshop lead by Jess Portnoy (@jess_port01) covering the use of various useful debugging tools, both general and specific to web apps.
It focuses on PHP based apps but vast parts of it are useful for other commonly used open sourced, interpreted languages.
Covering tools such as
1. GDB [for debugging the PHP engine and extensions, written in C/C++]
2. Xdebug [for debugging PHP code]
3. Shell utilities for better inspection of error and access logs such as ccze, efficient use of grep,sed.
4. Tracing processes with strace and more.
The session also featured several, real life examples such as:
1. A PHP extension causing seg faults
2. Reviewing Apache access and error logs to discover bad VHost configurations and rewrite rules
3. Various badly set PHP directives causing malfunctions
4. Debugging PHP code using Xdebug
Participants took part in the debugging process, and were asked to make suggestions as to how to advance and be prompted to share cases they’ve had, solved or did solve.
This document discusses techniques for improving the performance of fuzzing programs. It explains that most CPU cycles in fuzzing are wasted on program loading and initialization rather than actual fuzzing. The document recommends optimizing target selection to minimize code size, using smaller input files, and selecting mutators that are most likely to trigger new code paths. It also discusses using techniques like in-memory fuzzing and thin wrappers to improve efficiency. Overall it emphasizes the importance of quantitative and qualitative analysis to optimize fuzzer designs and strategies.
The document provides an overview of how to build a fully automated server deployment system using open source tools such as Request Tracker, Nictool/djbdns, dhcpd, PXEboot, Httpd, a yum repository, and Puppet. Key aspects include using an asset tracker (Request Tracker) to store server information and trigger automated builds. A PXE boot script generates configuration files using data from the asset tracker. A CGI script generates customized Kickstart files which install servers. Puppet then configures and deploys applications to servers based on their roles defined in the asset tracker. The goal is to achieve repeatable, consistent server builds from bare metal to a live application server within an hour with no
This lab document describes using the Metasploit framework to perform exploits against Windows systems. It consists of six sections: installing Metasploit, adding a remote user to Windows XP, gaining remote command shell access to Windows XP, using DLL injection to open a remote VNC connection, remotely installing a rootkit on Windows, and setting up the Metasploit web interface. The document provides background on exploit frameworks and payloads, and guides students through exercises to complete each section.
Black hat 2010-bannedit-advanced-command-injection-exploitation-1-wprgster
This document discusses techniques for exploiting command injection vulnerabilities beyond just getting a shell. It proposes designing a reliable command injection payload stager for Windows using Metasploit. The stager would reuse the established connection to transfer a payload instead of relying on network tools like SSH or FTP, improving reliability. It explores using WScript to execute a VBScript payload instead of debug.exe since it's been removed from newer Windows versions. Encoding the payload is important to avoid filters or out of order execution on multithreaded servers.
This document discusses debugging fundamentals and provides an overview of different debuggers. It summarizes how debuggers like Immunity Debugger, WinDbg, and OllyDbg work to test and troubleshoot target programs. The document also introduces security fuzzers and describes how they work with debuggers to detect vulnerabilities by providing unexpected input data to programs and monitoring for exceptions or memory leaks. An example is provided of using the Immunity Debugger and Infigo FTPStress Fuzzer to analyze and attempt to crash an FTP server.
This document discusses attacking and exploiting antivirus software. It begins by describing how antivirus engines work and how their functionality can increase vulnerabilities. The document then details initial experiments fuzzing 14 antivirus engines, finding remote and local vulnerabilities. Specific vulnerabilities are listed for various antivirus products. Statistics on fuzzing various engines are provided. The document concludes by discussing remote exploitation of antivirus engines, noting that despite ASLR, many engines still have exploitable issues due to non-ASLR modules or RWX pages. The emulators used by antivirus engines are highlighted as a key part that can bypass some protections.
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...Zohar Babin
OSCON 2014 tutorial workshop lead by Jess Portnoy (@jess_port01) covering the use of various useful debugging tools, both general and specific to web apps.
It focuses on PHP based apps but vast parts of it are useful for other commonly used open sourced, interpreted languages.
Covering tools such as
1. GDB [for debugging the PHP engine and extensions, written in C/C++]
2. Xdebug [for debugging PHP code]
3. Shell utilities for better inspection of error and access logs such as ccze, efficient use of grep,sed.
4. Tracing processes with strace and more.
The session also featured several, real life examples such as:
1. A PHP extension causing seg faults
2. Reviewing Apache access and error logs to discover bad VHost configurations and rewrite rules
3. Various badly set PHP directives causing malfunctions
4. Debugging PHP code using Xdebug
Participants took part in the debugging process, and were asked to make suggestions as to how to advance and be prompted to share cases they’ve had, solved or did solve.
This document discusses techniques for improving the performance of fuzzing programs. It explains that most CPU cycles in fuzzing are wasted on program loading and initialization rather than actual fuzzing. The document recommends optimizing target selection to minimize code size, using smaller input files, and selecting mutators that are most likely to trigger new code paths. It also discusses using techniques like in-memory fuzzing and thin wrappers to improve efficiency. Overall it emphasizes the importance of quantitative and qualitative analysis to optimize fuzzer designs and strategies.
The document provides an overview of how to build a fully automated server deployment system using open source tools such as Request Tracker, Nictool/djbdns, dhcpd, PXEboot, Httpd, a yum repository, and Puppet. Key aspects include using an asset tracker (Request Tracker) to store server information and trigger automated builds. A PXE boot script generates configuration files using data from the asset tracker. A CGI script generates customized Kickstart files which install servers. Puppet then configures and deploys applications to servers based on their roles defined in the asset tracker. The goal is to achieve repeatable, consistent server builds from bare metal to a live application server within an hour with no
This document provides instructions for a laboratory activity that introduces students to assembly language programming. It discusses using tools like a text editor, assembler, linker, and debugger to write, assemble, link, and debug assembly language programs. The activity has students write two short programs - one that moves values into registers, and one that performs a multiplication in a loop. It guides them on running the programs in an debugger to observe the results and make modifications to test changes. The conclusion asks students to explain what the multiplication program does and note any observations from changing a constant value.
Debugging is an important part of the software development process that helps developers write more reliable code. There are several tools available for debugging .NET applications, including Visual Studio and Debugging Tools for Windows. Some basic debugging tasks involve setting breakpoints, stepping through code, examining variables and call stacks, and understanding memory usage and threads. Postmortem debugging techniques like dump file analysis can help debug problems that occur in production environments where live debugging is not possible.
The document discusses tools and techniques for rapidly deploying software in an environment. It covers two aspects: software packaging and software deployment. For packaging, it explains how to analyze installers and configure them for silent/unattended installation. For deployment, it discusses using tools like Group Policy to distribute packaged software and custom configurations across an environment.
This is the detailed guide of MakePython ESP32 dev kit, With the 12 experiments, the readers will be able to make simple electronic projects with MicroPython on ESP32, and the basic knowledge& setting up of IoT projects.
This document discusses strategies for fuzzing complex file formats that contain multiple data types, encodings, and embedded files. It recommends separating fuzzing into modular components that focus on individual data types, encodings, and objects. This allows fuzzing ASCII, binary, images, fonts and other embedded objects independently before combining them back into a single test case in a manner similar to the complex file format. Taking this modular approach helps address issues like protocol awareness, code coverage, and handling multiple encoding levels within a single complex format.
Fermín J. Serna - Exploits & Mitigations: EMET [RootedCON 2010]RootedCON
Fermín J. Serna from Microsoft presented on exploits and mitigations. He discussed the history of exploits like stack overflows, heap overflows, and return oriented programming. He then covered mitigations introduced over time like GS, DEP, ASLR, SafeSEH, and SEHOP. Serna presented on the Enhanced Mitigation Experience Toolkit (EMET), including its current features like enabling DEP and a SEHOP-like implementation, as well as potential future features like EAT hardware breakpoint mitigation, stack pivot mitigation, and mandatory ASLR. He concluded by welcoming questions from the audience.
This document provides an introduction and overview of batch file programming in Microsoft Windows. It discusses how batch files work, the different modes (interactive and batch), and how to create a basic "Hello World" batch file. It also covers internal and external commands, common run line commands, operators used in batch files like arithmetic, logical, and redirection operators. The document aims to provide novice to advanced programmers an understanding of batch file programming concepts.
This document summarizes a technical workshop on advanced systems management. The workshop covered administration essentials like task management and automation, scripting essentials including an introduction to scripting with tutorials on syntax and sample code, and toolkit essentials including an overview of useful tools contained on a provided utility DVD. The agenda included sessions on task management, automation vs manual tasks, scripting overview and commands, code writing guidelines, and recommended system tools.
The document discusses using emulation for security applications like reverse engineering Cisco IOS's heap management, tracing program execution to evaluate binaries, implementing dynamic taint analysis, and developing automated unpacking tools. It describes how emulation allows intercepting program execution at the instruction level and adding instrumentation to perform these dynamic analyses, avoiding detection by anti-debugging techniques. Specific tools mentioned include Dynamips, TTAnalyze, Argos, Pandora's Bochs, and the author's own unpacker and emulator.
Automated Image & Restore (AIR) is an open source forensic imaging tool with a graphical user interface. It provides an easy front-end for disk/partition imaging using dd and dcfldd commands. Key features include support for hashing algorithms, SCSI tape drives, network imaging, splitting images, and detailed session logging. The tutorial demonstrates installing and using AIR to create a forensic image of a file on a Linux system and copy it to a CD-ROM for evidence preservation.
This document discusses protections against executing arbitrary PHP code on hardened PHP environments after code execution is achieved. It introduces new techniques to overcome many protections by combining local PHP exploits that leak information and cause memory corruption. Specifically, it shows how important memory structures can be leaked and manipulated to deactivate protections within PHP, Suhosin, the C library, filesystems, compilers, and the operating system kernel.
This document contains notes from a presentation on Windows PowerShell 2.0 given by Tom Pester on December 17, 2009. It discusses what PowerShell is, why it was created, who has access to it, key concepts like cmdlets and providers, and new features in PowerShell 2.0 such as remoting and background jobs. Recommended books and online resources for learning more about PowerShell are also provided.
Infrastructure as Code in your CD pipelines - London Microsoft DevOps 0423Giulio Vian
London Microsoft DevOps 23 April 2018 Meetup (https://www.meetup.com/London-Microsoft-DevOps/events/249114256/)
Infrastructure as Code in your CD pipelines
from VMs to Containers
He is going to cover the Journey of agile transformation in a non-IT company, bringing in Continuous Delivery, traditional infrastructure and modern cloud DevOps practices.
In this talk, you will hear about the DevOps journey in his company (Glass, Lewis & Co.), from the initial brown-field all-manual state to the current partially automated situation and the strategic destination of a fully automated and monitored process.
In an equilibrium between a high-level view and useful practical tips, he will touch on what informed their decisions, in terms of priorities and technologies, some lessons learned in setting up Infrastructure-as-Code using Terraform for Azure, and how the legacy constraints helped or hindered them on this journey.
PVS-Studio analyzed the Boost library and found 7 potential bugs or issues. The issues included a misprint that caused division by zero, incorrect class member initialization, memory being released incorrectly with auto_ptr, a condition that would always be true due to unsigned socket type, another misprint where a variable wasn't assigned a value, potential for infinite loop when reading from a stream, and suspicious subtraction of identical values. Finding even a small number of issues in a heavily used and reviewed library like Boost demonstrates the tool's effectiveness at static analysis.
This document provides an overview of debugging and anti-debugging techniques on Windows. It discusses what debugging is, how programs run at the assembly level, and common anti-debugging tricks like API hooking and monitoring debug flags in process and thread data structures. The document also outlines techniques like inline hooking, SSDT hooking, and direct kernel object manipulation that can be used to bypass commercial anti-debugging tools and prevent a debugger from running normally.
This document discusses dynamic malware analysis and the challenges posed by self-modifying code. It examines existing general purpose dynamic binary instrumentation frameworks like Pin and DynamoRIO, finding that while they handle self-modifying code, they are not designed with a "malware mindset" and have exploitable gaps. The document demonstrates these gaps through examples, showing how transitions in virtual memory protections and program counter virtualization can be exploited. It concludes that a framework with a "malware mindset" is needed to properly handle malware analysis at scale.
Tip: How to enable wireless debugging with Android?Sarath C
This document discusses how to set up wireless debugging for an Android device to avoid using USB cables. The process involves enabling USB debugging on the device, noting the device's IP address, using ADB commands to start a TCP server on the device and connect the computer to the device's IP and port. Once connected, the computer can remotely debug the device over WiFi without a USB cable.
This document discusses methods for bypassing antivirus scanners by encoding binary files. It begins with an introduction to how antivirus software works and an overview of the PE file format. It then covers modifying antivirus signatures, using polymorphic techniques, and hijacking the entry point. The main part discusses encoding binary files by preparing the PE file, implementing a custom encoder that loops through bytes and encodes them, and reintroducing the original entry point. It concludes that the encoder needs to be changed to a decoder so the file can execute properly without crashing. The goal is to educate about these techniques while noting they should only be used for educational purposes.
How to make computer viruses. This is the giant book of how to's. It's old and well out of date. Rare to ever see this anywhere. But we are bringing it to you right here. Feel free to download this book.
We looked at the data. Here’s a breakdown of some key statistics about the nation’s incoming presidents’ addresses, how long they spoke, how well, and more.
This document provides instructions for a laboratory activity that introduces students to assembly language programming. It discusses using tools like a text editor, assembler, linker, and debugger to write, assemble, link, and debug assembly language programs. The activity has students write two short programs - one that moves values into registers, and one that performs a multiplication in a loop. It guides them on running the programs in an debugger to observe the results and make modifications to test changes. The conclusion asks students to explain what the multiplication program does and note any observations from changing a constant value.
Debugging is an important part of the software development process that helps developers write more reliable code. There are several tools available for debugging .NET applications, including Visual Studio and Debugging Tools for Windows. Some basic debugging tasks involve setting breakpoints, stepping through code, examining variables and call stacks, and understanding memory usage and threads. Postmortem debugging techniques like dump file analysis can help debug problems that occur in production environments where live debugging is not possible.
The document discusses tools and techniques for rapidly deploying software in an environment. It covers two aspects: software packaging and software deployment. For packaging, it explains how to analyze installers and configure them for silent/unattended installation. For deployment, it discusses using tools like Group Policy to distribute packaged software and custom configurations across an environment.
This is the detailed guide of MakePython ESP32 dev kit, With the 12 experiments, the readers will be able to make simple electronic projects with MicroPython on ESP32, and the basic knowledge& setting up of IoT projects.
This document discusses strategies for fuzzing complex file formats that contain multiple data types, encodings, and embedded files. It recommends separating fuzzing into modular components that focus on individual data types, encodings, and objects. This allows fuzzing ASCII, binary, images, fonts and other embedded objects independently before combining them back into a single test case in a manner similar to the complex file format. Taking this modular approach helps address issues like protocol awareness, code coverage, and handling multiple encoding levels within a single complex format.
Fermín J. Serna - Exploits & Mitigations: EMET [RootedCON 2010]RootedCON
Fermín J. Serna from Microsoft presented on exploits and mitigations. He discussed the history of exploits like stack overflows, heap overflows, and return oriented programming. He then covered mitigations introduced over time like GS, DEP, ASLR, SafeSEH, and SEHOP. Serna presented on the Enhanced Mitigation Experience Toolkit (EMET), including its current features like enabling DEP and a SEHOP-like implementation, as well as potential future features like EAT hardware breakpoint mitigation, stack pivot mitigation, and mandatory ASLR. He concluded by welcoming questions from the audience.
This document provides an introduction and overview of batch file programming in Microsoft Windows. It discusses how batch files work, the different modes (interactive and batch), and how to create a basic "Hello World" batch file. It also covers internal and external commands, common run line commands, operators used in batch files like arithmetic, logical, and redirection operators. The document aims to provide novice to advanced programmers an understanding of batch file programming concepts.
This document summarizes a technical workshop on advanced systems management. The workshop covered administration essentials like task management and automation, scripting essentials including an introduction to scripting with tutorials on syntax and sample code, and toolkit essentials including an overview of useful tools contained on a provided utility DVD. The agenda included sessions on task management, automation vs manual tasks, scripting overview and commands, code writing guidelines, and recommended system tools.
The document discusses using emulation for security applications like reverse engineering Cisco IOS's heap management, tracing program execution to evaluate binaries, implementing dynamic taint analysis, and developing automated unpacking tools. It describes how emulation allows intercepting program execution at the instruction level and adding instrumentation to perform these dynamic analyses, avoiding detection by anti-debugging techniques. Specific tools mentioned include Dynamips, TTAnalyze, Argos, Pandora's Bochs, and the author's own unpacker and emulator.
Automated Image & Restore (AIR) is an open source forensic imaging tool with a graphical user interface. It provides an easy front-end for disk/partition imaging using dd and dcfldd commands. Key features include support for hashing algorithms, SCSI tape drives, network imaging, splitting images, and detailed session logging. The tutorial demonstrates installing and using AIR to create a forensic image of a file on a Linux system and copy it to a CD-ROM for evidence preservation.
This document discusses protections against executing arbitrary PHP code on hardened PHP environments after code execution is achieved. It introduces new techniques to overcome many protections by combining local PHP exploits that leak information and cause memory corruption. Specifically, it shows how important memory structures can be leaked and manipulated to deactivate protections within PHP, Suhosin, the C library, filesystems, compilers, and the operating system kernel.
This document contains notes from a presentation on Windows PowerShell 2.0 given by Tom Pester on December 17, 2009. It discusses what PowerShell is, why it was created, who has access to it, key concepts like cmdlets and providers, and new features in PowerShell 2.0 such as remoting and background jobs. Recommended books and online resources for learning more about PowerShell are also provided.
Infrastructure as Code in your CD pipelines - London Microsoft DevOps 0423Giulio Vian
London Microsoft DevOps 23 April 2018 Meetup (https://www.meetup.com/London-Microsoft-DevOps/events/249114256/)
Infrastructure as Code in your CD pipelines
from VMs to Containers
He is going to cover the Journey of agile transformation in a non-IT company, bringing in Continuous Delivery, traditional infrastructure and modern cloud DevOps practices.
In this talk, you will hear about the DevOps journey in his company (Glass, Lewis & Co.), from the initial brown-field all-manual state to the current partially automated situation and the strategic destination of a fully automated and monitored process.
In an equilibrium between a high-level view and useful practical tips, he will touch on what informed their decisions, in terms of priorities and technologies, some lessons learned in setting up Infrastructure-as-Code using Terraform for Azure, and how the legacy constraints helped or hindered them on this journey.
PVS-Studio analyzed the Boost library and found 7 potential bugs or issues. The issues included a misprint that caused division by zero, incorrect class member initialization, memory being released incorrectly with auto_ptr, a condition that would always be true due to unsigned socket type, another misprint where a variable wasn't assigned a value, potential for infinite loop when reading from a stream, and suspicious subtraction of identical values. Finding even a small number of issues in a heavily used and reviewed library like Boost demonstrates the tool's effectiveness at static analysis.
This document provides an overview of debugging and anti-debugging techniques on Windows. It discusses what debugging is, how programs run at the assembly level, and common anti-debugging tricks like API hooking and monitoring debug flags in process and thread data structures. The document also outlines techniques like inline hooking, SSDT hooking, and direct kernel object manipulation that can be used to bypass commercial anti-debugging tools and prevent a debugger from running normally.
This document discusses dynamic malware analysis and the challenges posed by self-modifying code. It examines existing general purpose dynamic binary instrumentation frameworks like Pin and DynamoRIO, finding that while they handle self-modifying code, they are not designed with a "malware mindset" and have exploitable gaps. The document demonstrates these gaps through examples, showing how transitions in virtual memory protections and program counter virtualization can be exploited. It concludes that a framework with a "malware mindset" is needed to properly handle malware analysis at scale.
Tip: How to enable wireless debugging with Android?Sarath C
This document discusses how to set up wireless debugging for an Android device to avoid using USB cables. The process involves enabling USB debugging on the device, noting the device's IP address, using ADB commands to start a TCP server on the device and connect the computer to the device's IP and port. Once connected, the computer can remotely debug the device over WiFi without a USB cable.
This document discusses methods for bypassing antivirus scanners by encoding binary files. It begins with an introduction to how antivirus software works and an overview of the PE file format. It then covers modifying antivirus signatures, using polymorphic techniques, and hijacking the entry point. The main part discusses encoding binary files by preparing the PE file, implementing a custom encoder that loops through bytes and encodes them, and reintroducing the original entry point. It concludes that the encoder needs to be changed to a decoder so the file can execute properly without crashing. The goal is to educate about these techniques while noting they should only be used for educational purposes.
How to make computer viruses. This is the giant book of how to's. It's old and well out of date. Rare to ever see this anywhere. But we are bringing it to you right here. Feel free to download this book.
We looked at the data. Here’s a breakdown of some key statistics about the nation’s incoming presidents’ addresses, how long they spoke, how well, and more.
This document discusses how emojis, emoticons, and text speak can be used to teach students. It provides background on the origins of emoticons in 1982 as ways to convey tone and feelings in text communications. It then suggests that with text speak and emojis, students can translate, decode, summarize, play with language, and add emotion to language. A number of websites and apps that can be used for emoji-related activities, lessons, and discussions are also listed.
Artificial intelligence (AI) is everywhere, promising self-driving cars, medical breakthroughs, and new ways of working. But how do you separate hype from reality? How can your company apply AI to solve real business problems?
Here’s what AI learnings your business should keep in mind for 2017.
Study: The Future of VR, AR and Self-Driving CarsLinkedIn
We asked LinkedIn members worldwide about their levels of interest in the latest wave of technology: whether they’re using wearables, and whether they intend to buy self-driving cars and VR headsets as they become available. We asked them too about their attitudes to technology and to the growing role of Artificial Intelligence (AI) in the devices that they use. The answers were fascinating – and in many cases, surprising.
This SlideShare explores the full results of this study, including detailed market-by-market breakdowns of intention levels for each technology – and how attitudes change with age, location and seniority level. If you’re marketing a tech brand – or planning to use VR and wearables to reach a professional audience – then these are insights you won’t want to miss.
This document summarizes a presentation on evading antivirus detection. It discusses how antivirus has gotten better at detecting old techniques, and introduces newer tools and methods for generating payloads that can bypass antivirus software, including Veil, Hyperion, and writing your own custom stagers and payloads. It also recommends building your own antivirus lab to reliably test new payloads before deployment.
Software Reverse Engineering in a Security ContextLokendra Rawat
Software Reverse Engineering in a Security Context (ncrisc 2018) this research paper was proposed in university event and it's targeted audience was junior students and anyone who doesn't have a clue on reverse engineering , also useful for developers because this will help them to understand execution of their developed applications on low level and malicious person able to exploit their applications
Penetrating Windows 8 with syringe utilityIOSR Journals
This document discusses penetrating Windows 8 remotely using Metasploit framework and syringe utility. It begins with an introduction to penetration testing and Windows 8 security. It then describes using Metasploit to generate a payload, encoding it to evade detection, and injecting it into a Windows 8 system using syringe. This allows establishing a meterpreter session and compromising the system by migrating processes and accessing the C drive. It concludes that Windows 8 has strong security but syringe injections allow compromising it, and more exploits could be found to enhance efficacy.
Possibility of arbitrary code execution by Step-Oriented Programmingkozossakai
Step-Oriented Programming (SOP) allows executing arbitrary code on embedded systems by repeating step execution and changing the program counter value. A debugger communicates with a target system's stub using the Remote Serial Protocol to read/write memory and registers, enabling full control via simple commands if the connection is compromised. SOP constructs code by combining pieces of existing machine code and executes it without needing to directly inject new code. Therefore attacks are possible even if execution from data areas is prevented. The presentation will demonstrate this attack principle and results from actual experimentation.
Possibility of arbitrary code execution by Step-Oriented Programming by Hiroa...CODE BLUE
An embedded system has a stub to connect with a host PC and debug a program on the system remotely. A stub is an independent control program that controls a main program to enable debugging by a debugger. A stub is simplified by only processing the simple controls such as reading or writing of the register or of a memory, and a debugger processes a complicated analysis on the host PC.
Communication with a debugger on the host PC and a stub on the embedded system is performed by a protocol called Remote Serial Protocol (RSP) over a serial communication or TCP/IP communication. If this communication is taken away, it becomes possible to operate a stub arbitrarily. We considered what kind of attack possibility there was in that case, and identified that execution of arbitrary code constructed from pieces of machine code, combined with (SOP: Step-Oriented Programming) is possible by repeating step execution while changing the value of the program counter. Therefore it is possible to construct an arbitrary code and execute it from existing machine code, even if execution of the injected machine code is impossible because execution on data area is prevented by DEP or only machine code on the flash ROM are allowed execution.
I will explain about an attack principle by SOP and the results from constructed attack code and actual inspection.
CPU emulation has been used over the years for a multitude of objectives. It allows an application compiled for a specific target platform to be run on a host platform with a completely different or overlapping architecture set.
PVS-Studio Now Supports Any Build System under Windows and Any Compiler. Easy...Andrey Karpov
The next PVS-Studio version 5.15 will be able to analyze projects built by absolutely any build system: Makefile, Visual Studio Project, user-made build systems based on Python, Bash or whatever else... It will allow you to simply "watch" compiler calls and collect all the necessary information to run the analyzer in automatic mode. Moreover, it works with any (sensible) C/C++ compiler under Windows. Want to know more?
Introduction
Difference between System software and Application software
Difference between System and Application programming
Elements of programming environment
Assembler
Loader and Linker
Macro preprocessor
Compiler
Editor
Debugger
Device Drivers
Operating System
Makefile actually is an old concept from UNIX development. Makefile is based upon compiling rules for a project and improve the project development efficiency. In a big project, there are many files in different folders. Of course you can write a DOS batch file to build whole project. But makefile can judge which steps should be done first, which steps can be ignored, and even more complicated goals. All of these are decided by the rules in makefile, instead of manually specified.
The document discusses disassembly theory, including first, second, and third generation languages. It then discusses the why and how of disassembly, including uses for malware analysis, vulnerability analysis, software interoperability, compiler validation, and debugging displays. It describes the basic process of disassembly and two common algorithms: linear sweep and recursive descent. Finally, it outlines some common reversing and disassembly tools like file, PE Tools, PEiD, nm, ldd, objdump, otool, and strings.
This document provides release notes and supplementary information for Delphi 7. It notes that some components have been deprecated and recommends newer alternatives. It also describes changes made to string handling functions, warnings added by the compiler, and issues fixed in streaming of subcomponents. Finally, it provides notes on various other topics like Apache, UDDI, Windows XP input, and databases.
An Ideal Way to Integrate a Static Code Analyzer into a ProjectPVS-Studio
One of the most difficult things about using static analysis tools is managing false positives. There are a number of ways to eliminate them using the analyzer's settings or changing the code itself. I took a small project Apple II emulator for Windows as an example to show you how you can handle PVS-Studio's analysis report, and demonstrate by a number of examples how to fix errors and suppress false positives.
You can now use PVS-Studio with Visual Studio absent; just give it the prepro...Andrey Karpov
The new version of the static code analyzer PVS-Studio 5.10 comes with a small utility PVS-Studio Standalone which you may even miss at first. I'd say that's one small step for mankind but one big leap for PVS-Studio :) You can use the current version of this utility in two (for now) ways:
1. View analysis results (the .plog file) saved on another computer without running the Visual Studio IDE.
2. Analyze preprocessed files (generated by any preprocessor beforehand) without a preprocessor and project files or makefiles.
This document introduces debugging ASP.NET applications with WinDBG and dump analysis. It discusses collecting dump files from ASP.NET processes using tools like ADPlus and Debug Diagnostic Tool. It then explains analyzing these dumps in WinDBG using commands and extensions like SOS and PSSCOR2 to diagnose issues like crashes, slow performance, hangs and memory leaks. The document provides an overview of common debugging scenarios, techniques and commands to get started with debugging ASP.NET applications offline using memory dumps.
The document discusses an interpreter and its components. An interpreter translates source code written in one computer language into another target language, often machine code. It performs operations like lexical analysis, parsing, semantic analysis, and code generation. The front end analyzes the source code to build an internal representation and symbol table, while the back end translates the intermediate code into the target language. The document then provides details about the purpose, scope, definition and objectives of a C interpreter project, which will analyze and execute source code line by line to translate it into object code for different computer types. It lists the software and tools used, including the NetBeans IDE.
This document provides an introduction and overview of programming microcontrollers using MikroBasic. It discusses why BASIC is a good choice, how to choose the right microcontroller, the basics of writing and compiling code in MikroBasic, and how to load the compiled program onto the microcontroller. The document is an excerpt from a book on MikroBasic that provides tutorials and examples for programming microcontrollers.
This document provides an introduction and overview of the MikroBasic programming language for microcontrollers. It covers the basics of BASIC programming including identifiers, operators, expressions, instructions, data types, constants, variables, directives, comments, labels, procedures and functions. The document uses examples and explanations to illustrate how to write clear and understandable MikroBasic code.
This document provides an introduction and overview of programming microcontrollers using MikroBasic. It discusses why BASIC is a good choice, how to choose the right microcontroller, the basics of writing and compiling code in MikroBasic, and how to load the compiled program onto the microcontroller. The document is an excerpt from a book on MikroBasic that provides tutorials and examples for programming microcontrollers.
This document provides an introduction and overview of programming microcontrollers using MikroBasic. It discusses why BASIC is a good choice, how to choose the right microcontroller, the basics of writing and compiling code in MikroBasic, and how to load the compiled program onto the microcontroller. The document is an excerpt from a book on MikroBasic that provides tutorials and examples for programming microcontrollers.
This document provides an introduction and overview of programming microcontrollers using MikroBasic. It discusses why BASIC is a good choice, how to choose the right microcontroller, the basics of writing and compiling code in MikroBasic, and how to load the compiled program onto the microcontroller. The document is an excerpt from a book on MikroBasic and provides foundational information for getting started with microcontroller programming using this BASIC variant.
1. Abstract
Anti-Virus manufacturers nowadays implements more and
more complex functions and algorithms in order to detect
the latest and newest viruses along with their variants.
There is however simple methods that can be used to by-
pass most of these, especially those that doesn’t use
heuristics and similar techniques at all.
Bypassing Anti-
Virus Scanners
2. Page 1
Contents
Chapter 1 – Introduction ..............................................................................................................2
Chapter 2 – PE File Structure ......................................................................................................3
2.1 - AV Signatures and the PE file format..................................................................................4
2.2 – Modifying AV Signatures in PE Files.................................................................................5
2.3 – Polymorphic Techniques and Hijacks.................................................................................7
Chapter 3 – Encoding Binary Files ..............................................................................................8
3.1 – Preparing the PE file for Encoding .....................................................................................9
3.2 – Implementing the Custom Encoder...................................................................................13
Chapter 4 – Decoding Binary Files.............................................................................................16
4.1 – Altering the Encoder to a Decoder....................................................................................16
4.2 – Testing the Custom Decoder.............................................................................................18
Chapter 5 – Conclusion ...............................................................................................................21
3. Page 2
Chapter 1
Introduction
Anti-Virus manufacturers has evolved a lot during the last decade, starting with simple signature-
based scanners and thereafter slowly implementing more and more advanced heuristics. Most of
these are able to scan files stored on the harddisk, but also opcodes in the memory.
Opcodes are in short, Assembly commands which are the lowest level of instructions given to the
CPU by any application running. A program is usually developed in a higher level language such
as C or C++, where opcodes are usually not directly involved. The compiler on the other hand,
translates the high-level code into these opcodes based on the Architecture used and so forth.
When a traditional Anti-Virus application scans a file, it does so by reading the offsets and its
assigned values. Where the offset is a memory address and the value is an opcode which the
scanner can read with a simple binary hex-viewer. Therefore, it is able to look for a signature.
If an application passes the file-scan check on the harddisk without any heuristic “sandboxes”
applied, then the file is either safe to run or the Anti-Virus application just got bypassed!
This paper will show some of the methods and techniques, one can use in order to do this.
This is for educational purposes only.
4. Page 3
Chapter 2
PE File Structure
A typical PE aka Portable Executable which is the default file format for Windows binaries looks
like the picture below. It should be mentioned that not all binaries has all these 5 sections. Some-
times it’s only 4 or perhaps 6-7 sections, depending on how the binary is built / made.
The signature which triggers the Anti-Virus application can be located anywhere, though usually
it is within one of the actual sections and not section table headers, DOS header, DOS stub etc.
Figure 2.1 – PE File Visualization
5. Page 4
2.1 – AV Signatures and the PE file format
Finding the signature that the Anti-Virus application looks for, isn’t that hard if an old technique
is used which is performed by splitting the file into several files and then scanning each file to
see which one of them contains the signature.
Sometimes the signature is pretty easy to find, e.g. in case ncx99.exe is used. This is a simple
netcat listener, which binds cmd.exe to port 99 on the global network interface. In the picture
below from offset E77E to offset E78F is the main signature located.
Figure 2.1.1 – Hexadecimal View of a Binary File
Furthermore, the signature is located in the idata section in this case. This means that if we
would try to encode the entire idata section, then our executable file might not work at all!
Therefore we could try to edit a part of this, or encode only the signature to avoid AV detection.
6. Page 5
It is however also important to note, that Anti-Virus applications will read the PE headers too
and use these to determine whether the executable file we want to run, is malicious or not.
Sometimes, even the time and date stamp within the file is a part of the signature which is a good
idea to change or simply replace with null. If some of the section tables, headers or flags seem to
be invalid by the AV-scanner, then it might flag it as malicious or potentially malicious since it
assumes, that it must be due to it can’t read the executable file properly.
Figure 2.1.2 – Partial View of the PE Header in Ollydbg
2.2 – Modifying AV Signatures in PE Files
After a signature is perhaps found within one of the sections, then it is usually possible to change
either by editing it directly with a hex-editor or by changing the opcodes with a disassembler or
maybe, with something as simple as a debugger. (It is possible to do with Ollydbg.)
7. Page 6
In case ncx99.exe is used as previously mentioned, then it is possible to change both the listening
port and the program it will execute. Of course if we change it to e.g. calc.exe then it won’t do
much good for any hacker at all, but changing the listening port from 99 to e.g. 81 do make a
difference. It isn’t many AV’s that gets fooled by this, but it is a few.
Figure 2.2.1 – ncx99.exe – Original (Binds cmd.exe to port 99)
Figure 2.2.2 – ncx99.exe – Modified (Binds cmd.exe to port 81)
As you can see, Avast and Ikarus were bypassed. If we were to attack a computer which used
one of these, then we would’ve succeeded now just by changing the listening port.
8. Page 7
2.3 – Polymorphic Techniques and Hijacks
Polymorphic Techniques
Some polymorphic viruses, has the same functionality but different opcodes. This is yet another
technique used by more skilled hackers. An example of this could be that instead of PUSH -1,
the hacker could use DEC ESI, PUSH ESI, INC ESI if the ESI register is 0 to start with. If it isn’t
then we might have to save the value of ESI, by pushing it onto the stack, XOR’ing it so it
becomes null (XOR ESI, ESI) and then use it to push the value -1 to the stack.
Afterwards we would of course have to restore the original value of ESI, by POP’ing the stack.
That is however just an example, since most AV scanners shouldn’t detect PUSH -1 alone as
anything malicious. But in case we encounter a signature, which is executable code and we can’t
change it to NOP’s, then we would have to use encoding methods or “polymorphic methods”.
Hijacks
In case we want to encode it, we have to hijack the entry point of the binary file either by editing
the PE headers or perhaps by overwriting the first instruction to a jump, which then points to a
“code cave” which is an unused section of data, where a hacker can enter his own code without
altering the size of the target file.
It should be noted though, that some AV’s actually checks the file-size too.
The hacker can of course, overwrite instructions further inside the binary too if he or she desires
to do so. As long as the original program still contains the same functionality, in order to execute
without crashing or causing similar errors, then it doesn’t matter where any edits are made.
9. Page 8
Chapter 3
Encoding Binary Files
Hijacking the Entry Point is often used, but it does not really bypass Anti-Virus applications.
Instead it makes a hacker able to re-route the execution flow to whatever he or she desires. In
this case it could be a “black hole” to trick heuristic detection systems, or perhaps an encoder
which bypasses the signature-based Anti-Virus scanner in use!
Below are two figures of how a normal PE file and an encoded PE file could look like.
Before Alteration
Ncx99.exe
Entry Point
Signature
After Alteration
Ncx99.exe
Altered Entry Point
Signature
Encoded .text
(data section)
Assembly Encoder
10. Page 9
3.1 – Preparing the PE file for Encoding
First we open our chosen PE file in our favorite disassembler and debugger. In this case we will
use Ollydbg to alter the previously mentioned ncx99.exe backdoor. Keep in mind that you don’t
have to be an Assembly programmer in order to do nor understand this.
Figure 3.1.1 – Initial Overview of ncx99.exe
First we select the first couple of instructions (opcodes) and copy them to notepad or whatever
program we prefer for taking notes. The reason why we’re doing this is because we need to re-
introduce some of the first overwritten opcodes later on, before we re-route the execution flow
back to its original place.
11. Page 10
We now have the following opcodes saved which we will need later on:
Address Hex dump Command
00404C00 /. 55 PUSH EBP
00404C01 |. 8BEC MOV EBP,ESP
00404C03 |. 6A FF PUSH -1
00404C05 |. 68 00B04000 PUSH OFFSET 0040B000
00404C0A |. 68 78764000 PUSH 00407678
00404C0F |. 64:A1 0000000 MOV EAX,DWORD PTR FS:[0]
00404C15 |. 50 PUSH EAX
Figure 3.1.2 – First couple of opcodes inside ncx99.exe
Then we browse through the binary, for a convenient place to implement our custom encoder.
After searching for a while inside the .text data section, we may find the following place.
Figure 3.1.3 – A convenient place for a “code cave” in ncx99.exe
12. Page 11
After we’ve noted down the new Entry Point address at 0040A770, we browse to the memory
overview by clicking the “M” icon. Then we double-click on the PE Header section and open it.
Simply, because we need to prepare the .text data section by making it writeable and of course,
change the old Entry Point to our new one, which points to our “code cave”. Adding a few bytes
extra to the last section doesn’t hurt either, as this may bypass some AV-scanners.
Figure 3.1.4 – PE Header Overview of ncx99.exe
This is the value we need to edit in order to be able to make the .text section writeable. We could
use LordPE for this, but knowing the common values by mind, makes us able to do this without.
We will therefore change 60000020 to E0000020 as shown in the next picture, making the .text
section writeable, allowing us to encode this while the PE file is executing. If we didn’t do this
we would get a “permission error” and most likely crash.
13. Page 12
Adding a few bytes to one of the sections is a good idea too, if you don’t need to be very strict on
keeping exactly the same file-size. This is done by taking the hexadecimal value of e.g. the .idata
section and then add the number of bytes wanted in hex.
If you’re going to do this, then make sure you’re calculating in hex and not decimal.
Figure 3.1.5 – Altered PE Header in ncx99.exe
After we’ve made our modifications, we select the entire section which contains our changes,
right click and browse to “Edit”, and then “Copy to Executable”. Then right click on the new
window and choose “Save File”.
Keep in mind that this is a bit different in the older version of Ollydbg.
14. Page 13
Because we’ve added a few bytes to the .idata section, the program won’t execute. Therefore we
need to add the amount of bytes we “added”, by using a hex-editor to add the actual amount of
bytes that was added to the .idata section.
Figure 3.1.6 – Altered ncx99.exe unable to execute
In this case XVI32 (a hex-editor) is sufficient to use. Simply browse to the end of the PE file,
open the “Edit” menu and choose “Insert string”. Then make sure you either add 00, 90 or CC.
Preferably just add 00 as this will do nothing at all. Under “Insert <n> times” you choose hexa-
decimal and choose the amount of bytes you added to the .idata section. When you’re done click
the “save” icon and your executable PE file, should be working again.
3.2 – Implementing the Custom Encoder
With all the preparations made, we’re ready to implement the encoder. First we open our
modified PE file in Ollydbg and see that we’ve landed at 0040A770. After taking a closer look
on where the base (beginning) address is and where our code cave begins, we note down that
from offset 00401000 to 0040A76F, is what we’ll encode.
There are many ways to implement an encoder, but the easiest way is the one Mati Aharoni from
Offensive Security did in his public video presentation about AV’s. The encoder we’re going to
implement is slightly different in order to hopefully confuse a few more Anti-Virus scanners.
We’ll basically encode almost the entire .text section, with an encoder which loops through each
byte of the selected code that we want to encode. The encoding mechanism itself will just change
the byte to whatever we tell it to become.
15. Page 14
Address Hex dump Command
0040A770 . B8 00104000 MOV EAX,00401000
0040A775 8000 13 ADD BYTE PTR DS:[EAX],13
0040A778 . 8030 0F XOR BYTE PTR DS:[EAX],0F
0040A77B 8000 37 ADD BYTE PTR DS:[EAX],37
0040A77E . 40 INC EAX
0040A77F . 3D 6FA74000 CMP EAX,0040A76F
0040A784 .^ 7E EF JLE SHORT 0040A775
Figure 3.2.1 – Custom Assembly Encoder
Explanation of the Custom Encoder
1) First the base (beginning) address is moved into the EAX register.
2) Then it adds 13 to the byte which EAX is pointing to.
3) XOR (Exclusive OR) the byte with 0F which EAX is pointing to.
4) Add 37 to the byte which EAX is pointing to.
5) Increase EAX to point to the next byte.
6) Compare EAX with our ending address.
7) If our ending address hasn’t been reached, jump to (2).
Figure 3.2.2 – Custom Encoder inside Ollydbg
16. Page 15
With our custom encoder implemented we’re almost done. It should be noted, that we could also
use other opcodes too, to encode our .text section. Such opcodes could be: sub, or, and, etc.
But for now we’re going to re-introduce some of the first few opcodes that was originally run by
the executable in the start. Now we could be simple and just place a jump to 00404C00, but we’ll
add the first couple of instructions ourselves as shown in the picture below.
Figure 3.2.3 – Re-Introduced Opcodes in ncx99.exe
With that done you may wonder what the JMP 00404C05 opcode is. That is a jump to the offset
aka memory address where the next instruction after the original PUSH -1 is located.
It should be noted that if we were to execute the file now, it would simply fail because the PE
file as it is right now, will encode the .text section and try to execute it. Since it becomes
encoded, then it will most likely fail and crash. But save the changes anyway and re-open it.
This is because we first need to use our encoder, to encode the file and afterwards change it to a
decoder, so the execution flow will seem completely normal even without a debugger.
17. Page 16
Chapter 4
Decoding Binary Files
After we’ve successfully implemented our encoder we need to save the encoded contents and
then change our encoder to a decoder as previously mentioned. This is relatively simple as you
will experience yourself.
When we hit the first instruction which moves 00401000 into the EAX register, we can right-
click this and select “Follow in Dump”. By pressing “F7” on your keyboard we can single-step
through the custom encoder, and watch our .text section become encoded.
To speed up this process, select the instruction right after the JLE SHORT 0040A775 opcode,
place a breakpoint by pressing “F2” on your keyboard and then press “F9” to execute until the
breakpoint stops the execution flow.
Some of the code and even your encoder may seem completely different now. This is because
the encoder altered all the opcodes in the .text data section, except your encoder even though it
may seem so. Copy the changes to an “executable” and save it as a new file.
4.1 – Altering the Encoder to a Decoder
Now open the newly created file and look at the custom encoder we implemented earlier.
As you can see almost all of the opcodes are “gibberish” and therefore we might have to press
CTRL+A to do a quick analysis in order to get our custom encoder visible. When it appears to
look like it should, we change two of the opcodes in order to make it a decoder.
Our initial encoder added 13 to the byte which EAX pointed to, then it XOR’d it with 0F and
added 37 to end with. Now we need to reverse this, by deducting -37 to start with and then -13.
18. Page 17
Figure 4.1.1 – Changing the Encoder to a Decoder
We will still use the add opcode and of course xor, but we’ll only need to change the values as
mentioned previously, which you can also see in the picture above in figure 4.1.1.
When we’ve done that we copy our changes to an executable, and save it as a new file.
In theory the PE file should work now just as it did to start with, but it is also encoded too
making it able to bypass some AV-scanners, which makes it more interesting.
19. Page 18
4.2 – Testing the Custom Decoder
Now it’s time to test if our encoded file will decode properly and execute gracefully.
Figure 4.2.1 – Encoded Overview of ncx99.exe
In the picture above, only the first hex character has been decoded back to its original “state”.
(Please note that a character in this case, is a byte which is the same as 8 bits made of binary.)
By placing a breakpoint right after JLE SHORT 0040A775, and then running the PE file until it
stops executing, we’ll see that the entire .text section has changed back to its original state.
If we execute the first couple of re-introduced opcodes including the long jump back to where
the real start of the program is, we’ll see that it may still look obfuscated or encoded.
20. Page 19
Figure 4.2.2 – The Beginning of the Decoded PE File
This does not really matter, as we can hit CTRL+A and do a quick analysis of the code. When
we’ve done that we may see that our executable PE file is back to its original state again and if
we press “F9” we may see that our program is executing without any errors.
If that is the case then we’ve encoded the binary file and even decoded it successfully.
Even scanning the file now with a lot of different AV-scanners will reveal different results, if the
file is just scanned and not executed since we haven’t implemented any bypassing techniques for
heuristic (malicious) opcode detection.
21. Page 20
Figure 4.2.3 – Netstat Overview of ncx99.exe running
If we scan the file with AVG it may be undetectable now, or as script kiddies tends to say: FUD.
This expression means “Fully Undetectable” and is widely used with tools such as cryptors.
Most of these use another way of making the PE files able to bypass the AV-scanners, which is
e.g. by encrypting the entire file with RC4 and then pack a stub decoder into the file.
This will of course alter the size of the file in many cases. In the picture below you’ll see that
many of the AV’s either didn’t know what was scanned or they didn’t flag it as malicious at all.
Figure 4.2.4 – AV-Scan of highly modified ncx99.exe
22. Page 21
Chapter 5
Conclusion
The purpose of this paper was to demonstrate how easy it is to bypass signature-based Anti-
Virus scanners which do not use heuristics at all or perhaps only in an insufficient way which
makes a hacker able to outsmart the AV-system in use.
Figure 5.1 – ncx99.exe before any modifications
As you can see almost all of the AV-scanners detects the original ncx99.exe by default.
23. Page 22
If we alter this file heavily then the results are quite amazing. The amount of code added and
changed can be as little as below 30 bytes which is the equivalent of 30 characters you can type
on your keyboard. Even the size of the file may have been unaltered too, though the contents of
the file may have been encoded with a custom encoder.
Figure 5.2 – ncx99.exe after heavy modifications
As you can see for yourself in the picture above, a lot of the AV-scanners were bypassed.
Kaspersky detected this file as potentially malicious with its heuristics system, hence the reason
Type_Win32 is stated which means it is probably a new variant of a virus, trojan, etc.
In any case it is always a good idea to encode the primary signature of the file, though usually
there is more than one signature so it isn’t piece of cake for any hacker to bypass AV-detection.