The binaries produced by the Rust compiler have some peculiarities which make them difficult to analyze, such as:

  - non-standard calling conventions
  - non-terminated string literals
  - unusual name mangling scheme

By default, Rust plugin is enabled if one of the following condition is true

  - one address is named 'rust_begin_unwind'
  - the string 'rustc-' can be found somewhere in the program
    If the segment '.rodata' exists, the search is limited to this segment

String literal analysis

Rust plugin walks to all addresses in segment with name ending in "__const", ".rodata" or ".rdata" and creates string literals on xref

  - on dref, the string literal is set up to the next dref
  - on cref, Rust tries to retrieve length from nearby instructions
    Arm, Risc-V and pc proc module benefit from this

To force the string literal detection:

  idaapi.load_and_run_plugin("rust", 1)

Demangling name

Rust plugin also offers the possibility to configure a demangler library for rust. By default the plugin will use the librustdemangle library that is shipped with IDA. You can disable this feature in 'Edit>Plugin>Rust language helper' or specify another library to use.

See cfg/rust.cfg for the possible options

List of '-Orust' options

  - on  : enable rust plugin for this session of IDA
  - off : disable rust plugin for this session of IDA

Example

  -Orust:off

This disable the plugin for this session of IDA.

Demangling

The swift plugin uses libSwiftDemangle to demangle Swift names. Note that IDA already had a built-in swift demangler, but it was becoming difficult to maintain. In the long-term we hope to fully deprecate IDA's custom swift demangler in favor of libSwiftDemangle.

However, the new approach still hasn't been fully integrated into IDA, so there may be times when IDA's old swift demangler produces more desirable results.

'cfg/swift.cfg' file presents all the options

'-Oswift' command line switches can be used to enable or disable some plugin options.

List of options

  - <demangler_path> : use specific libSwiftDemangle library
  - -d : use the built-in IDA swift demangler (legacy)
  - +d : use libSwiftDemangle swift demangler
  - -m : don't present metadata in nice way
  - +m : present metadata in nice way
  - -e : don't import enumeration types
  - +e : import enumeration types
  - -s : don't import structure types
  - +s : import structure types
  - -v : don't set variable type based on mangled names
  - +v : set variable type based on mangled names
  - -f : don't set function prototype based on mangled names
  - +f : set function prototype based on mangled names
  - -g : don't group functions in folders corresponding to modules
  - +g : group functions in folders corresponding to modules

Examples

  -Oswift:-g

Do not group functions into folders.

  -Oswift:/tmp/libSwiftDemangle_custom.dylib

Use /tmp/libSwiftDemangle_custom.dylib as the libSwiftDemangle library.

picture_search is a plugin that allows you to search for, and inspect pictures that are embedded in the binary.

The key feature of the plugin is the "Search for pictures" action, available in the "Search" menu, that will scan the entire binary (or the selection if there is one) for so-called "magic" numbers of well-known image types (PNG, JPEG, ...), and present the results in a tabular fashion:

                 [Address]         |[Format]
        .noptrdata:0000000000511620|GIF89a
        .noptrdata:00000000005133E0|PNG
        .noptrdata:0000000000517460|JPEG
        .noptrdata:000000000051ADA0|BMP

Note: at this point, pictures have not been decoded yet; the plugin has merely spotted what looks like the start of pictures. Decoding will only happen when triggering any of the following actions.

Double-clicking any row of that list will show the picture directly in IDA. Opening the context menu will reveal even more possibilities: open the picture in the OS's default viewer, save it, jump to its start address...

In addition to this very handy scanning feature, the plugin will add the "Open picture" action to the disassembly listing's context menu when the current position happens to be near data that matches the well-known image types' magic numbers.

The -O command line switch allows the user to pass options to the plugins. A plugin which uses options should call the get_plugin_options() function to get them.

Since there may be many plugins written by independent programmers, each options will have a prefix -O in front of the plugin name.

For example, a plugin named "decomp" should expect its parameters to be in the following format:

In this case, get_plugin_options("decomp") will return the "option1:option2:option3" part of the options string.

If there are several -O options in the command line, they will be concatenated with ':' between them.

List of plugins recognizing '-O' switch

• hexrays :

This switch is not available in the IDA Home edition.

Analyzing software in general and reverse-engineering in specifically are difficult. It is challenging even with a first-class tool like IDA: quite frequently, the limitations of the tool reveal themselves. That's why IDA can be programmed in multiple ways: with the built-in scriptable language, with Python 3, and plugins in C/C++.

Plugin contest in a nutshell:

• Create an innovative and useful extension of our products and win the contest!

• Three cash prizes are on the stake: The first place is 3000 USD, the second place is 2000 USD, and the third place is 1000 USD.

• Who can participate: all IDA license holders.

Want to know more? Check our contest rules

