This document dwells upon function identification and symbol porting in reverse engineering of Internet of things (IoT) devices without using BinDiff and PatchDiff2, which are “too good” for the purposes here and are inapplicable in certain scenarios. Typical function identification technologies include the Fast Library Identification and Recognition Technology (FLIRT) in IDA and the rizzo method developed by Craig Heffner, whose rationale and engineering practices are detailed here. The rest of this document explains the usage of some other IDA plug-ins.
Introduction
This document dwells upon function identification and symbol porting in reverse engineering of Internet of things (IoT) devices without using BinDiff and PatchDiff2, which are “too good” for the purposes here and are inapplicable in certain scenarios. Typical function identification technologies include the Fast Library Identification and Recognition Technology (FLIRT) in IDA and the rizzo method developed by Craig Heffner, whose rationale and engineering practices are detailed here. The rest of this document explains the usage of some other IDA plug-ins.
Function Identification/Symbol Porting
1 FLIRT
1.1 What Is FLIRT
Assume that you want to analyze a stripped ELF file without debugging information and symbol information, which was statically linked to OpenSSL’s libcrypto.a. What you want to know is the encryption algorithm and hash algorithm used by this ELF file. The findcrypt plug-in can do the job, but not competently enough.
In fact, for this purpose, FLIRT is a better choice. It is a function identification technology that IDA comes with to address such requirements.
IDA F.L.I.R.T Technology: In-Depth[1] describes in detail the basic principle of the FLIRT technology implemented in IDA 3.6:
————————————————————————–
Each function is represented by a pattern. Patterns are first 32 bytes of a function where all variant bytes are marked.
A special signature file, called startup signature file is applied to the entry point of the disassembled program to determine the generating compiler.
For the sake of user’s convenience we attempted to recognize the main() function as often as it was possible. The algorithm for identifying this function differs from compiler to compiler and from program to program.
The signature file contains no byte from the original libraries, except for the names of the functions.
————————————————————————–
Simply put, functions in a static library are identified from their predefined signature bytes, call relationships, and some special check items. For each function, its name and signature are organized in a specified format and saved in a .sig signature file. To analyze an ELF file, IDA loads related .sig files and automatically identifies library functions statically linked in the file.
The mechanism of identifying functions from signature files is relatively complicated. Only obtaining the first 32 bytes of a function is far from the ultimate goal of function identification. For details, see IDA F.L.I.R.T Technology: In-Depth[1].
1.2 Signature File
IDA comes with signature files, including the following:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | $ cd "C:\Program Files\IDA" $ tree /F /A sig | list | +---arm | android_arm.sig | armlibb.sig | armlibl.sig | armlib_l.sig | autoload.cfg | elf.sig | mfc.sig | pe.sig | vc_atl.sig | vc_extra.sig | vc_rtf.sig ... | +---mips | mfc.sig | pe.sig | psx.sig | psyq.sig | +---pc | autoload.cfg ... |
These signature files are stored in the following directory:
| 1 | <IDA PATH>\sig\<arch>\*.sig |
where <arch> indicates the CPU architecture, which is probably ARM when it comes to reverse engineering of IoT devices. The name of the .sig file provides some information, from which we can infer the source of the file. The .sig file may contain descriptive information, which can be viewed by using the following method:
| 1 2 3 | $ strings -n 5 armlibl.sig | head -2 IDASGN ARM library little endian |
The descriptive information is displayed in the second line. Note that not all .sig files contain such information.
1.3 Signature Application
View > Open subviews > Signatures (Shift-F5)
Here, the current signature file and the number of functions identified by using this file are listed.
View > Open subviews > Signatures (Shift+F5) > Shortcut menu > Apply new signature (Ins)
Or
File > Load file > FLIRT signature file
Here, all signature files under <IDA PATH>\sig\<arch>\ are listed.
Chapter 12 in The IDA Pro Book, 2nd edition, describes the usage of FLIRT and FLAIR:
| 1 2 3 4 5 6 7 | ————————————————————— Only functions named with an IDA dummy name can be automatically renamed. In other words, if you have renamed a function, and that function is later matched by a signature, then the function will not be renamed as a result of the match. Therefore, it is to your benefit to apply signatures as early in your analysis process as possible. ————————————————————— |
The “dummy name” takes the form of “sub_…”. After a binary is disassembled, signature files should be applied as early as possible to avoid the situation where manual renaming makes automatic renaming of signature files impossible.
1.4 What Is FLAIR
FLAIR is short for Fast Library Acquisition for Identification and Recognition. This is a toolkit in IDA for customization of signature files.
The method of using FLAIR tools to create a signature file is as follows:
| 1 2 3 | ELF -- (pelf) --> PAT -- (sigmake) +--> SIG -- (zipsig) --> Compressed SIG | +--> EXC |
Use pelf to create a .pat file from the ELF file. .pat is the format of text files that list names and patterns of functions in the static library.
Use sigmake to generate a .sig file from the .pat file. Collisions often occur during the first execution of sigmake because multiple functions share the same pattern. In this case, sigmake generates an .exc file, which must be handled to resolve the collisions. After that, execute sigmake again to create the desired .sig file.
The .sig file generated by sigmake is OK for IDA. Of course, it can also be compressed with zipsig to generate a compressed file with the same extension. IDA supports both uncompressed and compressed .sig files.
FLAIR ships with help files, including the following:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | ————————————————————– readme.txt This is a top-level overview of the signature creation process. pat.txt This file details the format of pattern files. sigmake.txt This file describes the use of sigmake.exe for generating .sig files from pattern files as well as the format and handling method of .exc files. plb.txt This file describes the use of the static library parser, plb.exe.————————————————————– |
1.5 EXC File
| 1 2 3 | $ pelf libcrypto.a libcrypto_arm.pat $ sigmake -n”openssl-1.0.1l libcrypto.a for arm” libcrypto_arm.pat libcrypto_arm.sig libcrypto_arm.sig: modules/leaves: 497/595, COLLISIONS: 9 |
This indicates that collisions exist in the .pat file because of multiple functions sharing the same pattern. In this case, libcrypto_arm.exc is automatically generated, like the following:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | -------------------------------------------------------------- ;(delete these lines to allow sigmake to read this file) ; add '+' at the start of a line to select a module ; add '-' if you are not sure about the selection ; do nothing if you want to exclude all modules X509_get_default_private_dir 00 0000 00001FE51EFF2FE1........00001FE51EFF2FE1........00001FE51EFF2FE1 EVP_dss 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 EVP_dss1 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 EVP_ecdsa 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 NETSCAPE_SPKI_free 00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA PROXY_CERT_INFO_EXTENSION_free 00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA ----------------------------------------------------- |
The first four lines are the same in all .exc files generated with sigmake, reminding you that you can add a plus sign (+) or hyphen (-) at the start of each line:
+: uses this function name.
-: has this function name appear in the form of comment.
Following the four lines are collisions separated with blank lines.
The following is an example showing how to manually handle the .exc file:
| 1 2 3 4 5 6 7 8 9 10 | ---------------------------------------------------------------X509_get_default_private_dir 00 0000 00001FE51EFF2FE1........00001FE51EFF2FE1........00001FE51EFF2FE1 +EVP_dss 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 EVP_dss1 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 EVP_ecdsa 00 0000 00001FE51EFF2FE1........0C3090E50100A0E10310A0E1......EA0C0090E5 NETSCAPE_SPKI_free 00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA -PROXY_CERT_INFO_EXTENSION_free 00 0000 00101FE5......EA........00101FE5......EA........00001FE5......EA -------------------------------------------------------------- |
The first four lines must be deleted from the .exc file, indicating that it has been manually handled; otherwise, sigmake would fail to parse the exclusions file during subsequent execution.
For the first collision group (counting from 1), nothing is done, meaning that this function name is abandoned.
For the second collision group, the function name “EVP_dss” is selected, with the other two abandoned, which leads to a false positive.
For the third collision group, a comment “PROXY_CERT_INFO_EXTENSION_free” will be added for the matched function name.
You should keep the following in mind when attempting to resolve collisions:
a. The simplest way is to delete the first four lines that begin with semicolons from the .exc file, with the other contents remaining unchanged. This indicates that all function name in collision groups are abandoned and they will not be used during renaming.
b. Do not add a plus sign (+) or hyphen (-) to more than one function name in a collision group. You should add either to only one function name.
c. If a collision group contains only one function, do not add a plus sign (+) or hyphen (-) in front of that function. Just leave it alone. This means that this function name is abandoned.
2 IDB2PAT
The general process of customizing a signature file is as follows:
ELF -> PAT -> SIG
Sometimes it may be like this:
IDB -> PAT -> SIG
Assume that you analyzed some raw IoT firmware and renamed a batch of key functions. Now you need to analyze a new version of firmware that looks much alike the previous one you analyzed. BinDiff or PatchDiff2 can compare the binaries, but that would be like using a sledgehammer to crack a nut. Is there any other method for fast porting of function names?
IDB2PAT, as its name implies, is an IDA plug-in for export of PAT files from the current IDB. After the export, you can use sigmake to generate SIG files and apply them to a new IDB.
Initially, IDB2PAT is a plug-in written in C that needs to be complied with the IDA SDK. In other words, every time IDA is upgraded, IDB2PAT needs to be recompiled. FireEye then provides a plug-in written in Python[6].
Press Alt+F7 to load idb2pat.py. When asked to select a location to save the .pat file, do so and click OK.
idb2pat.py can be used in IDA 7.2. For use in IDA 7.1, the following changes must be made: Replace all “get_name(” with “get_name(BADADDR,”. This is because the prototype of the get_name() function is “get_name(ea)” in version 7.2, but “get_name(from,ea)” in version 7.1. In the original implementation, Config() uses the default parameter “mode=ALL_FUNCTIONS”, which should be changed to “NON_AUTO_FUNCTIONS”; otherwise, “sub_…” would be also exported to the .pat file, which is pointless.
3 lscan[7]
Assume that you are analyzing a stripped ELF file with IDA and find statically linked library functions. Now you want to know which static libraries are used in this ELF file and want to rapidly rename these static library functions. If you have a lot of .sig files on hand, it would be an excruciating job to match the ELF file against these .sig files one by one.
Luckily, lscan comes to your rescue. lscan is not an IDA plug-in, but an independent Python script. It checks to what extent a SIG file matches an ELF file. A higher percentage of matched contents indicates a greater chance of the ELF file using the related static library. lscan can compare multiple SIG files with a single ELF at one go and then preferentially applies the SIG file with the highest percentage of matched contents in IDA.
The tool does not support SIG files compressed with zipsig and can identify only uncompressed SIG files.
| 1 2 3 4 | [scz@ /home/scz/src]> pip2 install pyelftools pefile [scz@ /home/scz/src]> git clone https://github.com/maroueneboubakri/lscan.git [scz@ /home/scz/src]> du -hs lscan 406M lscan |
The installation package of lscan downloaded with the git clone command is as big as 406 MB. In fact, only lscan.py is useful. Other files are all test sets, and the SIG files that the tool ships with are not of much use. Therefore, it is unnecessary to download this tool with the git clone command.
| 1 2 3 4 5 6 | [scz@ /home/scz/src/lscan]> python2.7 lscan.py -h Usage: lscan.py [options] Options: -h, --help show this help message and exit -v, --versbose Verbose mode -s SIGFILE, --sig=SIGFILE Signature file -S SIGDIR, --sigs=SIGDIR Signature folder -f BINFILE, --file=BINFILE ELF file -d, --dumpDump signature file |
Use all SIG files under arm/sig/ to match FLIRTTarget:
| 1 2 3 4 5 6 7 | [scz@ /home/scz/src/lscan]> python2.7 lscan.py -S arm/sig -f /tmp/FLIRTTarget arm/sig/libssl-1.0.1e.sig 15/573 (2.62%) arm/sig/libpthread-2.13.sig 0/260 (0.00%) arm/sig/libssl-1.1.0.sig 0/863 (0.00%) arm/sig/libc-2.22.sig 0/2841 (0.00%) arm/sig/libc-2.23.sig 0/2853 (0.00%) arm/sig/libm-2.13.sig 0/318 (0.00%) arm/sig/libcrypto-1.0.1e.sig 27/4518 (0.60%) arm/sig/libcrypto-1.1.0.sig 0/37 (0.00%) arm/sig/libm-2.22.sig 0/339 (0.00%) arm/sig/libpthread-2.22.sig 0/273 (0.00%) arm/sig/libc-2.13.sig 0/2816 (0.00%) |
No SIG file of lscan matches FLIRTTarget.
Use SIG files generated from custom-built .a files to match FLIRTTarget:
| 1 2 | [scz@ /home/scz/src/lscan]> ls /tmp/sig fromidb.sig libcrypto_arm.sig libssl_arm.sig |
fromidb.sig is taken from IDB2PAT, and the other two are generated from library files compiled by the author.
| 1 2 3 4 | [scz@ /home/scz/src/lscan]> python2.7 lscan.py -S /tmp/sig -f /tmp/FLIRTTarget /tmp/sig/fromidb.sig 4358/2803 (155.48%) /tmp/sig/libcrypto_arm.sig 107955/4771 (2262.73%) /tmp/sig/libssl_arm.sig 247/600 (41.17%) |
The preceding output shows that lscan has bugs because some match percentages even exceed 100%, for which I did not waste time to find out the cause.
4 rizzo
Signatures that FLIRT uses to identify functions are mainly machine code sequences. However, machine code sequences of static library functions can be very tricky because of different compilers, compilation options, and source code versions used. For this reason, Craig Heffner proposed a heuristic method[8] for function identification. To identify a function, the method checks the following items:
a. Reference to unique strings
b. Reference to unique constants
c. CFG
d) …
Compilers, compilation options, and source code versions have a minor impact on these check items.
The workflow of rizzo is as follows:
IDB A -> RIZ -> IDB B
Both rizzo and IDB2PAT rely on IDB to implement file identification. First, use rizzo to export a .riz file from IDB A. This file is equivalent to the .sig file in FLIRT. Then, use rizzo again to import the .riz file into IDB B. This operation is equivalent to applying the signature file.
For example, use IDA to disassemble a static library libsome.a and use rizzo to export some.riz. Next, use IDA to disassemble an ELF file that you suspect to link libsome.a. Finally, use rizzo to import some.riz.
rizzo.py is an IDA plug-in. To use it for file identification, just copy it to the IDA plugins directory and restart IDA.
Export a .riz file:
File > Produce file > rizzo signature file
Load the .riz file:
File > Load file > rizzo signature file
If the two entries are missing, the plug-in has some bug.
It does not matter where you put .riz files. They can be in any other directories besides the <IDA PATH>\sig\<arch>\ directory.
5 Use of IDC for Symbol Porting
If two IDB files map the same ELF file, you can migrate symbols, constructs, and comments by exporting IDC files.
Export an .idc file:
File > Produce file > Dump database to IDC file
Edit some.idc, modify main(), and retain only functions related to Bytes() and Functions().
Load the .idc file:
File > Load file > Additional binary file
6 syms2elf[10]
Assume that you used IDA to analyze a stripped ELF file and then used FLIRT or rizzo to rename a batch of functions. Now you use syms2elf to generate a new ELF file containing symbol information. When IDA disassembles and GDB debugs the new ELF file, symbols in the file take effect automatically. To use syms2elf, copy syms2elf.py to the IDA plugins directory and restart IDA. This tool is applicable to IDA 6.95 through 7.2 on either the x86 or x64 architecture.
Edit > Plugins > sym2elf
Assume that FLIRTTarget is the original ELF file and FLIRTTarget_new is the new ELF file:
| 1 2 3 4 5 6 7 | $ file -b FLIRTTarget ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped $ file -b FLIRTTarget_new ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, not stripped $ nm -C FLIRTTarget_new | grep Private |
The nm line shows that the new ELF file already contains the renamed function.
| 1 | $ nm -C FLIRTTarget_new | grep sub_ |
syms2elf takes “sub_…” as a valid function name and writes it to the new ELF file. In fact, this should not be written into the ELF file.
Use objcopy to export the symbol file from the new ELF file:
| 1 | $ objcopy --only-keep-debug FLIRTTarget_new FLIRTTarget_new.sym |
Obviously, syms2elf is applicable only to binaries of the ELF format and cannot be used for raw firmware.
When generating a new ELF file, syms2elf attempts to find the original ELF file. If this file is not in the expected directory, this operation will fail.
Check the path of a binary file:
idaapi.get_input_file_path()
Change the path of the binary file:
idaapi.set_root_filename( “…” )
Change the path to a relative path, for example, retain only the ELF file name, with the directory structure omitted, to put the ELF file in the same directory as IDB.
7 Static Library
FLIRT and rizzo both rely on a static library of high match percentage. Only with such a library, can SIG or RIZ files be generated. Generally, you can hardly know which static libraries are used in an ELF file that is being analyzed, let alone the static library file used during compilation. If lucky enough, you can find some strings in the ELF file.
| 1 2 3 4 5 6 | $ file -b FLIRTTarget ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped $ strings -n 5 FLIRTTarget | grep -i gcc | sort -u GCC_3.5 libgcc_s.so.1 |
This may be because GCC 3.5 was used during FLIRTTarget compilation. If the ldd utility is unavailable in the current environment, you can check dynamic libraries that the ELF file is dependent on as follows:
| 1 | $ LD_TRACE_LOADED_OBJECTS=1 ./FLIRTTarget |
FLIRTTarget may use an OpenSSL 1.0.1l static library (libcrypto.a) for ARM.
Run the following command to view symbols in libcrypto.a:
| 1 | $ nm -C libcrypto.a | grep RSA_new |
Run the following command to view the version number of libcrypto.a:
| 1 | $ strings -n 5 libcrypto.a | grep -E "^OpenSSL\s+[0-9]\." |
Conditions permitting, run the following command to find the version number and compilation options:
$ openssl version -a
Where can you find libcrypto.a used by FLIRTTarget?
7.1 Compilation of OpenSSL from Source Code
The version is openssl-1.0.1l.
Cross-compile the ARM version:
| 1 2 3 4 5 | [scz@ /tmp/arm]> tar xfz /tmp/openssl-1.0.1l.tar.gz [scz@ /tmp/arm/openssl-1.0.1l]> ./Configure --prefix=/usr/local --openssldir=/usr/local/openssl threads no-zlib no-shared linux-armv4 make CC=arm-gcc |
arm-gcc is provided here for illustration only. You should try to analyze FLIRTTarget, finding the most probable cross-compilation toolchain.
Only functions related to encryption algorithms, such as RSA_new(), are the concern. no-zlib indicates that zlib is not considered in the process; otherwise, you need to cross-compile zlib, which is a rather time-consuming job.
Compiling OpenSSL from source code is the last resort. Without knowing the compiler used and compilation options, you can only take a wild guess.
7.2 Generation of a SIG File
| 1 2 3 4 | $ nm -C libcrypto.a | grep RSA_new $ pelf libcrypto.a libcrypto_arm.pat $ sigmake -n"openssl-1.0.1l libcrypto.a for arm" libcrypto_arm.pat libcrypto_arm.sig libcrypto_arm.sig: modules/leaves: 497/595, COLLISIONS: 9 |
sigmake can hardly yield results in the first execution. You must manually handle .exc files to resolve collisions.
Execute sigmake again:
| 1 | $ sigmake -n"openssl-1.0.1l libcrypto.a for arm" libcrypto_arm.pat libcrypto_arm.sig |
Use zipsig to compress the .sig file to reduce the space usage. This step, however, is not required.
| 1 | $ zipsig libcrypto_arm.sig |
Use dumpsig to view the .sig file:
| 1 2 | $ dumpsig libcrypto_arm.sig libcrypto_arm.txt $ dumpsig -f -X libcrypto_arm.sig libcrypto_arm.txt |
dumpsig cannot reproduce the .pat file. In the irreversible process of generating a .sig file from a .pat file, some information is missing. Luckily, the .txt file generated by dumpsig contains signature bytes.
The newly generated .sig file should be saved in the <IDA PATH>\sig\<arch>\ directory.
Use IDA to disassemble libcrypto.a and rizzo to export libcrypto.riz.
7.3 SIG/RIZ Test
According to my personal experience, it is advisable to apply RIZ files first and then SIG files.
First, apply libcrypto.riz in FLIRTTarget.idb. The following information is identified:
| 1 | 00AF2A60 RSA_new |
However, functions following RSA_new in FLIRTTarget.idb fail to be identified. Now apply SIG files. First press Shift+F5 and then Ins to apply these files one by one:
| 1 2 3 | libcrypto_arm.sig libssl_arm.sig fromidb.sig |
It turns out that repeated application of SIG files can identify more functions. For example:
| 1 2 3 4 5 6 7 8 9 10 11 | File State #func Library name |
The second line indicates that 2403 functions are renamed during that round of applying libcrypto_arm.sig.
According to the rationale of the FLIRT technology, SIG files should be repeatedly applied until no new function is identified.
7.4 Others
During static linking, all functions in an .o file are linked to a binary. Assume that a function in an .o file is identified in FLIRTTarget.idb, and this function, together with other functions preceding and following it, probably reflects the layout of the .o file. If other functions are not renamed, you can manually check the file for these functions.
8 Community-maintained SIG Libraries vs SIG Files Compiled from Source Code
Some communities maintain SIG libraries[7], which, however, are hardly useful. According to my experience, a feasible method is to compile SIG/RIZ files from source code. These files have proved to be good enough to identify functions as expected.
9 IDA Signsrch[4]
| 1 2 3 4 5 6 7 | Tool for searching signatures inside files, extremely useful as help in reversing jobs like figuring or having an initial idea of what encryption/ compression algorithm is used for a proprietary protocol or file. It can recognize tons of compression, multimedia and encryption algorithms and many other things like known strings and anti-debugging code which can be also manually added since it’s all based on a text signature file read at run-time and easy to modify |
IDA Signsrch, which is applicable to IDA V7.2, functions like findcrypt.plw, but can identify more algorithms. To use this plug-in, copy IDA_Signsrch.plw, IDA_Signsrch.p64, signsrch.xml, IDA_Signsrch.dll, and IDA_Signsrch64.dll to the corresponding plugins directory of IDA and then restart IDA.
Edit > Plugins > Signsrch > Continue
Matching results are displayed in the “Signsrch matches” window.
You cannot say IDA Signsrch and findcrypt are unuseful. They just have very limited usage. Oftentimes, your own eyes (identifying signature constants) and Google together can do a better job.
10 Static Identification vs Dynamic Debugging
IDA is only one of many methods for static identification of encrypted functions. If dynamic debugging is possible, you can infer algorithms based on observation of in/out data and then verify your inference. The two methods can be used together to identify functions.
Decompilation
1 Snowman[2]
Snowman is similar to Hex-Rays, but not as half good as the latter. Even for the simple “Hello, World”, the decompilation result of Snowman is far from OK. The tool is claimed to support x86, x64, ARM, and ARM64. According to the developer, Snowman supports IDA through 7.0. In practice, it can also be used in IDA 7.2.
To use this plug-in, copy snowman.plw, snowman.p64, snowman.dll, and snowman64.dll to the corresponding plugins directory of IDA and then restart IDA. Press F3 at the cursor to display the C code of the current code. The window consists of two panes: assembly listing (left) and C/C++ code (right). You can select a code snippet from the left pane and then right-click the code and choose Decompile from the shortcut menu (or press Ctrl+E) to decompile the selected code. This operation, however, is not very meaningful.
2 HexRaysCodeXplorer[5]
To use this tool, copy HexRaysCodeXplorer.plw, HexRaysCodeXplorer.p64, HexRaysCodeXplorer32.dll, and HexRaysCodeXplorer64.dll to the corresponding plugins directory and then restart IDA.
This is a Hex-Rays plug-in, which can be selected for use through the shortcut menu in the decompilation window of Hex-Rays. When the plug-in takes effect, the following items appear on the shortcut menu:
| 1 | Display Ctree Graph |
HexRaysCodeXplorer supports structure customization in Local types (Shift+F1) via REconstruct Type. This is what the plug-in is most useful for. The procedure is as follows:
a. Select an object (structure) pointer in the decompilation window of Hex-Rays.
b. Choose Reset pointer type from the shortcut menu, or manually change the variable from the pointer type to an integer.
c. Choose REconstruct Type from the shortcut menu.
d. Check Local types (Shift+F1).
HexRaysCodeXplorer-2.1.zip is incompatible with the IDA 7.2 SDK and so cannot be used in IDA 7.2 currently.
Others
1) IdaRef[3]
The main function of IdaRef is to display in real time help information of an assembly instruction in the Instruction Reference window when you hover the mouse over the instruction. The plug-in supports x86, x64, ARM, and MIPS.
| 1 | | idaref.py | \---archs arm.sql mips32.sql x86-64.sql x86-64_old.sql xtensa.sql |
To use IdaRef, copy idaref.py and archs directories to the IDA plugins directory and restart IDA.
| 1 | Edit > idaref > Stop Idaref/Start Idaref |
This is a dispensable plug-in that is not of much use.
| 1 | Options > General > Disassembly > Auto comments |
The function provided by IdaRef is also available in IDA as long as you choose Auto comments.
References
[1] IDA F.L.I.R.T. Technology: In-Depth
https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml
[2] Snowman
https://github.com/yegord/snowman
[3] IdaRef
https://github.com/nologic/idaref
[4] IDA Signsrch
https://sourceforge.net/projects/idasignsrch/
[5] HexRaysCodeXplorer
https://github.com/REhints/HexRaysCodeXplorer
[6] IDB2PAT
https://github.com/fireeye/flare-ida/blob/master/python/flare/idb2pat.py
[7] lscan
https://github.com/maroueneboubakri/lscan
Community driven collection of IDA FLIRT signature
https://github.com/Maktm/FLIRTDB
https://github.com/push0ebp/sig-database
[8] https://github.com/devttys0/ida/tree/master/plugins/rizzo
A Code Signature Plugin for IDA – Craig [2014-10-11]
[10] syms2elf
