1 00:00:00,083 --> 00:00:02,626 MARION MARSCHALEK: Hello. 2 00:00:02,626 --> 00:00:05,209 Welcome to my talk about the thorny piece of malware. 3 00:00:05,209 --> 00:00:06,334 My name is Marion. 4 00:00:06,334 --> 00:00:07,667 I'm a malware analyst. 5 00:00:07,751 --> 00:00:09,751 I'm sparing my second name in because people seem 6 00:00:09,751 --> 00:00:12,209 to have problems pronouncing it anyway. 7 00:00:12,751 --> 00:00:14,959 And I work for the Austrian software company 8 00:00:14,959 --> 00:00:17,375 Ikarus Security Software. 9 00:00:18,918 --> 00:00:22,083 My talk is going to be about one specifically thorny piece 10 00:00:22,083 --> 00:00:26,501 of malware I analyzed, and I'm going to start out with some fancy fun facts 11 00:00:26,501 --> 00:00:28,542 about that sample. 12 00:00:28,667 --> 00:00:31,042 And the rest of the talk is all going to be about analyzed issues I had when 13 00:00:31,042 --> 00:00:32,834 looking into it. 14 00:00:32,999 --> 00:00:35,334 I'm going to bring two analyst techniques 15 00:00:35,334 --> 00:00:38,999 I encountered in the sample and two more analyst headaches that 16 00:00:38,999 --> 00:00:42,501 still provide problem for reverse engineers. 17 00:00:43,667 --> 00:00:46,999 First one that is exception handling that cannot 18 00:00:46,999 --> 00:00:48,999 execution path. 19 00:00:48,999 --> 00:00:50,918 And the second one is junk code that I encountered 20 00:00:50,918 --> 00:00:54,167 in there that was pretty nasty at first pass, but then you needed 21 00:00:54,167 --> 00:00:56,292 to pass by after all. 22 00:00:56,292 --> 00:00:59,000 I'm going to talk about binary analyzes 23 00:00:59,000 --> 00:01:03,999 of C++ executables and about multi threaded applications 24 00:01:03,999 --> 00:01:06,999 for reverse engineering. 25 00:01:06,999 --> 00:01:07,999 All right. 26 00:01:08,334 --> 00:01:09,542 Let's start over. 27 00:01:09,542 --> 00:01:12,876 Now, all together, this is my favorite piece of malware. 28 00:01:12,876 --> 00:01:15,209 Now why would it be my favorite piece of malware? 29 00:01:15,209 --> 00:01:19,083 Well, I reversed it in and out from top to bottom, and I really had a lot of fun. 30 00:01:19,083 --> 00:01:22,125 It is a challenging piece of malware but not impossible to pass 31 00:01:22,125 --> 00:01:24,584 by even for beginners. 32 00:01:24,584 --> 00:01:28,083 It's not packed or encrypted but still provides enough interesting 33 00:01:28,083 --> 00:01:30,250 topics to research. 34 00:01:30,292 --> 00:01:32,334 But what does it do after all? 35 00:01:32,334 --> 00:01:36,834 Well, all together, I summarize it there. 36 00:01:36,834 --> 00:01:41,083 It's an Asian multi threaded, non polymorphic, file infecting spy bot. 37 00:01:41,083 --> 00:01:42,250 What does it do? 38 00:01:42,250 --> 00:01:45,292 Like what spy bots do, it can produce screen shots. 39 00:01:45,292 --> 00:01:48,292 It can produce screen captures and send them to C & C server. 40 00:01:48,292 --> 00:01:49,375 It can delete files. 41 00:01:49,375 --> 00:01:50,375 It can copy files. 42 00:01:50,375 --> 00:01:52,125 It can execute files. 43 00:01:52,125 --> 00:01:54,876 Most of all, it can update so it can download 44 00:01:54,876 --> 00:01:59,083 a new version of itself and execute this one. 45 00:01:59,334 --> 00:02:04,375 So basically it can do anything the mode of control wants to. 46 00:02:05,959 --> 00:02:07,292 Anyway. 47 00:02:07,292 --> 00:02:09,667 What are interesting facts about it? 48 00:02:09,751 --> 00:02:11,918 The sample uses structured exception handling 49 00:02:11,918 --> 00:02:14,751 to obfuscate its execution part. 50 00:02:14,999 --> 00:02:17,626 That means by throwing deliberate exceptions, 51 00:02:17,626 --> 00:02:21,918 the malware author can pass execution control from one place in executable 52 00:02:21,918 --> 00:02:25,375 to another one, namely the exception handler. 53 00:02:25,375 --> 00:02:27,292 And the interesting thing about exception handlers 54 00:02:27,292 --> 00:02:30,334 is an exception handler can find a new entry point that's going 55 00:02:30,334 --> 00:02:33,083 to be executed after the encryption. 56 00:02:33,626 --> 00:02:34,999 How does this work? 57 00:02:34,999 --> 00:02:38,626 Well, the documentation I could find still was written in 1997 58 00:02:38,626 --> 00:02:41,584 by a guy called Matt Pietrik. 59 00:02:41,584 --> 00:02:46,125 He's one of my big heros now because he did already did recognize 60 00:02:46,125 --> 00:02:51,542 documentation this issue, namely, A Crash Course on the Depths 61 00:02:51,542 --> 00:02:55,459 of were committed of this article. 62 00:02:55,792 --> 00:02:58,999 Actually, exception handling is implemented as a chain 63 00:02:58,999 --> 00:03:02,792 of exception handlers which is located on stack and intertwined 64 00:03:02,792 --> 00:03:06,999 with the functions that frames that are around there. 65 00:03:06,999 --> 00:03:09,083 And it all starts with the thread formation book 66 00:03:09,083 --> 00:03:13,792 because every thread has its own chain of exception handlers. 67 00:03:13,999 --> 00:03:16,999 A reverse engineer can find this through the FS register adopted 68 00:03:16,999 --> 00:03:19,999 0 which points to exception registration structure 69 00:03:19,999 --> 00:03:22,999 which looks more or less like this. 70 00:03:23,083 --> 00:03:25,709 And in some cases, structure contains a pointer 71 00:03:25,709 --> 00:03:29,999 to the handler which could eventually handle the thrown exception 72 00:03:29,999 --> 00:03:34,250 and a pointer which points to the previous registration block which 73 00:03:34,250 --> 00:03:39,751 looks like this and eventually, the chain, there comes a default handler and, well, 74 00:03:39,751 --> 00:03:41,334 minus one. 75 00:03:41,918 --> 00:03:42,999 All right. 76 00:03:42,999 --> 00:03:44,584 Now this is based on the stack. 77 00:03:44,584 --> 00:03:46,584 And in one of the function stack frames. 78 00:03:46,584 --> 00:03:50,083 And there's a whole science about building stack and unwinding 79 00:03:50,083 --> 00:03:55,292 the stack, but what's really interesting for a malware author is, of course, 80 00:03:55,292 --> 00:03:59,792 he can register his own exception handlers and deliberately throw 81 00:03:59,792 --> 00:04:03,209 exceptions and control like put point execution flow 82 00:04:03,209 --> 00:04:06,417 to some other piece in the code. 83 00:04:07,083 --> 00:04:09,667 Now, this looks more or less like this. 84 00:04:09,667 --> 00:04:13,626 If you're inside of a binary and can spot something like F:0 85 00:04:13,626 --> 00:04:18,250 and see the structure where a new exception handler is linked 86 00:04:18,250 --> 00:04:24,375 into the list, that most likely has to do with exception handling. 87 00:04:25,167 --> 00:04:27,999 Now I told you there's a pointer in there pointing 88 00:04:27,999 --> 00:04:31,918 to the handler code which would be the first switch to some other point 89 00:04:31,918 --> 00:04:34,584 in the executable for execution. 90 00:04:34,751 --> 00:04:38,125 And inside of this handler now, someone can change 91 00:04:38,125 --> 00:04:41,999 the execution flow to completely different point 92 00:04:41,999 --> 00:04:44,999 inside of the executable. 93 00:04:45,999 --> 00:04:48,792 The magic thing about this is an exception is treated 94 00:04:48,792 --> 00:04:52,125 as a software interrupt which means every time the exception occurs, 95 00:04:52,125 --> 00:04:54,999 the whole context structure of the file that's running 96 00:04:54,999 --> 00:04:57,334 is saved away and loaded back into the CPU when 97 00:04:57,334 --> 00:05:00,083 the exception handler is finished. 98 00:05:00,083 --> 00:05:02,083 And the interesting thing there is that someone can change this 99 00:05:02,083 --> 00:05:04,626 content structure and point the structure pointer somewhere 100 00:05:04,626 --> 00:05:06,501 completely different. 101 00:05:08,083 --> 00:05:11,125 So yeah, I know there's a lot of people in there getting excited when 102 00:05:11,125 --> 00:05:12,876 they hear they can point instruction 103 00:05:12,876 --> 00:05:14,709 pointers somewhere. 104 00:05:14,918 --> 00:05:15,999 Right. 105 00:05:15,999 --> 00:05:16,999 And I know today a lot of things have changed, 106 00:05:16,999 --> 00:05:19,083 especially concerning C++. 107 00:05:19,876 --> 00:05:23,667 And in Visual C++, it is based on structured exception handling 108 00:05:23,667 --> 00:05:25,918 I showed you before. 109 00:05:25,999 --> 00:05:29,999 But the things that have changed mainly is now every function has its 110 00:05:29,999 --> 00:05:31,999 own exception handler and uses 111 00:05:31,999 --> 00:05:36,167 a funcinfo structure which contains information about try blocks 112 00:05:36,167 --> 00:05:40,709 and cache blocks and I think I need to take a break. 113 00:05:44,667 --> 00:05:47,876 SPEAKER: You would be correct. 114 00:05:51,834 --> 00:05:55,999 (Applause) SPEAKER: We have a little tradition here at DEF CON. 115 00:05:55,999 --> 00:05:57,709 Let me tell you all about it. 116 00:05:57,709 --> 00:05:59,459 It involves AUDIENCE: Drinking. 117 00:05:59,459 --> 00:06:00,459 SPEAKER: Louder. 118 00:06:00,459 --> 00:06:01,709 AUDIENCE: Drinking. 119 00:06:01,709 --> 00:06:02,709 SPEAKER: Why? 120 00:06:05,834 --> 00:06:08,250 Why are we making her drink? 121 00:06:08,250 --> 00:06:09,709 AUDIENCE: First timer. 122 00:06:09,709 --> 00:06:11,999 SPEAKER: We need someone from the audience. 123 00:06:11,999 --> 00:06:14,999 Do we have any first timers here in the audience? 124 00:06:14,999 --> 00:06:16,083 No? 125 00:06:16,083 --> 00:06:17,292 So there really? 126 00:06:17,292 --> 00:06:18,584 Nobody is a first timer? 127 00:06:18,626 --> 00:06:19,626 None? 128 00:06:19,999 --> 00:06:21,209 Wait. 129 00:06:21,209 --> 00:06:22,209 Okay. 130 00:06:22,209 --> 00:06:23,834 Who's everybody pointing at? 131 00:06:23,834 --> 00:06:24,834 All right. 132 00:06:24,834 --> 00:06:25,834 Get up here. 133 00:06:27,167 --> 00:06:29,918 I can't believe this is the only guy. 134 00:06:29,918 --> 00:06:30,918 That's amazing. 135 00:06:30,918 --> 00:06:31,918 Cheers! 136 00:06:38,459 --> 00:06:40,501 Welcome to DEF CON! 137 00:07:00,667 --> 00:07:03,542 (Applause) SPEAKER: Have a good time. 138 00:07:03,999 --> 00:07:05,667 MARION MARSCHALEK: Thank you. 139 00:07:05,667 --> 00:07:06,667 Sheesh. 140 00:07:06,667 --> 00:07:07,999 SPEAKER: Where were you? 141 00:07:07,999 --> 00:07:09,918 MARION MARSCHALEK: Right there. 142 00:07:09,918 --> 00:07:10,918 Okay. 143 00:07:10,918 --> 00:07:11,918 Now where was I? 144 00:07:11,918 --> 00:07:12,918 All right. 145 00:07:12,918 --> 00:07:15,083 Visual C++ structured exception handling. 146 00:07:15,083 --> 00:07:16,999 It's still based sorry. 147 00:07:17,334 --> 00:07:20,209 (Coughing) (Laughing) It's still based on the principal 148 00:07:20,209 --> 00:07:23,584 of structured exception handling I showed you before, 149 00:07:23,584 --> 00:07:27,834 but now every function has its own dedicated exception handler which 150 00:07:27,834 --> 00:07:32,417 is compile generated and uses some structure called fun infrastructure that 151 00:07:32,417 --> 00:07:35,459 contains a lot of information, namely information 152 00:07:35,459 --> 00:07:38,999 for unwinding fun clips about try blocks and cache blocks 153 00:07:38,999 --> 00:07:42,209 and well, the pointers to the exception handlers that 154 00:07:42,209 --> 00:07:44,999 eventually handle exceptions. 155 00:07:45,125 --> 00:07:46,125 Right. 156 00:07:46,125 --> 00:07:48,999 There's that built in function code SEH frame handler, 157 00:07:48,999 --> 00:07:51,792 which this funcinfo structure is handed 158 00:07:51,792 --> 00:07:56,083 over to and then performs well, the matching exception handling 159 00:07:56,083 --> 00:07:59,999 to executed exception handlers, of course. 160 00:08:00,209 --> 00:08:02,167 And still, as I mentioned, the important thing there, 161 00:08:02,167 --> 00:08:05,584 the exception handler can define your entry point. 162 00:08:05,792 --> 00:08:08,709 Now, I pointed to a really nice diagram that we 163 00:08:08,709 --> 00:08:10,250 see here. 164 00:08:10,876 --> 00:08:11,876 Interesting. 165 00:08:11,876 --> 00:08:12,876 Right? 166 00:08:12,876 --> 00:08:15,999 Open RC is painted by Igar Sakinski, who did a lot of research 167 00:08:15,999 --> 00:08:19,083 on structured exception handling. 168 00:08:19,292 --> 00:08:22,667 And I've provided some scratchbook painting here to show you. 169 00:08:22,667 --> 00:08:25,292 It's really not pretty, but let's look through that. 170 00:08:25,292 --> 00:08:26,417 There is a pointer to the exception handler on the stack, 171 00:08:26,417 --> 00:08:29,751 right, that's the compile generated the exception handler. 172 00:08:29,751 --> 00:08:30,999 There's the SEH frame differential where 173 00:08:30,999 --> 00:08:33,375 the funcinfo structure ends up at. 174 00:08:34,375 --> 00:08:37,083 This pointer points to a try block map. 175 00:08:37,083 --> 00:08:39,999 The try block map points to a handler array. 176 00:08:39,999 --> 00:08:41,999 The handler array points to a handler offset which points 177 00:08:41,999 --> 00:08:43,999 down to a handler. 178 00:08:45,584 --> 00:08:47,167 You got the thought, right? 179 00:08:47,167 --> 00:08:50,542 Well, I provided some screen shots here, from IDA Pro. 180 00:08:50,667 --> 00:08:52,999 Let's get back to the bot. 181 00:08:52,999 --> 00:08:55,999 In practice, this would look like this. 182 00:08:55,999 --> 00:08:58,417 For example, there's a registration sequence. 183 00:08:58,417 --> 00:08:59,876 I hope people can read this. 184 00:08:59,876 --> 00:09:00,876 Maybe. 185 00:09:00,876 --> 00:09:01,876 I don't know. 186 00:09:01,876 --> 00:09:02,999 But there is the zero flying by and a new exception handler 187 00:09:02,999 --> 00:09:06,501 is registered at the beginning of the function. 188 00:09:06,626 --> 00:09:09,709 And sometime later, there's an exception happening. 189 00:09:09,709 --> 00:09:13,626 If you can read that call, this will almost never work, right? 190 00:09:13,626 --> 00:09:18,250 Because this memory address puts to ecx there is somewhat likely not 191 00:09:18,250 --> 00:09:20,250 to be valid. 192 00:09:20,334 --> 00:09:24,792 So there's the exception and there is the registered exception handler 193 00:09:24,792 --> 00:09:29,999 which causes the system to execute the co paginated handler. 194 00:09:29,999 --> 00:09:31,125 The other funcinfo structure is handed 195 00:09:31,125 --> 00:09:34,999 over to the SEH frame handler which then performs the magic. 196 00:09:35,083 --> 00:09:37,999 Let's look into this funcinfo structure. 197 00:09:38,167 --> 00:09:41,999 In this funcinfo structure, there's the values that Igor thankfully pointed 198 00:09:41,999 --> 00:09:43,999 out in his diagram. 199 00:09:44,250 --> 00:09:46,999 So there's the try block map and the handler array, and finally, 200 00:09:46,999 --> 00:09:50,751 the pointer to the handler that the user registered. 201 00:09:50,999 --> 00:09:54,209 So there's the user generated handler. 202 00:09:54,209 --> 00:09:59,417 And in there, you can find the offset to the entry point. 203 00:09:59,999 --> 00:10:02,709 If you have a look at the user generated handler, it 204 00:10:02,709 --> 00:10:05,999 is really obvious that this handler is just registered 205 00:10:05,999 --> 00:10:08,751 for obfuscation because there's nothing else 206 00:10:08,751 --> 00:10:10,751 happening there. 207 00:10:10,751 --> 00:10:13,334 Then setting of this offset for the entry point. 208 00:10:14,250 --> 00:10:15,501 Right. 209 00:10:15,501 --> 00:10:16,918 So much about exceptions. 210 00:10:16,918 --> 00:10:18,999 The second point, the junk code in the file. 211 00:10:19,417 --> 00:10:22,083 There was really quite a lot of junk code defined 212 00:10:22,083 --> 00:10:26,918 in the sample which is pretty scary for young analysts if you see a lot 213 00:10:26,918 --> 00:10:30,209 of source and a lot of shifting operations and a lot 214 00:10:30,209 --> 00:10:35,751 of loops that actually dump phony, any useful information in there. 215 00:10:35,959 --> 00:10:40,918 So I was kind of overwhelmed on this junk code until I found 216 00:10:40,918 --> 00:10:45,918 the principle of the junk code in my sample. 217 00:10:45,999 --> 00:10:49,876 There's a whole lot of research about junk code and binary pass. 218 00:10:49,876 --> 00:10:54,792 And principle of this junk code is pretty simple, opaque predicates. 219 00:10:54,999 --> 00:10:57,709 Now the opaque predicates is something that's just well, 220 00:10:57,709 --> 00:10:59,999 branch statement, it always returns true 221 00:10:59,999 --> 00:11:02,167 or always returns false. 222 00:11:02,167 --> 00:11:04,876 And so it's always going to be just executed one branch 223 00:11:04,876 --> 00:11:07,709 of the branches that there are. 224 00:11:07,709 --> 00:11:10,250 And the other branches gets the junk code. 225 00:11:10,709 --> 00:11:17,083 So well, in the sample analysis, it looks somewhat like this. 226 00:11:17,542 --> 00:11:20,292 On the right side, you see the first screen shot. 227 00:11:20,292 --> 00:11:22,876 On the left side, there's a simplified version. 228 00:11:22,876 --> 00:11:24,999 And if you think through that, the compare statement in yent 229 00:11:24,999 --> 00:11:28,918 is never going to produce any 0 flags, so the junk not 0 is always going 230 00:11:28,918 --> 00:11:31,125 to take the green branch. 231 00:11:31,626 --> 00:11:32,626 Right. 232 00:11:32,626 --> 00:11:33,918 You think that is simple? 233 00:11:34,125 --> 00:11:35,125 It's true. 234 00:11:35,125 --> 00:11:37,375 It was like this all throughout the sample. 235 00:11:37,375 --> 00:11:38,417 Was just as simple. 236 00:11:38,417 --> 00:11:39,918 So what did the analyst do? 237 00:11:40,999 --> 00:11:44,999 I just put the normal down and green branch for precedent. 238 00:11:45,501 --> 00:11:47,167 If you can see this graphics. 239 00:11:47,167 --> 00:11:48,167 I'm not sure. 240 00:11:48,167 --> 00:11:49,167 All right. 241 00:11:49,167 --> 00:11:49,999 So the yellow boxes are the productive code and 242 00:11:49,999 --> 00:11:52,626 the white boxes are just junk code. 243 00:11:52,667 --> 00:11:55,334 So this was really pretty simple to get by. 244 00:11:55,999 --> 00:11:57,751 NS headaches. 245 00:11:57,959 --> 00:12:00,334 I spend a lot of time with sample into the especially 246 00:12:00,334 --> 00:12:03,125 because of the threats in there. 247 00:12:03,501 --> 00:12:04,999 People have seen the movie Take Me to Hell, 248 00:12:04,999 --> 00:12:07,999 and that's what I've been through with that application. 249 00:12:09,334 --> 00:12:10,999 The author of the sample actually has 250 00:12:10,999 --> 00:12:13,999 all my respect because he produced this in C++. 251 00:12:14,083 --> 00:12:18,167 This is a simplified version of the threats that I found in there. 252 00:12:18,292 --> 00:12:21,999 There's actually a lot more, but it boils down basically 253 00:12:21,999 --> 00:12:26,999 to one threat that malicious, the whole instance, namely, the well, 254 00:12:26,999 --> 00:12:30,959 the bot instances that could start up in the system 255 00:12:30,959 --> 00:12:35,792 because eventually there's more than one file infected that could 256 00:12:35,792 --> 00:12:37,417 start up. 257 00:12:37,584 --> 00:12:39,083 Second threat, there was the file infector, 258 00:12:39,083 --> 00:12:42,501 always infecting processes that would start up. 259 00:12:42,709 --> 00:12:45,667 Of that machinery that would handle the sending side 260 00:12:45,667 --> 00:12:50,375 of the bot which could send messages and data to the C & C and on site, 261 00:12:50,375 --> 00:12:53,375 the receiving side of the bot. 262 00:12:53,375 --> 00:12:56,125 And, of course, the C & C command switching. 263 00:12:56,667 --> 00:12:59,375 Now how did I get to that information? 264 00:12:59,375 --> 00:13:03,375 That was pretty tricky and spent a lot of trial and error time in there. 265 00:13:03,584 --> 00:13:07,999 But actually what I did was in first steps, I realized that I have 266 00:13:07,999 --> 00:13:12,876 to spot the really interesting threats because there's a lot of timing, 267 00:13:12,876 --> 00:13:15,501 synchronization going on. 268 00:13:15,709 --> 00:13:19,083 After doing this, I had to spot the interface communication and 269 00:13:19,083 --> 00:13:22,167 the synchronization meters which actually told me a lot 270 00:13:22,167 --> 00:13:26,834 about what threats were about, by triggered by specific events. 271 00:13:27,209 --> 00:13:31,083 I will talk a little bit more about this pretty soon. 272 00:13:31,083 --> 00:13:33,209 In the first step, of course, I had to analyze somewhat 273 00:13:33,209 --> 00:13:36,417 the function base of the threats to really find out what they do, 274 00:13:36,417 --> 00:13:39,542 what information they generated and where this information would 275 00:13:39,542 --> 00:13:41,459 eventually flow to. 276 00:13:41,626 --> 00:13:43,918 Knowing all this, in the first step it could bring 277 00:13:43,918 --> 00:13:47,959 down this big picture of where is information generated? 278 00:13:47,959 --> 00:13:48,959 Which threat? 279 00:13:48,959 --> 00:13:50,834 Which thread, sorry accepted information, 280 00:13:50,834 --> 00:13:54,667 processes it and eventually takes any action. 281 00:13:54,667 --> 00:13:55,999 All right. 282 00:13:55,999 --> 00:13:59,751 So if you go back to that diagram, I found four different ME thoughts 283 00:13:59,751 --> 00:14:02,542 of synchronization in there which were events 284 00:14:02,542 --> 00:14:05,667 for triggering the file infector and for managing 285 00:14:05,667 --> 00:14:09,209 the different instances that were started. 286 00:14:09,334 --> 00:14:13,999 Threat messages which remain used at the receiving side of the bot. 287 00:14:14,083 --> 00:14:16,999 IA completion part which was used to manage the so you had 288 00:14:16,999 --> 00:14:19,918 the receiving side of the bot, the threat messages 289 00:14:19,918 --> 00:14:23,209 for the receiving side of the bot and the critical sections 290 00:14:23,209 --> 00:14:26,459 for data exchange between the threats. 291 00:14:26,542 --> 00:14:28,918 When I had that, I could paint the threats 292 00:14:28,918 --> 00:14:31,751 around the synchronization meters. 293 00:14:33,542 --> 00:14:34,876 All right. 294 00:14:34,876 --> 00:14:37,209 Now here comes the last nastiness for today. 295 00:14:37,334 --> 00:14:38,334 C++. 296 00:14:38,334 --> 00:14:40,083 All right. 297 00:14:40,083 --> 00:14:42,375 There's actually a lot about reversing C++. 298 00:14:42,375 --> 00:14:43,417 There's a whole science for people who are interested 299 00:14:43,417 --> 00:14:46,999 in that I collected a lot of links on that research on the last slide 300 00:14:46,999 --> 00:14:49,083 of this presentation. 301 00:14:49,626 --> 00:14:52,999 But I actually want to talk about our visual function calls. 302 00:14:53,250 --> 00:14:55,999 Our visual function calls are very interesting to reverse 303 00:14:55,999 --> 00:14:59,292 because they're indirect calls, and they're only fully determinable 304 00:14:59,292 --> 00:15:00,999 at one time. 305 00:15:01,542 --> 00:15:03,999 These simple multiple inheritance features C++, so one 306 00:15:03,999 --> 00:15:06,292 of these special function calls can actually call 307 00:15:06,292 --> 00:15:09,209 into several different meters at run time. 308 00:15:09,417 --> 00:15:14,083 They're translated using visual function tables which has a lot 309 00:15:14,083 --> 00:15:17,999 in reversing these sorts of binaries. 310 00:15:18,459 --> 00:15:21,083 I provided the an example here. 311 00:15:21,626 --> 00:15:24,999 In this example, there's a visual function table actually loaded 312 00:15:24,999 --> 00:15:27,125 into the register EX. 313 00:15:27,542 --> 00:15:29,709 And at offset 4 of the virtual function table, 314 00:15:29,709 --> 00:15:34,542 there's ME thought that's going to be called with this call station. 315 00:15:35,292 --> 00:15:37,999 That was really sort of the catch me if you can. 316 00:15:39,459 --> 00:15:43,209 Actually, I collected another sample from open RC and Igar Sakinski 317 00:15:43,209 --> 00:15:46,999 because he did a lot of research on this as well. 318 00:15:47,375 --> 00:15:53,667 Here's one Class A where there's two virtual functions defined in there. 319 00:15:54,125 --> 00:15:57,459 Underneath this class definition, you can see the myriad 320 00:15:57,459 --> 00:16:00,999 of Class A where there's a virtual function pointer actually 321 00:16:00,999 --> 00:16:03,999 pointing to the virtual function table of Class A. 322 00:16:03,999 --> 00:16:07,417 Now virtual function table is something that just class have 323 00:16:07,417 --> 00:16:10,999 to have virtual functions defined in there. 324 00:16:11,209 --> 00:16:12,542 All right. 325 00:16:12,542 --> 00:16:14,626 Here's the second Class B which also has really similar layer 326 00:16:14,626 --> 00:16:17,834 with two virtual functions defined in there. 327 00:16:17,999 --> 00:16:20,501 And another interesting thing is the Class C 328 00:16:20,501 --> 00:16:25,375 because Class C inherits Class A and Class B and implements one virtual 329 00:16:25,375 --> 00:16:27,334 function each. 330 00:16:27,667 --> 00:16:31,999 Now, I already have Class C somewhat bigger because as it inherits other 331 00:16:31,999 --> 00:16:35,542 classes, the testing includes their class layout and also 332 00:16:35,542 --> 00:16:40,959 the virtual functions pointers in there to the virtual function tables. 333 00:16:41,209 --> 00:16:44,709 These virtual function tables are now adapted to fit the needs of Class C 334 00:16:44,709 --> 00:16:49,167 and point to the actual function offsets that Class C implemented. 335 00:16:49,542 --> 00:16:50,999 All right. 336 00:16:50,999 --> 00:16:54,999 This is really dry to look at, at code. 337 00:16:55,125 --> 00:16:56,292 Back to business. 338 00:16:56,292 --> 00:16:57,709 Here's the C & C command switching function 339 00:16:57,709 --> 00:17:01,876 which is a really good example for virtual function calls. 340 00:17:01,918 --> 00:17:04,292 Under you see little yellow boxes. 341 00:17:04,292 --> 00:17:06,834 This is all memory allocation for objects that are going 342 00:17:06,834 --> 00:17:09,999 to be instantiated in the green boxes. 343 00:17:09,999 --> 00:17:14,167 And then you see one pink box which is the virtual function call which was 344 00:17:14,167 --> 00:17:18,083 actually used to call to the bot functions. 345 00:17:18,501 --> 00:17:20,999 The bot functions are implemented as direct classes 346 00:17:20,999 --> 00:17:23,667 for one bot action super class. 347 00:17:25,209 --> 00:17:29,999 And all had one function overloaded, sorry, implemented that was 348 00:17:29,999 --> 00:17:31,999 the bot action. 349 00:17:32,083 --> 00:17:34,459 Now here, another IDA Pro example 350 00:17:34,459 --> 00:17:37,709 with the move file object. 351 00:17:38,626 --> 00:17:41,667 Here in yellow you see the object instantiation. 352 00:17:41,667 --> 00:17:42,667 I'm sorry. 353 00:17:42,667 --> 00:17:45,459 The memory allocation where there's space reserved for the object that 354 00:17:45,459 --> 00:17:49,083 is going to be instantiated in the green box. 355 00:17:49,334 --> 00:17:52,167 And what you see there is a call to a constructer. 356 00:17:52,709 --> 00:17:57,209 Now this constructer actually has call into the super class constructer, 357 00:17:57,209 --> 00:18:00,167 as it work with direct objects. 358 00:18:00,667 --> 00:18:02,417 And there you see the first VFTable. 359 00:18:03,083 --> 00:18:05,250 I will talk about this in a second. 360 00:18:06,083 --> 00:18:08,083 As I mentioned, this constructer has call 361 00:18:08,083 --> 00:18:11,292 into the base class constructer, and there's another virtual function 362 00:18:11,292 --> 00:18:15,125 table where there is space reserved for two virtual functions. 363 00:18:15,334 --> 00:18:16,999 Now IDA Pro checked the cross reference 364 00:18:16,999 --> 00:18:19,334 of this base class constructer. 365 00:18:19,751 --> 00:18:23,083 There have 23 cross references, I guess, surprise, there's 366 00:18:23,083 --> 00:18:27,375 like 23 bot actions that can be taken by the bot. 367 00:18:27,876 --> 00:18:29,292 All right. 368 00:18:29,292 --> 00:18:34,417 Along this the final step is the call into the function ME bot 369 00:18:34,417 --> 00:18:37,709 of the new file object. 370 00:18:37,876 --> 00:18:40,501 What you see there is that the function table 371 00:18:40,501 --> 00:18:43,876 of the new file object is loaded into the register and 372 00:18:43,876 --> 00:18:46,751 the function offset is called if you have a look 373 00:18:46,751 --> 00:18:50,834 at the virtual function table of the new file object, the for there 374 00:18:50,834 --> 00:18:53,083 is move file function. 375 00:18:53,083 --> 00:18:55,334 So theory approved. 376 00:18:55,334 --> 00:18:57,999 Using these virtual function tables, you can not easily 377 00:18:57,999 --> 00:19:01,999 but pretty fast determine which functions are going to be called 378 00:19:01,999 --> 00:19:04,999 at these virtual function calls. 379 00:19:05,834 --> 00:19:07,459 All right. 380 00:19:08,167 --> 00:19:10,125 This was my presentation. 381 00:19:10,125 --> 00:19:11,959 Here are the promise to the links. 382 00:19:11,959 --> 00:19:16,751 The samples we found online and they're the first link. 383 00:19:16,751 --> 00:19:20,292 And while if there's any questions, you can contact me on Twitter 384 00:19:20,292 --> 00:19:24,250 or I'm going to be out in the hallway to answer your questions 385 00:19:24,250 --> 00:19:28,918 or receive critics or anything you want to tell me now. 386 00:19:28,999 --> 00:19:29,999 Thank you.