C C++
Clone or download
Latest commit ab7a422 Apr 22, 2018

README.md

Contributions Welcome Build Status GitHub release Github Releases Github All Releases GitHub stars license

xAnalyzer is a plugin for the x86/x64 x64dbg debugger by @mrexodia. This plugin is based on APIInfo Plugin by @mrfearless, although some improvements and additions have been made. xAnalyzer is capable of doing various types of analysis over the static code of the debugged application to give more extra information to the user. This plugin is going to make an extensive API functions call detections to add functions definitions, arguments and data types as well as any other complementary information, something close at what you get with OllyDbg analysis engine, in order to make it even more comprehensible to the user just before starting the debuggin task.

Table Of Contents

Features

Some of the main features and improvements include:

  • Extended function calls analysis (over 13,000 API’s definitions from almost 200 DLL’s)

  • Defined and generic functions, arguments, data types and additional debugging info recognition.

  • Automatic loops detection.

  • User maintained definition files

Before xAnalyzer

After xAnalyzer

Download

Download HERE the latest release of the binaries

Installation

  1. Download the latest version of x64dbg

  2. Copy xAnalyzer.dp32/xAnalyzer.dp64 files and apis_def folder to x32/x64 respective plugins directories of x64dbg

  3. Look under the "Plugins" menu in the main x64dbg window or in the secondary menu in the Disasm window as well for an "xAnalyzer" entry

Configuration

xAnalyzer has some options to choose from in order to personalize even more the experience with it, to use it just when you need it and the way you wan it. The plugin options are as follows:

  • Automatic Analysis: When this option is ON, the plugin is going to launch a full automatic analysis over the executable code every time it reaches the entry point when loading on the debugger. By using this option you get the more closer OllyDbg initial analysis behavior on x64dbg.

  • Extended Analysis: This option is going to force xAnalyzer to make an extended analysis over the entire code section of the debugged executable. WARNING!!! By enabling this option the analysis process may take much more time and resources to complete, also larges amount of RAM memory might be used by x64dbg depending on the size of the section and the amount of extra data added to the debugged executable static disassembly

  • Analyze Undefined Functions: By selecting this option xAnalyzer will use generic analysis and argument types for all of those API Calls/Functions that are not defined in the api definition files and also calls like:

CALL {REGISTER}
CALL {REGISTER + DISPLACEMENT}
CALL {DYNAMIC_POINTER}

Usage

xAnalyzer has some commands and menu options to choose from when working with an executable:

Analyze Selection

By making a selection of several instructions in the disassembly windows of x64dbg and selecting this menu, a fast analysis will be made over the selected lines. You can also use the command xanal selection for launching this option or even set your own hotkeys for it in the x64dbg gui.

Analyze Function

If you are in the middle of some function you could use this menu entry to analyze that entire function and only that function. Taking your single selected instruction as a reference xAnalyzer will process from there all the lines inside a block of code. You could also use the command xanal function for launching this type of analysis or even set your own hotkeys for it in the x64dbg gui.

Analyze Module

This command it's going to launch a full analysis over the entire module. This feature takes the Extended Analysis option into consideration for the depth of analysis to be used. You could use the command xanal module to execute it as well or even set your own hotkeys for it in the x64dbg gui.

Remove Analysis Menus

In these cases, all of these menus are going to make the opposite of what the previous commands did. In case you want to get rid of the analysis extra information in some parts of the code or in the entire executable if wished. You could also use the commands: xanalremove selection/function/module

API Definition Files

xAnalyzer has an expandable system of API definition files, these files are present in the folders "api_def" and "api_def/headers" which should contain all the files with a .ini structure and with the norm of:

  • "filename": This is the name of the module on which the API function is located in.

  • "filename.h": This is the header containing type data (flags and enums) related information

  • ".api" extension: Specifies that it is a definition file, no other extension will be recognized (kernel32.api, shell32.api, etc)

All these ini files contain important information for the plugin such as, the functions prototypes, argument types, etc. All of this information is used by xAnalyzer in order the set the extra information on the static code. A single entry in any of these files would be like:

File user32.api

