Login
file-unpumper is a powerful command-line utility designed to clean and analyze Portable Executable (PE) files. It provides a range of features to help developers and security professionals work with PE files more effectively.
PE Header Fixing: file-unpumper can fix and align the PE headers of a given executable file. This is particularly useful for resolving issues caused by packers or obfuscators that modify the headers.
Resource Extraction: The tool can extract embedded resources from a PE file, such as icons, bitmaps, or other data resources. This can be helpful for reverse engineering or analyzing the contents of an executable.
Metadata Analysis: file-unpumper provides a comprehensive analysis of the PE file's metadata, including information about the machine architecture, number of sections, timestamp, subsystem, image base, and section details.
File Cleaning: The core functionality of file-unpumper is to remove any "pumped" or padded data from a PE file, resulting in a cleaned version of the executable. This can aid in malware analysis, reverse engineering, or simply reducing the file size.
Parallel Processing: To ensure efficient performance, file-unpumper leverages the power of parallel processing using the rayon crate, allowing it to handle large files with ease.
Progress Tracking: During the file cleaning process, a progress bar is displayed, providing a visual indication of the operation's progress and estimated time remaining.
file-unpumper is written in Rust and can be easily installed using the Cargo package manager:
FreshRSS cargo install file-unpumper
<INPUT>: The path to the input PE file.--fix-headers: Fix and align the PE headers of the input file.--extract-resources: Extract embedded resources from the input file.--analyze-metadata: Analyze and display the PE file's metadata.-h, --help: Print help information.-V, --version: Print version information.bash file-unpumper path/to/input.exe
bash file-unpumper --fix-headers --analyze-metadata path/to/input.exe
bash file-unpumper --extract-resources path/to/input.exe
bash file-unpumper --fix-headers --extract-resources --analyze-metadata path/to/input.exe
Contributions to file-unpumper are welcome! If you encounter any issues or have suggestions for improvements, please open an issue or submit a pull request on the GitHub repository.
The latest changelogs can be found in CHANGELOG.md
file-unpumper is released under the MIT License.
Caracal is a static analyzer tool over the SIERRA representation for Starknet smart contracts.
Precompiled binaries are available on our releases page. If you are using Cairo compiler 1.x.x uses the binary v0.1.x otherwise if you are using the Cairo compiler 2.x.x uses v0.2.x.
You need the Rust compiler and Cargo. Building from git:
cargo install --git https://github.com/crytic/caracal --profile release --forceBuilding from a local copy:
git clone https://github.com/crytic/caracal
cd caracal
cargo install --path . --profile release --forceList detectors:
caracal detectorsList printers:
caracal printersTo use with a standalone cairo file you need to pass the path to the corelib library either with the --corelib cli option or by setting the CORELIB_PATH environment variable. Run detectors:
caracal detect path/file/to/analyze --corelib path/to/corelib/srcRun printers:
caracal print path/file/to/analyze --printer printer_to_use --corelib path/to/corelib/srcIf you have a project that uses Scarb you need to add the following in Scarb.toml:
[[target.starknet-contract]]
sierra = true
[cairo]
sierra-replace-ids = trueThen pass the path to the directory where Scarb.toml resides. Run detectors:
caracal detect path/to/dirRun printers:
caracal print path/to/dir --printer printer_to_use| Num | Detector | What it Detects | Impact | Confidence | Cairo |
|---|---|---|---|---|---|
| 1 | controlled-library-call | Library calls with a user controlled class hash | High | Medium | 1 & 2 |
| 2 | unchecked-l1-handler-from | Detect L1 handlers without from address check | High | Medium | 1 & 2 |
| 3 | felt252-overflow | Detect user controlled operations with felt252 type, which is not overflow safe | High | Medium | 1 & 2 |
| 4 | reentrancy | Detect when a storage variable is read before an external call and written after | Medium | Medium | 1 & 2 |
| 5 | read-only-reentrancy | Detect when a view function read a storage variable written after an external call | Medium | Medium | 1 & 2 |
| 6 | unused-events | Events defined but not emitted | Medium | Medium | 1 & 2 |
| 7 | unused-return | Unused return values | Medium | Medium | 1 & 2 |
| 8 | unenforced-view | Function has view decorator but modifies state | Medium | Medium | 1 |
| 9 | unused-arguments | Unused arguments | Low | Medium | 1 & 2 |
| 10 | reentrancy-benign | Detect when a storage variable is written after an external call but not read before | Low | Medium | 1 & 2 |
| 11 | reentrancy-events | Detect when an event is emitted after an external call leading to out-of-order events | Low | Medium | 1 & 2 |
| 12 | dead-code | Private functions never used | Low | Medium | 1 & 2 |
The Cairo column represent the compiler version(s) for which the detector is valid.
cfg: Export the CFG of each function to a .dot filecallgraph: Export function call graph to a .dot fileCheck the wiki on the following topics:
Supports almost all operating systems
Supports almost all desktop applications developed based on Electron
๏จ All malicious operations are executed by the injected program, those commonly used trusted programs
Bypass of Network Access Control Policy for Applications by Zero Trust Sandbox
Verified that it will not be discovered by the antivirus software below
(Please note that a simple command call has been implemented here, and some behavior based heuristic checks will still prompt , bypass AV is not a key issue to be addressed in this project)
An increasing number of desktop applications are opting for the Electron framework.
Electron provides a method that can be debugged, usually by utilizing Chrome's inspect function or calling inspect through Node.js. In this project, the implementation of inspect was analyzed, and a method for automatically parasitizing common Electron programs was developed.
By establishing a connection with the Command and Control (C2) server, a simple remote control is achieved.
Due to the widespread trust of most antivirus software in these well-known applications (with digital signatures), executing malicious commands in the program context provides excellent concealment and stability.
For these injected applications, it is necessary to carefully consider the potential legal risks brought by such actions. When users analyze program behavior, they may be surprised to find that the parent process executing malicious behavior comes from the application they trust.
nc -lvnp 8899
clone this project
modify build.config
injected_app: The electron program you want to inject
c2: set c2_Public IP and c2_netcat Port
exec node build.js, and then pkg to an execute program
Send to victim, and get electron_shellย
VTScanner is a versatile Python tool that empowers users to perform comprehensive file scans within a selected directory for malware detection and analysis. It seamlessly integrates with the VirusTotal API to deliver extensive insights into the safety of your files. VTScanner is compatible with Windows, macOS, and Linux, making it a valuable asset for security-conscious individuals and professionals alike.
VTScanner enables users to choose a specific directory for scanning. By doing so, you can assess all the files within that directory for potential malware threats.
Upon completing a scan, VTScanner generates detailed reports summarizing the results. These reports provide essential information about the scanned files, including their hash, file type, and detection status.
VTScanner leverages file hashes for efficient malware detection. By comparing the hash of each file to known malware signatures, it can quickly identify potential threats.
VTScanner interacts seamlessly with the VirusTotal API. If a file has not been scanned on VirusTotal previously, VTScanner automatically submits its hash for analysis. It then waits for the response, allowing you to access comprehensive VirusTotal reports.
For users with free VirusTotal accounts, VTScanner offers a time delay feature. This function introduces a specified delay (recommended between 20-25 seconds) between each scan request, ensuring compliance with VirusTotal's rate limits.
If you have a premium VirusTotal API account, VTScanner provides the option for concurrent scanning. This feature allows you to optimize scanning speed, making it an ideal choice for more extensive file collections.
VTScanner goes the extra mile by enabling users to explore VirusTotal's detailed reports for any file with a simple double-click. This feature offers valuable insights into file detections and behavior.
For added convenience, VTScanner comes with preinstalled Windows binaries compiled using PyInstaller. These binaries are detected by 10 antivirus scanners.
If you prefer to generate your own binaries or use VTScanner on non-Windows platforms, you can easily create custom binaries with PyInstaller.
Before installing VTScanner, make sure you have the following prerequisites in place:
pip install -r requirements.txtYou can acquire VTScanner by cloning the GitHub repository to your local machine:
git clone https://github.com/samhaxr/VTScanner.git
To initiate VTScanner, follow these steps:
cd VTScanner
python3 VTScanner.py
VTScanner is released under the GPL License. Refer to the LICENSE file for full licensing details.
VTScanner is a tool designed to enhance security by identifying potential malware threats. However, it's crucial to remember that no tool provides foolproof protection. Always exercise caution and employ additional security measures when handling files that may contain malicious content. For inquiries, issues, or feedback, please don't hesitate to open an issue on our GitHub repository. Thank you for choosing VTScanner v1.0.
A fiber is a unit of execution that must be manually scheduled by the application rather than rely on the priority-based scheduling mechanism built into Windows. Fibers are often called lightweight threads. For more detailed information about what are and how fibers work consult the official documentation. Fibers allow to have multiple execution flows in a single thread, each one with its own registers' state and stack. On the other hand, fibers are invisible to the kernel, which makes them a stealthier (and cheaper) method to execute in-memory code than spawning new threads.
One thread can create multiple fibers, and switch between them at desire by calling the SwitchToFiber function. Before that, the current thread itself must have become a fiber by calling ConvertThreadToFiber since only a fiber can create other fibers. Finally, in order to create a fiber that, when scheduled, executes an in-memory code (for example, after reflectively loaded a PE or some shellcode) it is just needed to make a call to CreateFiber.
The SwitchToFiber function is the most important part of this process and where all the magic occurs. This function allows to schedule one fiber or another, all happening on user space. According to the official documentation, "the SwitchToFiber function saves the state information of the current fiber and restores the state of the specified fiber". This mean that when this function is called, the registers' values and the stack are switched from the current fiber state to the target fiber state, allowing to "hide" the stack of the current fiber once the process is completed. This also allows to continue the execution of the target fiber from the same point where the execution was stopped (the same way that it happens when the scheduler switches between threads according to its own priority logic).
And this is exactly what this simple PoC does:
run() function exported by the manually mapped dll. This fiber will be known as the payload fiber from now on.This process repeats indefinitely.
The use of fibers may be advantageous for some types of payloads (like a C2 beacon) for some of these reasons:
JMP or CALL from the loader pointing to unbacked memory regions.Since we are using LITCRYPT plugin to obfuscate string literals, it is required to set up the environment variable LITCRYPT_ENCRYPT_KEY before compiling the code:
C:\Users\User\Desktop\Fiber> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"
After that, simply compile both the payload and the loader and run the last one:
C:\Users\User\Desktop\Fiber\payload> cargo build --release
C:\Users\User\Desktop\Fiber\loader> cargo build --release
C:\Users\User\Desktop\Fiber\loader\target\release> loader.exe
There is not much mistery on this PoC execution. All it has to be done is to run the loader and use any tool like ProcessHacker to inspect the thread stack. Since the payload switches back to the control fiber before sleeping, the payload fiber's stack remains hidden most of the time. You will see in the output how the two fibers are consecutively scheduled following the already commented logic.
The code is commented to show how to use, create and schedule fibers. You will notice that both the loader and the payload offered as example are "stuck" on an infinite loop, which allows to indefinitely switch between fibers and continue the execution.
If a different payload wants to be tested, just modify the path located on line 32 of the file src::main.rs of the loader. In that case, the new dll has to export a run(PVOID) function that will receive as input parameter the address of the control fiber. This function has to switch back to the control fiber in order to call the Sleep function, although you can modify this behavior at will to fit your requirements.
Another way to test this tool with a random payload is to perform IAT hooking to redirect any call to the Sleep function (or any other imported function) made by the payload to a function located on the loader, allowing to switch back to the control fiber when this call occurs. Up to you.
In the following screenshots we can see how the stack of the current threat moves from one private memory region to another as we switch fibers:
This tool is a simple PoC of how to hide memory artifacts using a ROP chain in combination with hardware breakpoints. The ROP chain will change the main module memory page's protections to N/A while sleeping (i.e. when the function Sleep is called). For more detailed information about this memory scanning evasion technique check out the original project Gargoyle. x64 only.
The idea is to set up a hardware breakpoint in kernel32!Sleep and a new top-level filter to handle the exception. When Sleep is called, the exception filter function set before is triggered, allowing us to call the ROP chain without the need of using classic function hooks. This way, we avoid leaving weird and unusual private memory regions in the process related to well known dlls.
The ROP chain simply calls VirtualProtect() to set the current memory page to N/A, then calls SleepEx and finally restores the RX memory protection.
The overview of the process is as follows:
This process repeats indefinitely.
As it can be seen in the image, the main module's memory protection is changed to N/A while sleeping, which avoids memory scans looking for pages with execution permission.
Since we are using LITCRYPT plugin to obfuscate string literals, it is required to set up the environment variable LITCRYPT_ENCRYPT_KEY before compiling the code:
C:\Users\User\Desktop\RustChain> set LITCRYPT_ENCRYPT_KEY="yoursupersecretkey"
After that, simply compile the code and run the tool:
C:\Users\User\Desktop\RustChain> cargo build
C:\Users\User\Desktop\RustChain\target\debug> rustchain.exe
This tool is just a PoC and some extra features should be implemented in order to be fully functional. The main purpose of the project was to learn how to implement a ROP chain and integrate it within Rust. Because of that, this tool will only work if you use it as it is, and failures are expected if you try to use it in other ways (for example, compiling it to a dll and trying to reflectively load and execute it).
