Skip to main content

​
Welcome Contributors

Contributions of all kinds are welcome to make xAnalyzer better for everyone. Whether you’re reporting bugs, improving documentation, adding API definitions, or contributing code, your help is appreciated.
You don’t need to be a developer to contribute! Bug reports, documentation improvements, and API definition additions are all valuable contributions.

​
Ways to Contribute

Report Bugs

Help identify and document issues

Improve Documentation

Enhance guides, fix typos, add examples

Add API Definitions

Expand the API definition database

Submit Code

Fix bugs or implement new features

​
Reporting Bugs

High-quality bug reports help us fix issues faster.

​
Before Reporting

1

Update software

Make sure you’re running the latest versions of both xAnalyzer and x64dbg.
2

Isolate the issue

Test with only xAnalyzer loaded (no other plugins) to ensure the issue is with xAnalyzer itself.
3

Search existing issues

Check if the issue has already been reported on GitHub Issues.

​
Creating a Bug Report

If the issue persists after the above steps, open a new issue with:
Use a descriptive title that summarizes the problem (e.g., “Analysis fails on executables with multiple dots in filename”).
  • xAnalyzer version (check About dialog)
  • x64dbg version
  • Operating system version
  • What you were trying to do
  • What you expected to happen
  • What actually happened
Clear, numbered steps that allow maintainers to replicate the issue:
  1. Load executable X
  2. Enable option Y
  3. Run analysis Z
  4. Observe error…
  • Log output from x64dbg Log tab
  • Any error dialogs or messages
  • Screenshots if applicable
If you can provide a sample executable that demonstrates the issue, it greatly helps with debugging. Make sure it’s safe to share.

​
Contributing API Definitions

One of the easiest ways to contribute is by adding or fixing API definitions.

​
When to Add Definitions

  • You notice an API call that isn’t being detected
  • An API is detected incorrectly (wrong argument types or order)
  • New Windows APIs that aren’t in the current definition files

​
Definition File Structure

API definition files are located in the apis_def folder with .api extension. Header files with data types are in apis_def/headers with .h.api extension. 
[MessageBox]
1=HANDLE hWnd
2=LPCTSTR lpText
3=LPCTSTR lpCaption
4=[MessageBoxType] uType
ParamCount=4
Header=shell.h.api;
@=MessageBox

​
Definition Format Rules

  • Main file: dllname.api (e.g., kernel32.api, user32.api)
  • Header file: headername.h.api (e.g., shell.h.api)
  • File names should match the DLL module name
[FunctionName]
1=TYPE parameter_name
2=TYPE parameter_name
ParamCount=2
Header=optional_header.h.api;
@=FunctionName
  • Simple types: HANDLE, LPCTSTR, DWORD, BOOL, etc.
  • Bracketed types: [TypeName] refers to a type defined in a header file
  • Pointer types: Add * or use LP prefix as appropriate
[TypeName]
TypeDisplay=UINT
Base=UINT
Type=Flag  ; or Enum
Const1=CONSTANT_NAME
Value1=0x00000000
  • TypeDisplay: How the type appears in comments
  • Base: Underlying data type
  • Type: Either Flag (bitmask) or Enum (enumeration)

​
Testing Your Definitions

1

Add definition file

Place your .api file in the apis_def folder (and .h.api in headers if needed).
2

Restart x64dbg

xAnalyzer loads definition files at startup.
3

Test analysis

Load an executable that uses the API you defined and run analysis to verify it’s detected correctly.
4

Verify output

Check that arguments, types, and comments appear correctly in the disassembly.

​
Contributing Code

For code contributions (bug fixes, new features, refactoring):

​
Development Setup

  1. Fork the repository on GitHub
  2. Clone your fork locally
  3. Set up build environment (Visual Studio 2017 or later)
  4. Create a branch for your changes

​
Code Contribution Guidelines

Make sure your changes don’t break existing functionality. Test thoroughly before submitting.
  • Follow existing code style for consistency
  • Test your changes with various executables (x86 and x64)
  • Document your changes in code comments where appropriate
  • Update relevant documentation if adding features
  • Keep commits focused - one logical change per commit

​
Submitting Pull Requests

1

Create a clear description

Explain what your PR does and why it’s needed. Reference any related issues.
2

Provide test cases

Describe how you tested the changes and what scenarios you verified.
3

Be responsive

Be prepared to address feedback and make requested changes.
4

Be patient

Maintainers review contributions in their spare time.

​
Documentation Contributions

Improving documentation helps all users:
  • Fix typos or unclear wording
  • Add examples and use cases
  • Expand troubleshooting guides
  • Translate documentation (if applicable)
Even small documentation improvements are valuable. Don’t hesitate to submit PRs for minor fixes!

​
License

By contributing to xAnalyzer, you agree that your contributions will be licensed under the MIT License. 
MIT License
Copyright (c) 2016 ThunderCls

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
View full license

​
Community Guidelines

  • Be respectful to maintainers and other contributors
  • Be constructive in feedback and criticism
  • Be patient - this is an open source project maintained by volunteers
  • Be helpful - assist other users when you can

​
Getting Started

GitHub Repository

Visit the main repository

Open Issues

Find issues to work on

Latest Release

Get the latest version

Contributions Badge

See all contributors
Thank you for contributing to xAnalyzer! Your efforts help make this tool better for the entire reverse engineering community.

Build docs developers (and LLMs) love

Get started for freeTalk to us