[MessageBox]
1=HANDLE hWnd
2=LPCTSTR lpText
3=LPCTSTR lpCaption
4=[MessageBoxType] uType
ParamCount=4
Header=shell.h.api;
@=MessageBox

File shell.h.api

[MessageBoxType]
TypeDisplay=UINT
Base=UINT
Type=Flag
Const1=MB_ABORTRETRYIGNORE
Value1=0x00000002
Const2=MB_CANCELTRYCONTINUE
Value2=0x00000006
Const3=MB_HELP
Value3=0x00004000
Const4=MB_OK
Value4=0x00000000
Const5=MB_OKCANCEL
...

Any argument between brackets means that this is an specific data type (enum or binary flags) and that this will be defined in the proper .h header file specified in the key "Header".

As for the header file the scheme is pretty much the same just a couple of keys there, like "TypeDisplay". This specify the proper data type to display in the dbg comment, then it comes "Base", and it will point to the base data type used by the main entry, in case there´s a linked data type, this could be between brackets as well. "Type" key is the type of data structure this is and it can be "Flag" or "Enum". Finally all the variable names and values come along.

If you find that a certain API call definition is not being detected or not detected correctly by xAnalyzer it might mean that it's not present in the definition files or that it is defined incorrectly, so in this case an addition or modification could be made to include any missing function or arguments as long as the same structure is followed it may be 100% customizable.

