-
Notifications
You must be signed in to change notification settings - Fork 73
Home
IFL stands for "Interactive Functions List". It is a small plugin created to provide an alternative, enhanced view of the list of functions. The main goal of this utility is to make navigating code faster and easier. In addition, it allows to load the outputs from other author's tools into the IDA view.
IFL is recommended to be used as a side view. It lists all the functions defined in IDA, including: their beginning/end, name, returned type, arguments, x-references from and to the function, and the flag indicating if the function is an import.
All the addresses (marked blue on the picture) are clickable, and will move us directly to the specific address in the code view. The functions names (yellow/orange on the picture) are editable - and help renaming each function very quickly.

The plugin allows us to sort the functions by particular criteria, and to apply filters. We can search for a function, using i.e. its start, fragment of the name, or a regular expression.

IFL maximally shortens the time to find where our function of interest was used, and lets us browse through all there places click by click.

It also lets us find all the dependencies of our function, and navigate through all other functions that it calls.
,.
The names of the functions can be exported to an external list.

The exported list has a simple format - comma separated in case of CSV, and ';' separated in case of TAG:
[RVA];[name]It allows to store the list of functions from the sample in a text-based form that is easy to share, and independent of particular database type. TAG can also be imported into PE-bear tool and to other disassemblers/debuggers.
Just as IFL allows to export functions names into CSV or TAG format, it can also allow to import the same formats back into IDA.
By clicking the button "Load names" you get access to several types that can be loaded.

By loading CSV or TAG into our IDB, we can quickly apply functions' names, or set comments in the code. It enables sharing information across various different tools. Additionally, the .IMPORTS.TXT format allow to load resolved lists of imported functions, with the help of which we can add a custom, external IAT to the shellcode dumped from memory.
TAG is a simple, custom format used for commenting disassembly. It is generated by tools of the same author, such as PE-sieve, TinyTracer, and PE-bear. It can be used by multiple other tools, with the help of appropriate plugins.
- In PE-bear, that is a PE editor with simple disassembler, TAG is used mainly to store comments set in the code.
- In PE-sieve, that scans process memory for implants and modifications, TAG format serves to describe the detected patches (more details here). Loading the TAGs into IDA allows to easily pinpoint the listed modifications, and analyze them in context of the full binary.
- In TinyTracer, that is a tool for tracing code execution, TAG is the main format of the output. Each called API, or other event of interest, is logged alongside the RVA of its occuring. By loading the TAGs into IDA we can get a better insights into an obfuscated code. For example, it helps us label functions that are resolved on fly. Details are described at Tiny Tracer's Wiki
Example - The visible comments in the code, describing called APIs, and transitions between different sections, come from the TinyTracer's tracelog loaded with the help of IFL:

Aforementioned tool, PE-sieve, allows to dump implanted code from the memory of the process. Sometimes the implant takes form of a PE. In such case, any additional, dynamic IAT can be reconstructed and appended to the existing Import Table of the PE format.
But sometimes the implant is a standalone shellcode, without any headers. In such case, while we can dump the blob of code, the relevant information about the imported APIs will be missing. If we open the dumped code in IDA, the functions that were resolved in memory will no longer be mapped to their names.
To deal with such situation, PE-sieve creates an additional report, .imports.txt. This report can be then loaded into IDA with the help of IFL, to enhance the view. Once we apply it on our loaded shellcode, all the imports get resolved and look as if they were coming from an Import Table.
It is ilustrated by the following video:
https://www.youtube.com/watch?v=9xM6BmH8CN0
IFL is a lightweight utility for day-to-day use that can be especially helpful in analyzing malware. It lets us quickly pinpoint the important functions, browse all the places in code where they are used, as well as to see their dependencies. It can also help enriching your IDA database with information obtained from other tools, or to export the information from IDB and share it in a simple, tool-agnostic way.
IFL is available on Github: https://github.com/hasherezade/ida_ifl