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.

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.

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.

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

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

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:

 - if a Golang startup signature matches the entry point (PC-only)
 - if the Golang plugin detects a Golang-specific segment name
 - if the elf loader finds a "Go" note in the input file
 - on PE files: if certain Golang symbol names or a Go build id signature is found

Analysis

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

 - function information (e.g. name, package, range) retrieved from the pclntab
 - type information (e.g. name, package, layout, size) retrieved from the typelinks table

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

  `golang:detect_and_parse` (Edit>Other)

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.

  force                         try to force the analysis
                                (no detection step needed)
  off                           disable the plugin
  no_rtypes                     do not import any types
  rname_len2                    force the reflect type name format to go1.17
                                and later (varint encoding: 1-10 bytes)
  rname_len1                    force the reflect type name format to before
                                go1.17 (2 bytes)
  import_lnnums                 recover file names & line numbers from pclntab
  no_func_end_from_pcval_tabs   do not derive a function's end from pclntab
                                metadata
  force_regabi[=on|=off]        override calling convention version
                                 `=off`: will force the stack-based CC
                                 `=on`/no value: will force
                                 the register-based CC

See cfg/golang.cfg for available configuration options.

Examples

forcing analysis and register-based calling convention

  -Ogolang:force:force_regabi

disabling the plugin

  -Ogolang:off

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