IDA natively is shipped with repository of plugins, that are inside your IDA folder. Yo udo not need to install them separately, but in this section you'll find guides on how to use their basic features.

List of plugins shipped with IDA:

• Rust

• Swift

• Golang

• dscu

• Objective-C analysis

• picture_search

• gooMBA

• IDAClang

IDA’s functionality can easily be extended by the use of programmable plug-ins. Plugins may be written to automate routine tasks, for example to enhance the analysis of hostile code or to add specific functionality to our disassembler. Plugins should be written in C++. They may be linked to hot keys or menu items and have full access to the IDA database and may examine or modify the program or use I/O functions. Our SDK contains

• 4 sample plugins

  • a simple “hello world” type plugin.

  • a sample processor extension plugin (adds 2 NEC V20 specific instructions to the 80×86 processor module).

  • a sample pdb file loader ( as used by IDA itself ).

  • a sample executable decryption plugin.

  • a sample graphing plugin.

• the source code to a 30+ processor modules!

• the source code to a 20+ loaders

• header files (almost 19.000 lines of heavily commented documentation to IDA’s exported interface).

• import libraries for Borland C/C++ (32 & 64 bits), Microsoft Visual C++ 6 (32 & 64 bits), GNU C/C++ (32 & 64 bits), Watcom 11

• if you received IDA as a download, the SDK download information can be found in the e-mail you have received.

Additional free plugins, from Ilfak’s blog:

Do you want to create custom plugins and wonder where to start? Check our tutorials based on the language of your choice:

Golang binaries are by default statically linked and full of metadata therefore a lot can be gained from annotating a Golang binary's contents using recovered metadata.

Detection

The golang plugin's analysis only happens by default if the input file is detected as a Golang file. There are multiple mechanisms in place to detect that:

Analysis

The metadata parsed by the golang plugin falls under two main categories:

The package paths of functions and types are used to create folders. This analysis will occur upon `ev_newfile` (when a new file has been loaded) if Golang has been detected.

Actions

This action is useful to force a full search of the binary for Golang metadata. It will first attempt to parse a pclntab at the current address, if this is unsuccessful it will perform a full search of the binary for the pclntab's signature and parse it if found. In addition, it will also attempt to locate and parse the type information.

Calling Conventions

Golang has its own calling convention(s), denoted in IDA as `__golang`. In fact, Golang has two different calling conventions: a stack-based CC (abi0) and a newer register-based CC (abiinternal). The version of Golang and thus which calling convention to use will be automatically inferred from metadata structures; It is also controllable through the `force_regabi` command line option.

List of `-Ogolang` options

Command line options take precedence over config file options.

See cfg/golang.cfg for available configuration options.

Examples

forcing analysis and register-based calling convention

disabling the plugin

This plugin (nicknamed "dscu" for brevity) is essentially just an extension of the Mach-O loader. It allows you to manually load modules from a dyldcache that were not loaded when first opening the cache in IDA (the plugin is only activated after using the "single module" option for a dyldcache).

For a quick overview of the dscu functionality, see menu File>Load file>DYLD Shared Cache Utils.

Loading Modules

There are a few ways to manually load a module from the cache:

1) Use File>Load file>DYLD Shared Cache Utils>Load module... and choose which module to load

2) Right-click on an unmapped address in the disassembly, and select 'Load module <module name>'

3) Programatically:

Loading Sections

dscu also allows you to load a subset of a given module.

Any section from any of the dyldcache's submodules can be loaded individually. This is especially useful when analyzing Objective-C code, since often times it is convenient to only load Objective-C info from a given module without loading all of its code.

For example, if you see a pointer to a selector string that has not been loaded:

Right-click on "0x1AECFF7F9" and dscu will provide you with two options:

The UIKitCore module is huge, so perhaps you don't want to load the entire thing, but still want to clean up the disassembly. If you choose "Load UIKitCore:__objc_methname", dscu will load only these selector strings into the database:

This operation is much faster, and still provides a lot of benefit to the analysis.

Sections can also be loaded via:

or programmatically with:

See also

The objc plugin performs Objective-C specific analysis on the database.

For an overview of what the plugin can do, see the menu options in Edit>Other>Objective-C, or the config options in objc.cfg.

Type Information

The bulk of the plugin's work is done at file load time, when it will parse all Objective-C type information embedded in the binary, and use this to create tinfo_t structures for all known classes and construct prototypes for all known methods.

This analysis can be invoked manually at any time with:

  Edit>Other>Objective-C>Reload Objective-C info

Or:

  idaapi.load_and_run_plugin("objc", 1)

You can also disable objc analysis at load time with command line option:

  -Oobjc:+l

Or check the "Lazy mode" option in:

  Edit>Other>Objective-C>Objective-C Options...

Decompilation

The plugin will also perform Objective-C analysis during decompilation.

When a function is decompiled, the plugin will analyze any calls to objc_msgSend, and use the arguments to determine if objc_msgSend will ultimately invoke one of the methods in the current database.

