I've a X64 DLL file which uses C++ standard library heavily. I've loaded the PDB symbol file in IDA and all the subroutines names sub_xxyz changes to std::xyz, which is as expected. But there are many subroutines, for example one name is like std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string<char,std::char_traits<char>,std::allocator<char>>(void *Dst, _BYTE *a2, __int64 a3). Too long, isn't it ;)

Under the hood, all these subroutines mainly do some memory manipulation with malloc(), memcpy(), memmove() etc. Hence my question, Can I simplify those subroutines in IDA by any means?


Although this function name is indeed quite long, there's no easy way to simplify it nor is it too difficult to understand once you gain decent C++ development experience, using std especially. The TLDR answer is that this is a constructor for a std::string object (specifically this looks like the substring(3) constructor, but I'm not 100% sure).

If you visit the std::string reference page, you'll see this is the definition for std::string:

typedef std::basic_string<char> string; 

The std::string class is being defined using the std::basic_string class template, which has three template parameters:

  1. the character type used for the string object.
  2. an object to control some string traits.
  3. The allocator used to actually allocate the string buffers for the class.

In the std::string case, however, only the first template parameter is provided - the other two are the default ones defined based on the first template parameter (char), and although they can be replaced with different or more complex traits or allocators, this isn't the case for the std::string class.

Although the typedef string is pretty simple and straightforward thanks to the default templates parameters being unspecified, when the object is built and actually defined by the compiler the full definition is used, which adds a lot of boilerplate definitions.

If we split it up to it's parts, we'll see std::basic_string is being used and three template parameters are specified. As mentioned for the std::string, the second (std::char_traits<char>) and third (std::allocator<char>) are derived by the first and are both templates by themselves, receiving the same template parameter std::basic_string got (char).

After the class definition, the two colons indicate a definition of an object under the class namespace:

::basic_string<char,std::char_traits<char>,std::allocator<char>>(void *Dst, _BYTE *a2, __int64 a3)

We can easily see this is a function that has the same name as the class itself, which is the known way to define a constructor.

Lastly, as with every function we have the parameters this function accepts inside the parentheses:

void *Dst, _BYTE *a2, __int64 a3

To simplify the full definition back to std::basic_string<char>, one would need to hold the default template parameters for all std template classes, and strip the ones that are recognized as the default ones. Although this is not a very difficult task, it seems a little redundant to me. You are obviously encouraged to either develop such a plugin yourself or suggest the feature improvement to the IDA development team.

| improve this answer | |
  • @Biswapriyo The last paragraph discusses the task of actually simplifying those names but as mentioned I personally find it redundant. – NirIzr Jun 5 '18 at 21:50
  • @Nirlzr: may be a worthwhile endeavor parsing the for typedef occurrences that are specializations of the standard containers and use an IDAPython script or plugin to make the names more readable. But yeah, it looks kind of like a tedious task. It'd probably require some proper C++ parser like libclang in the first place. – 0xC0000022L Jun 5 '18 at 21:53
  • @0xC0000022L Not sure about the c++ parsing, because these function names are not really free strings but compiler-mangled names. There are slight variations between compilers (which IDA already support, obviously) but basically I think it is structured enough for you to not need a actual C++ parsing, at least on the plugin's side. I believe you could also scrape some DBs or websites to get the default values without doing any c++ parsing either. YMMV and I didn't go into details because I don't thing anybody should be wasting their time on that, tbh. – NirIzr Jun 5 '18 at 21:58
  • @Biswapriyo I also went into details in here for anyone that is not familiar with the std and has trouble reading the function names. Goal was not to explain that one name you provided but show how std/template names are built and how they should be interpreted by the unfamiliar reader. – NirIzr Jun 5 '18 at 21:59
  • @NirIzr: I was referring to the part where one sifts through the STL headers, looking for typedef instances that look akin to typedef basic_string<wchar_t> wstring for any number of container classes. Because that's where the short names come from (std::string, std::wstring etc) and where the defaults will be known (provided you can parse C++). With libclang it's really a lot easier than it used to be (e.g. trying to parse the XML AST output from GCC). – 0xC0000022L Jun 5 '18 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.