Known issues and limitations

  • First undefined call with generic arguments in a function will not be processed, unless it's preceded by a jump, since there's no way to tell how many arguments to use without illegaly using the function prolog instructions. Only docummented calls will be processed at the begining of a function or an undefined function that has been presided by a jump.

  • Some "uncommon" functions have arguments among jumps, so according to the actual desgin of the plugin (no jumps among functions arguments) these calls won't be processed, since each time a jump is found the instructions in the stack are cleaned.

  • Nested calls will work correctly only when:

    1-) Inner call is defined
    2-) If inner undefined call takes no more arguments of the stack than the arguments needed by the outter call

  • It only detects loops inside functions (function boundaries Prologs/RETs). If a function contains a RET in the middle of its code it will be detected as a function end and the loops stack is cleared.

  • Analysis could fail if the executable being debugged has multiple dots in its name

  • Incorrect loop detection for a section with an non-conditional jump inside it (See #7)

  • Nested argument lines (xAnalyzer has support for nested arguments but x64dbg at the moment doesn't)

To-Do Long-Term

  • Add entropy analysis

  • Flow analysis scanning instead of linear (trace emulation)

  • Case-Switch detection

Version History

xAnalyzer 2.5.2
-Used current selected disasm line for module analysis instead of cip
-Modified some typing in plugin entries
-Some code refactoring
-Modified command "xanal/xanalremove exe" to "xanal/xanalremove module"

xAnalyzer 2.5.1
-Fixed crash on mov instructions variations

xAnalyzer 2.5.0
-Removed [EBP+/-] instructions as possible function caller arguments
-Removed prefix "0x" of all function arguments values since hexadecimal is inferred
-Fixed arguments where pointer variables wouldn't show correctly as pointers but as base data type instead
-Added recognition of stack pointer usage (ESP) as possible argument for function calls (x86)
-Added use of accurate data type name in arguments instead of generic/base data type name
-Added function smart tracking feature (Smart prediction and recognition of indirect function calls like: CALL {REGISTER}, CALL {POINTER})
-Added name of function pointers as parameters (the entire function name, if detected, will be used instead of just the address)

xAnalyzer 2.4.3
- Added recognition of MOV instructions on x86
- Added recognition of functions with "Stub" suffix
- Fixed bug on "auto analysis" (added more EP check conditions)
- Clear Auto Comments/Auto Labels options checked now by default

xAnalyzer 2.4.2
- Fixed BoF when argument flags comment overpassed MAX_COMMENT_SIZE
- Fixed function name search bug when definition lies in a second .api file

xAnalyzer 2.4.1
- Added a new hotkeys scheme
- Added new options to control which previous analysis data should be erased. (This gives the possibility to work seamlessly with map loader plugins like SwissArmyKnife, etc).
- Added new commands (old ones have been deprecated)
xanal selection : Performs a selection analysis
xanal function : Performs a function analysis
xanal exe : Performs an entire executable analysis
xanalremove selection : Removes a previous selection analysis
xanalremove function : Removes a previous function analysis
xanalremove exe : Removes a previous entire executable analysis
xanal help : Brings up to the log window some help text
- Fixed automatic analysis not launching on startup (Closes #18 )
- Fixed various api definition files (Closes #17 )

xAnalyzer 2.4
- New and improved API definition files with a slightly modified scheme (13,000 API’s from almost 200 DLL’s)
- Symbols recognition system for each API definition argument used (1000+ enums data types and 800+ flags)
- Recognition of params data types (BOOL, NUMERIC, NON-NUMERIC)
- VB "DllFunctionCall" stubs detection
- Strings passed as arguments are cleaner now (debugger comments now have the address part stripped)
- Execution Summary added to log window
- Hotkeys feature removed (will be incorporated in future revisions) due some conflicting with x64dbg
- Various bugs fixed

xAnalyzer 2.3.1
- Fixed bug when launching "Analyze Selection" menu with a single line selected, what caused an abrupt dbg exception (thanks to @blaquee)
- Check if the definition files folder "apis_def" and definition files exist inside it before loading the plugin
- Changed hot keys to Ctrl+Shift+X for selection and Ctrl+X for functions

xAnalyzer 2.3
- Added option "Analyze undefined functions". (OFF by default, anything that's not in definition files is not analyzed)
- Added option "Automatic analysis" (OFF by default, make analysis on launch at EP of debugged executable)
- Added feature "Analyze Selection" (Makes a selected instructions analysis, it supports multiple selected calls)
- Added feature "Analyze Function" (Makes an automatic discovery and analysis of the current function from the selected address)
- Added feature "Remove Analysis" from Selection/Function/Executable
- Added command shortcuts
- Added new icons
- Added saving configuration to .ini file
- Added capitalization of hexadecimal argument values
- Restructured feature "Analyze Executable" (Makes a full analysis of the current executable)
- Restructured menus
- New about dialog now shows the version number to keep track of updates
- Some small bug fixes
- Fixed and merged some API definition files
- Speed and stability improvements

xAnalyzer 2.2
- Added analysis progress indicator
- Added new analysis depth mode
-Now automatic analysis is only executed if no backup database is present
- Bugs fixed

xAnalyzer 2.1
- Generic arguments for undefined functions and internal subs
- Smart function comments and arguments (only functions with arguments on stack are being processed). This allows xAnalyzer to give a cleaner sight of the code by just processing and commenting those functions with actual arguments
- Detection of indirect function calls with scheme CALL -> DYNAMIC_MEMORY -> API
- Detection of indirect function calls with scheme CALL -> REGISTER/REGISTER + DISPLACEMENT -> API
- Detection of indirect function calls with scheme CALL -> JMP -> JMP -> API
- Automatic loops detection
- Fixed minors bugs
- Code rearrangements

xAnalyzer 2.0
- Support for x64 bits
- Support API call arguments order changes in x64 bits
- Support PDB files extra info in API calls
- Support of direct/indirect API calls
- Support of static API functions calls to main module code
- Fixed several wrong API calls arguments order in definition files. More calls can now be detected and commented properly
- Some improvements and better written code
- Various bugs solved

xAnalyzer 1.2
- Updated the API's definition files
- Added support to vc6+ executables

xAnalyzer 1.1
- Fixed issue that didn't show API's info on VC++ executables due to not properly cleaning BASIC_INSTRUCTION_INFO structures before/after using them in a loop
- Added/Updated the API's definition files
- Bugs fixed

xAnalyzer 1.0
- Initial Release

Contributing Guidelines

Contributions of all kinds are welcome, not only as PR but also as bugs reporting, documentation, etc.

Please keep the following in mind:

  • Bug Reports: Make sure you're running the latest versions of the plugin and x64dbg, also make sure you have no other plugins loaded but xAnalyzer plugin. If the issue(s) still persist: please open a clearly documented issue with a clear title and as much information as possible in order to replicate the issue and give it solution.

Thanks for using xAnalyzer plugin...and Happy Reversing to All!