If such a situation is detected, the plugin will replace the call to objc_msgSend with a call to the target method, and add an xref to the method. This is done in the hopes that continued use of the decompiler will improve call graphs for Objective-C binaries.

If the target method has type information, then the return type can be used to refine the types of local variables in the pseudocode, which in turn could lead to more method calls being detected, and so on.

You can disable objc analysis in the pseudocode with command line option:

  -Oobjc:-h

Or uncheck the "Enable decompiler plugin for Objective-C" option in:

  Edit>Other>Objective-C>Objective-C Options...

Debugging

objc also provides tools for dynamic analysis.

During debugging, you can analyze objc info for a specific library by right-clicking in the Modules window and selecting "Load debug info".

This operation can also be performed programmatically with:

  n = idaapi.netnode()
  n.create("$ objc")
  n.supset(1, "/module/path", 'R')
  idaapi.load_and_run_plugin("objc", 3)

If you prefer that objc does not perform analysis during "Load debug info", (say if DWARF information is available for a module and you prefer that), you can disable this functionality with command line option:

  -Oobjc:-s

Or by unchecking the "Enable SIP for Objective-C" option in:

  Edit>Other>Objective-C>Objective-C Options...

Step Into Message

The plugin also implements a "step into" debugger action for Objective-C.

If you use this action before a call to objc_msgSend, objc will try to calculate the address of method that is being invoked, and break at the method address rather than step into the objc_msgSend function itself.

You can perform this action with shortcut:

  Shift+O

Or via the menu option:

  Debugger>Run until message received

Or programmatically with:

  idaapi.load_and_run_plugin("objc", 2)

This action can be very useful, but you must be careful. When invoked, the action will automatically run to the address of objc_msgSend, analyze its arguments, then continue to the target method.

If there is no subsequent call to objc_msgSend in the program, you will lose control of the process. It is best to use this action only when you are sure that IP is in the vicinity of an objc_msgSend call.

NSConcreteStackBlock

The objc plugin can also be used to analyze Apple binaries that make heavy use of blocks: https://clang.llvm.org/docs/Block-ABI-Apple.html

The analysis involves identifying NSConcreteStackBlock instances on the stack, and creating a specialized Block_layout structure to apply to the function's stack frame.

The end result transforms the following sequence of statements:

  loc_BF60:                                 Block_layout_BF60 v1;
    v1 = _NSConcreteStackBlock;             v1.isa        = _NSConcreteStackBlock;
    v2 = 0x...;                             v1.flags      = 0x...;
    v3 = 0;                                 v1.reserved   = 0;
    v4 = __block_invoke;             =>     v1.invoke     = __block_invoke;
    v5 = &__block_descriptor_tmp;           v1.descriptor = &__block_descriptor_tmp;
    v6 = ...                                v1.lvar1      = ...
    v7 = ...                                v1.lvar2      = ...
    ...                                     ...
    func(&v1);                              func(&v1);

Already this cleans up the analysis quite a lot, but more importantly this new Block_layout_BF60 structure will be applied to the prototype of __block_invoke, which can heavily improve the pseudocode.

Block analysis can be performed on the database with:

  Edit>Other>Objective-C>Analyze stack-allocated blocks (entire database)

Or programmatically with:

  idaapi.load_and_run_plugin("objc", 5)

You can also perform block analysis on a specific function:

  Edit>Other>Objective-C>Analyze stack-allocated blocks (current function)

Or with shortcut:

  Ctrl+Shift+S

Or programmatically:

  n = idaapi.netnode()
  n.create("$ objc")
  n.altset(1, 0xBF60, 'R') # the address can be any address within the function
  idaapi.load_and_run_plugin("objc", 5)

These actions work in both the disassembly and pseudocode windows, but note that you must refresh the pseudocode with F5 for the changes to take full effect.

Also, please note that this feature makes use of the microcode in the hexrays SDK, so you must have the decompiler in order to use it.

NSConcreteGlobalBlock

Global blocks (i.e. blocks that don't make use of local variables) are much easier to analyze, and simply involve identifying references to NSConcreteGlobalBlock in the __const segment.

Global blocks are analyzed automatically at load time, but the analysis can be performed manually at any time with:

  Edit>Other>Objective-C>Re-analyze global block functions

Or:

  idaapi.load_and_run_plugin("objc", 4)

Command Line

Here's a summary of the command-line arguments that can be passed to objc:

objc features can be enabled or disabled using '+' or '-', followed by one of the following characters:

  v: verbose mode
  s: source info provider
  h: hexrays decompiler analysis
  l: lazy mode

For example, -Oobjc:+v:+l:-s will enable verbose and lazy mode, and will disable the objc SIP.

See also

• Debugger for macOS

• Remote iOS debugger

• DYLD Shared Cache Utils