Live Stream VOD: BitRat Analysis (C++) - Part 3
Added 2022-10-30 03:11:19 +0000 UTCIn this twitch stream we conclude our three-part series on analyzing RitRat, a C++ RAT that is sold and generally used for eCrime activity but has also been linked to nation-stage backed targeted attacks.
The functionality of this RAT is fairly straight forward but its use of the C++ Standard Template Library makes reverse engineering a challenge. In this stream we finally setup the correct std::string type and our IDB magically begins to look like something readable... we then complete our analysis of the config encryption and build a static extractor in python.
Sample
Packed: 5e1ea26f5575e26857b209695de82207a04de0b0dc06f3645f776cc628440c46 [Malware Bazaar]
Unpacked 91e994fe2f5d97c9c7a8267ac900bd08d66c6e997397d01ccd15c0b301d98ea3 [Malshare]
Notes
Comments
lol
Khải Phan Quang
2022-12-12 15:01:59 +0000 UTCThank you!! We def got messed up by setting the wrong argument type in some of string function prototypes ... this propagated to cause most of the pain. As you saw the union was also an issue but not as big an issue as me just getting the struct def wrong lol! I'll try a few of these in our next stream and see what happens. Please keep these coming they are extremely helpful!
OALABS
2022-11-02 23:53:17 +0000 UTChihih, in that case here is some more ramble. Tip #1 in decompiler code when a std::string buffer is accessed it may get messy and confusing because of the union, there will be different parts of code to load the const char pointer, you should always set the destination resulting variable to const char* and the src to the actual union type, use ALT+Y to choose the appropriate union selection. Tip #2 another point is that a pointer to a std::string can be confused with a point to the buffer since its the same thing(first to first element of struct) so look carefully at the usage before deciding to set the resulting type to const char* or std::string* Tip #3 as you have already seen, arrays/structure on the stack can make life extremely difficult if you get it wrong :-D so here is my stratergy to prevent this: 1. locate all stack variables that are passed as pointers to other functions inside the current function you are working on. 2. you can now almost safely assume that these stack variables are the start of some fixed type. I call this list of stack vars my safe list. 3. look inside the other functions where each var from the safe list is used, try to figure out the size of them from how they are accessed. 4. now you have a rough idea of the size of each of these and you can start to define them as arrays/structs in your current function. example: function omg_dont_break_me { dd var 1 dd var 2 dd var 3 dd var 4 dd var 5 dd var 6 dd var 7 call blah(&var2) call blah(&var5) } exmaple: we examine the blah function and find out the pointer is accessed as 2 dwords now we can create struct SomeThingForBlah { DWORD x; DWORD y; } and start adding our stack types dd var 1 SomeThingForBlah blah1; dd var 4 SomeThingForBlah blah2; dd var 7 this way you are less likely to overlap something Tip #4 always set correct types in structs for every element struct MyCoolClass_VTABLE { void (blahf1*)(MyCoolClass*) -> MyCoolClass_Function_01; void (blahf2*)(MyCoolClass*) -> MyCoolClass_Function_02; } struct MyCoolClass { MyCoolClass_VTABLE* v; DWORD unknown_for_now_padding_01; DWORD unknown_for_now_padding_02; } void blahf1(MyCoolClass* this); etc Tip #5 if you know a type of variable is const then add the const keyword to the type, it can dramatically alter the way the decompiler optimises the output and makes it easier to read, for example some obfuscation tricks can also be removed by patching types as const i mostly do this stuff manually by hand because i enjoy it and consider the exploration part of the reversing process however it would be great if certain plugins could help, ive written scripts to assist me in this and i would be interested what the state of current plugins are to help, i havent looked at them for a while. ... that being said i am 80% in process of moving away from IDA and transferring my process into binja. end of ramble (-:
Robert Yates
2022-11-01 17:38:36 +0000 UTCP.S. Ramble more! This was actually very helpful!
OALABS
2022-11-01 17:03:40 +0000 UTCFreestyling RE! I like it! Thanks for the tips, I've noted them and you may see them on stream soon! I plan on doing a C++ "what have we learned" stream this week where we take a look at some of the basics again.
OALABS
2022-11-01 17:03:33 +0000 UTCCould of rescued your idb by resetting the function vars, https://hex-rays.com/blog/igors-tip-of-the-week-102-resetting-decompiler-information/ i enjoyed this journey :) hope in the future you will show of your awesome new collection of structs after taking some time to compile your own c++ stuff and decompile it. msvc std strings are easy to spot since they have an initial max(field is infact named capacity) value of 0xF, before the data is accessed anywhere you will see a check for >= 0x10 so that it can decide to deference the data pointer or use the mini 0xF buffer at the start. anyway like i said i enjoyed the journey, its cool to watch others explore and test out stuff, the best things are learnt this way. i offically name these kind of streams "freestyling RE" :-p thx for taking the time and effort to backtrack on the idbs and improve on stuff even though the viewership is low for such streams, at least i appreciate it (-: somewhere i have some old scripts i wrote for vtables, it creates the class structure and the vtable structure for it, but it also names all the pointers in table with the class name and function number and sets the prototype of the functions in the vtable correctly and additionally sets the first variable in the functions to "this" with the type of the class, that way it indirect vtable calls decompile nicely, i will have to try and dig it out one time but it would be also fun to to watch you create your own vtable solutions :) afaik current tools dont set function pointer types in the vtables or modify arguments. ok im rambling and my comment keeps getting longer, im done (-:
Robert Yates
2022-11-01 01:12:02 +0000 UTC
