Ida hexrays8/24/2023 msdn segment stores the argument descriptions as shown in Figure 4. This only impacts the IDA database file and does not modify the original binary.įigure 3: The additional segment added to the IDA database msdn segment the plug-in creates in order to store argument descriptions. In order to identify addresses of instructions that position arguments prior to a function call, the plug-in relies on IDA Pro’s markup.įigure 3 shows the additional. It shows how a descriptive comment is added to each API function call. An example of an annotated import table is depicted in Figure 2. For every function reference in the import table, the plug-in annotates the function’s description and return value, adds argument descriptions, and renames constants. It relies on an offline database generated from the MSDN documentation and IDA Pro type library (TIL) files. The plug-in is designed to run once on a sample before you start your analysis. This file gets stored in the same directory as the current database and can be used to revert to the previous markup in case you do not like the changes or something goes wrong. ![]() And in the bottom image, you can see how hovering over dwShareMode, the automatically renamed constant displays descriptive information.įigure 1: Hovering function names, arguments and constants displays the respective descriptions How it worksīefore the plug-in makes any changes to the disassembly, it creates a backup of the current IDA database file (IDB). In the middle image, hovering over the hTemplateFile argument displays the corresponding description. The top image shows how hovering over the CreateFileA function displays a short description and the return value. In Figure 1 you can see how the plug-in enables you to display function, argument, and constant information right within the disassembly. Table 1: Automatic labelling of standard symbolic constants Additionally, each function argument is renamed to a unique name, so the corresponding description can be added to the disassembly. In this example, 40000000h was automatically converted to GENERIC_WRITE. The most obvious change is that constants are renamed automatically. The right side of Table 1 shows the result of executing our plug-in showing the support it offers to an analyst. To obtain readable constant values, an analyst would be required to research the respective argument, import the corresponding standard enumeration into IDA and then manually rename each value. Normally an analyst would have to look up function, argument and possibly constant descriptions in the documentation to understand what this code snippet is trying to accomplish. On the left you can see IDA Pro’s standard disassembly: seven arguments get pushed onto the stack and then the CreateFileA function is called. Table 1 shows what benefit the plug-in provides to an analyst. The plug-in relies on an offline XML database file, which is generated from Microsoft’s documentation and IDA type library files. Additionally, the plug-in is able to automatically rename constants, which further speeds up the analyst workflow. This allows the information to be integrated as seamlessly as possible. The MSDN Annotations plug-in integrates information about functions, arguments and return values into IDA Pro’s disassembly listing in the form of IDA comments. In this blog post we will release a script that does just that, and we will show you how to use it. Frequently switching to the developer documentation can interrupt the reverse engineering process, so we thought about ways to integrate MSDN information into IDA Pro automatically. ![]() While analyzing malware samples with the team, I realized that a lot of time is spent looking up information about functions, arguments, and constants at the Microsoft Developer Network (MSDN) website. Motivationĭuring my summer internship with the FLARE team, my goal was to develop IDAPython plug-ins that speed up the reverse engineering workflow in IDA Pro. We hope you find all these scripts as useful as we do. As always, you can download these scripts at the following location. We started this blog series with a script for Automatic Recovery of Constructed Strings in Malware. ![]() The FireEye Labs Advanced Reverse Engineering (FLARE) Team continues to share knowledge and tools with the community.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |