[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:05.08,0:00:10.10,Default,,0000,0000,0000,,Such a weird processor - messing with x86 opcodes... and a little bit of PE [Portable Executable]
Dialogue: 0,0:00:10.51,0:00:19.05,Default,,0000,0000,0000,,So welcome. ...And especially let me know if I speak too quickly. Um, so -- who I am -- oh, yes so
Dialogue: 0,0:00:19.05,0:00:28.02,Default,,0000,0000,0000,,I will talk about opcodes and a little bit about the PE [portable executable] file format and their oddities. So, I've been
Dialogue: 0,0:00:28.02,0:00:35.01,Default,,0000,0000,0000,,a reverse engineer for some years, for some time. I created a project called Corkami.
Dialogue: 0,0:00:35.01,0:00:42.04,Default,,0000,0000,0000,,Also in the past I worked on the MAME arcade emulator, and professionally I am a malware analyst, but
Dialogue: 0,0:00:42.04,0:00:48.54,Default,,0000,0000,0000,,this is only on the behalf of my hobbies, this is my own experiments and research at home.
Dialogue: 0,0:00:48.54,0:00:57.01,Default,,0000,0000,0000,,So, I introduced Corkami. Corkami is just the name of the project I created for RCE project.
Dialogue: 0,0:00:57.01,0:01:04.07,Default,,0000,0000,0000,,I tried to keep it just to the technical stuff, no ads, no login required.
Dialogue: 0,0:01:04.07,0:01:06.06,Default,,0000,0000,0000,,Really direct to the good stuff.
Dialogue: 0,0:01:06.06,0:01:12.04,Default,,0000,0000,0000,,I try to update it and make it useful, so I also created cheat sheets and the kind of easy documents
Dialogue: 0,0:01:12.04,0:01:15.08,Default,,0000,0000,0000,,that I would use for work on a daily basis,
Dialogue: 0,0:01:15.08,0:01:18.33,Default,,0000,0000,0000,,but it's only a hobby; I do that once the kids are asleep
Dialogue: 0,0:01:18.33,0:01:23.02,Default,,0000,0000,0000,,and late at night so it's probably doesn't look professional
Dialogue: 0,0:01:23.02,0:01:24.78,Default,,0000,0000,0000,,and as good as I would like it to be.
Dialogue: 0,0:01:24.78,0:01:30.97,Default,,0000,0000,0000,,So right now, Corkami, the form of Corkami, is wiki pages and cheat sheets
Dialogue: 0,0:01:30.97,0:01:37.98,Default,,0000,0000,0000,,and I focus on creating as many as possible relevant proof of concepts [Hi Bob!]
Dialogue: 0,0:01:37.98,0:01:43.09,Default,,0000,0000,0000,,so the binaries are hand-written, usually I don't use a compiler, I create the PE (structure) myself
Dialogue: 0,0:01:43.09,0:01:46.04,Default,,0000,0000,0000,,so that it's only focusing on the exact interesting point
Dialogue: 0,0:01:46.04,0:01:49.00,Default,,0000,0000,0000,,and you don't have a lot of noise even -- you don't probably
Dialogue: 0,0:01:49.00,0:01:51.04,Default,,0000,0000,0000,,need IDA to actually understand what's going on
Dialogue: 0,0:01:51.04,0:01:54.79,Default,,0000,0000,0000,,because I try to focus only on what's important.
Dialogue: 0,0:01:54.79,0:01:58.29,Default,,0000,0000,0000,,The binaries are all directly available to download so you can
Dialogue: 0,0:01:58.46,0:02:01.03,Default,,0000,0000,0000,,really test your debugger, your tools, your knowledge
Dialogue: 0,0:02:01.03,0:02:03.90,Default,,0000,0000,0000,,and just get them directly from that.
Dialogue: 0,0:02:03.90,0:02:07.07,Default,,0000,0000,0000,,So far, I've focused on the PDF, assembly and the PE..
Dialogue: 0,0:02:07.07,0:02:11.02,Default,,0000,0000,0000,,...file format. A few other stuff, but that's mainly the most
Dialogue: 0,0:02:11.02,0:02:15.01,Default,,0000,0000,0000,,covered subject of my website. And I share that with a
Dialogue: 0,0:02:15.01,0:02:19.08,Default,,0000,0000,0000,,very permissive license so BSD you can reuse them commercially
Dialogue: 0,0:02:19.08,0:02:24.78,Default,,0000,0000,0000,,whatever. Even the images are done in open-source format.
Dialogue: 0,0:02:25.40,0:02:29.51,Default,,0000,0000,0000,,So the story behind this presentation is that some time ago
Dialogue: 0,0:02:29.51,0:02:32.33,Default,,0000,0000,0000,,I was young and innocent and I thought that CPUs, being
Dialogue: 0,0:02:32.33,0:02:38.04,Default,,0000,0000,0000,,electronic - whatever - they had to be perfectly logical and no problems
Dialogue: 0,0:02:38.04,0:02:41.83,Default,,0000,0000,0000,,and then I was tricked by malware. And basically
Dialogue: 0,0:02:41.83,0:02:46.06,Default,,0000,0000,0000,,IDA wasn't able to work on it, so I decided to go back
Dialogue: 0,0:02:46.06,0:02:49.77,Default,,0000,0000,0000,,to the basics and study assembly and PE files from scratch.
Dialogue: 0,0:02:49.77,0:02:52.74,Default,,0000,0000,0000,,I created in the meantime documents on Corkami
Dialogue: 0,0:02:53.74,0:02:57.07,Default,,0000,0000,0000,,and now I'm presenting you more or less the final results.
Dialogue: 0,0:02:57.07,0:03:01.06,Default,,0000,0000,0000,,or the good programs results. If I wasn't -- if I was just a
Dialogue: 0,0:03:01.06,0:03:05.68,Default,,0000,0000,0000,,guy who learned assembly I probably wouldn't be in HashDays
Dialogue: 0,0:03:05.68,0:03:10.06,Default,,0000,0000,0000,,to talk about it, if I didn't get a few achievements from
Dialogue: 0,0:03:10.06,0:03:14.07,Default,,0000,0000,0000,,various tools. So basically I failed all the disassemblers that I tried
Dialogue: 0,0:03:14.07,0:03:21.01,Default,,0000,0000,0000,,and I also created a few crashes - in IDA. I insist that all
Dialogue: 0,0:03:21.01,0:03:26.01,Default,,0000,0000,0000,,the authors were notified and most of the bugs are already fixed, but
Dialogue: 0,0:03:26.01,0:03:30.69,Default,,0000,0000,0000,,basically it was like this in 6.1 -- you get a direct crash -- but
Dialogue: 0,0:03:30.69,0:03:33.03,Default,,0000,0000,0000,,now it's fixed in 6.2, and everything.
Dialogue: 0,0:03:33.03,0:03:37.05,Default,,0000,0000,0000,,And Hiew [Hacker's view] - that's the latest version - but the newest and released,
Dialogue: 0,0:03:37.05,0:03:40.37,Default,,0000,0000,0000,,- well, the newest beta - fixed that and so on.
Dialogue: 0,0:03:40.40,0:03:45.09,Default,,0000,0000,0000,,So the agenda for the presentation is that I first try with
Dialogue: 0,0:03:45.09,0:03:50.64,Default,,0000,0000,0000,,an easy introduction, but I assume that most of you already know or are familiar with disassembly, right?
Dialogue: 0,0:03:52.08,0:03:57.04,Default,,0000,0000,0000,,Yes. And another question: are you all familiar with
Dialogue: 0,0:03:57.56,0:04:02.58,Default,,0000,0000,0000,,or you already had an event of undocumented disassembly in your ... or never?
Dialogue: 0,0:04:02.58,0:04:05.80,Default,,0000,0000,0000,,Like, you trust IDA and that's all.
Dialogue: 0,0:04:06.60,0:04:10.55,Default,,0000,0000,0000,,Like, is it a common thing to have an undocumented disassembly in IDA?
Dialogue: 0,0:04:11.30,0:04:14.04,Default,,0000,0000,0000,,Raise you arms -- okay, not so much.
Dialogue: 0,0:04:14.04,0:04:19.62,Default,,0000,0000,0000,,Okay. So then after the introduction (that will go quickly),
Dialogue: 0,0:04:19.62,0:04:25.04,Default,,0000,0000,0000,,I will mention a few tricks, then introduce CoST, the program that I created.
Dialogue: 0,0:04:25.04,0:04:29.03,Default,,0000,0000,0000,,And I will also talk a little bit more about the PE file format.
Dialogue: 0,0:04:29.63,0:04:34.01,Default,,0000,0000,0000,,So as you all have assembly knowledge I will go quickly on that.
Dialogue: 0,0:04:34.01,0:04:37.49,Default,,0000,0000,0000,,So basically, you compile a binary, there is assembly, there is
Dialogue: 0,0:04:37.55,0:04:44.02,Default,,0000,0000,0000,,some relevance, some common points between the [source] code and the assembled [generated] code.
Dialogue: 0,0:04:44.02,0:04:48.49,Default,,0000,0000,0000,,Then of course there is a relation between the opcode and the [assembly] code, you all know that.
Dialogue: 0,0:04:49.06,0:04:53.06,Default,,0000,0000,0000,,What is important is that the assembly is generated by the compiler, but actually what is
Dialogue: 0,0:04:53.99,0:04:59.69,Default,,0000,0000,0000,,then from the assembly what is -- what's only kept in the binary are the opcodes itself which are understood
Dialogue: 0,0:04:59.69,0:05:03.28,Default,,0000,0000,0000,,directly by the CPU, which means the CPU just knows
Dialogue: 0,0:05:03.28,0:05:07.04,Default,,0000,0000,0000,,what to do with the bytes, it doesn't care if you or the
Dialogue: 0,0:05:07.04,0:05:10.58,Default,,0000,0000,0000,,tool you're using know what it will do, because it just does it.
Dialogue: 0,0:05:10.58,0:05:16.34,Default,,0000,0000,0000,,And the problem is that what we read is not usually the opcodes for most people but actually the disassembly
Dialogue: 0,0:05:16.34,0:05:20.64,Default,,0000,0000,0000,,and if the disassembler doesn't give you any result, well,
Dialogue: 0,0:05:20.64,0:05:25.41,Default,,0000,0000,0000,,we're stuck, we're blind, we don't know what execution will do.
Dialogue: 0,0:05:25.41,0:05:28.01,Default,,0000,0000,0000,,And the other problem is because of the opcode length you
Dialogue: 0,0:05:28.01,0:05:30.31,Default,,0000,0000,0000,,don't know what the next instruction will be because you
Dialogue: 0,0:05:30.31,0:05:32.03,Default,,0000,0000,0000,,don't know how to disassemble it.
Dialogue: 0,0:05:32.03,0:05:40.02,Default,,0000,0000,0000,,So, here I just create one undocumented opcode in a simple program.
Dialogue: 0,0:05:40.02,0:05:48.22,Default,,0000,0000,0000,,So basically we just '_emit' -- [it's] a keyword in -- that's Visual Studio 2010 ultimate --
Dialogue: 0,0:05:48.22,0:05:52.02,Default,,0000,0000,0000,,you will get a byte that is unidentified at disassembly
Dialogue: 0,0:05:52.02,0:05:58.100,Default,,0000,0000,0000,,so you get question marks, so basically this program
Dialogue: 0,0:05:58.100,0:06:01.08,Default,,0000,0000,0000,,even though it costs several thousand dollars is not able
Dialogue: 0,0:06:01.08,0:06:05.00,Default,,0000,0000,0000,,to -- it doesn't know what will happen.
Dialogue: 0,0:06:05.00,0:06:09.01,Default,,0000,0000,0000,,So usually if you do that... Oh, yeah, if you check the Intel documentation
Dialogue: 0,0:06:09.01,0:06:14.47,Default,,0000,0000,0000,,there is nothing to see at the D6 opcode, there is nothing to see there.
Dialogue: 0,0:06:14.47,0:06:17.64,Default,,0000,0000,0000,,Microsoft doesn't say anything, Intel doesn't say anything,
Dialogue: 0,0:06:17.64,0:06:21.01,Default,,0000,0000,0000,,so usually if you try that you could expect bad results.
Dialogue: 0,0:06:21.01,0:06:26.50,Default,,0000,0000,0000,,So, not documented, directly: usually it is a crash or not the expected result.
Dialogue: 0,0:06:26.50,0:06:29.50,Default,,0000,0000,0000,,But here, in this case, this specific case, no problem.
Dialogue: 0,0:06:29.90,0:06:35.28,Default,,0000,0000,0000,,We don't know what is was, if we follow Intel or Microsoft documentation, we don't know what happened.
Dialogue: 0,0:06:35.28,0:06:41.49,Default,,0000,0000,0000,,But if we -- the CPU just does its stuff. So what happened is that actually
Dialogue: 0,0:06:41.49,0:06:49.01,Default,,0000,0000,0000,,D6 is a very simple opcode, that doesn't do much, but somehow it's not documented by Intel
Dialogue: 0,0:06:49.01,0:06:53.57,Default,,0000,0000,0000,,[but] it's documented by AMD, and most of the opcodes are actually documented by AMD
Dialogue: 0,0:06:53.57,0:06:58.02,Default,,0000,0000,0000,,but not Intel. I don't know why, if anyone has any idea why...
Dialogue: 0,0:06:58.02,0:07:04.01,Default,,0000,0000,0000,,It's quite a trivial opcode, but it's not -- Intel still says there's nothing there. Okay.
Dialogue: 0,0:07:04.01,0:07:08.03,Default,,0000,0000,0000,,So it's commonly used, the common use for those undocumented opcodes are malware
Dialogue: 0,0:07:08.03,0:07:13.38,Default,,0000,0000,0000,,and packers, just to prevent automated analysis or easy reverse-engineering.
Dialogue: 0,0:07:14.32,0:07:22.37,Default,,0000,0000,0000,,What's funny is that, Intel, if you follow the documentation you will have many holes, but Intel's own disassembler,
Dialogue: 0,0:07:22.37,0:07:26.38,Default,,0000,0000,0000,,Xed, which is free of use, it is not open source, but just handles
Dialogue: 0,0:07:26.38,0:07:35.69,Default,,0000,0000,0000,,all these opcodes correctly, while Microsoft, and Visual Studio, and WinDBG, they follow blindly the documentation.
Dialogue: 0,0:07:35.69,0:07:42.65,Default,,0000,0000,0000,,So you will get question marks even though Intel knows perfectly what it does.
Dialogue: 0,0:07:43.01,0:07:51.52,Default,,0000,0000,0000,,So it's like "[...] do as I disassemble and don't read my documentation."
Dialogue: 0,0:07:52.03,0:08:00.69,Default,,0000,0000,0000,,So - of course - you could argue that WinDBG is only made to debug what the compiler,
Dialogue: 0,0:08:00.69,0:08:07.44,Default,,0000,0000,0000,,Microsoft compiler created, but then it kind of rules out WinDBG as a malware debugging tool,
Dialogue: 0,0:08:08.01,0:08:17.46,Default,,0000,0000,0000,,because you just inserted D6, it's trivial, and WinDBG is just not able to tell you what the instructions
Dialogue: 0,0:08:17.46,0:08:24.81,Default,,0000,0000,0000,,are. So it's not very useful for malware analysis -- for a malware analysis debugger
Dialogue: 0,0:08:25.06,0:08:32.97,Default,,0000,0000,0000,,So, another problem that happens is that of course each of the
Dialogue: 0,0:08:32.97,0:08:37.31,Default,,0000,0000,0000,,undocumented things, facts, are available, maybe one
Dialogue: 0,0:08:37.31,0:08:42.35,Default,,0000,0000,0000,,you will have in a trojan, one in a packer, and everything, but it's not so easy
Dialogue: 0,0:08:42.35,0:08:46.58,Default,,0000,0000,0000,,to find a good, exhaustive, clean test set to actually
Dialogue: 0,0:08:46.58,0:08:48.98,Default,,0000,0000,0000,,gather all these undocumented facts, so for example if you
Dialogue: 0,0:08:49.24,0:08:53.24,Default,,0000,0000,0000,,so, for example, someone says - a colleague - mentions an undocumented
Dialogue: 0,0:08:53.24,0:08:55.72,Default,,0000,0000,0000,,opcode or behaviour, and then you say "oh yeah, it's
Dialogue: 0,0:08:55.72,0:08:58.95,Default,,0000,0000,0000,,in MebRoot [MBR infector], or you skip this part of the file or whatever",
Dialogue: 0,0:08:58.95,0:09:03.47,Default,,0000,0000,0000,,and then you are actually, you know first it's a malware so you have -- you cannot
Dialogue: 0,0:09:03.47,0:09:08.06,Default,,0000,0000,0000,,really spread that, and then there is a lot of noise -- the malware payload or something before and
Dialogue: 0,0:09:08.06,0:09:15.01,Default,,0000,0000,0000,,after -- so it's not so easy to analyse. So that's why I focused on creating a small and clean test
Dialogue: 0,0:09:15.01,0:09:21.02,Default,,0000,0000,0000,,set that would actually provide --- insists just on one particular instruction or fact.
Dialogue: 0,0:09:22.20,0:09:27.56,Default,,0000,0000,0000,,So, now let's start, at last, the real stuff, and a few of the undocumented opcodes.
Dialogue: 0,0:09:28.03,0:09:36.86,Default,,0000,0000,0000,,But before I actually started [studying], [I was] wondering what the actual possibilities of the CPUs, I didn't even know
Dialogue: 0,0:09:36.86,0:09:44.46,Default,,0000,0000,0000,,what are the possibilities, what are the opcodes that are still supported or not by the -- by the CPU.
Dialogue: 0,0:09:44.46,0:09:52.02,Default,,0000,0000,0000,,And I think it's a bit like English, everybody, or most people in the world, would be able to read and
Dialogue: 0,0:09:52.02,0:09:57.41,Default,,0000,0000,0000,,understand these words, and if you['ve] see[n] some disassembly [before] then well you are used to seeing these opcodes,
Dialogue: 0,0:09:57.41,0:10:03.57,Default,,0000,0000,0000,,they are made by all the compilers and they are so common that if they are not here then we are a bit
Dialogue: 0,0:10:03.57,0:10:08.07,Default,,0000,0000,0000,,ill-at-ease, and if it's something different then we probably would be surprised.
Dialogue: 0,0:10:08.62,0:10:19.54,Default,,0000,0000,0000,,So this is standard English, but the Intel CPUs were made in the 70s, so it'd be the same as if you take
Dialogue: 0,0:10:19.54,0:10:27.07,Default,,0000,0000,0000,,Shakespearean English, so you could say that it's still English, but mmm... You know, I don't know what that means actually...
Dialogue: 0,0:10:27.07,0:10:30.05,Default,,0000,0000,0000,,or maybe I forgot, I quickly forgot at least, and it's a bit the same
Dialogue: 0,0:10:30.05,0:10:36.03,Default,,0000,0000,0000,,for those opcodes which are still supported by all the CPUs that we have -- all the Intel CPUs -- but
Dialogue: 0,0:10:36.03,0:10:41.10,Default,,0000,0000,0000,,we probably don't know what they actually do, and that's a problem.
Dialogue: 0,0:10:41.10,0:10:46.08,Default,,0000,0000,0000,,I actually made, one of the proof of concepts that I made was only using these old opcodes, and these
Dialogue: 0,0:10:46.08,0:10:53.02,Default,,0000,0000,0000,,old opcodes are actually doing something, so if someone is familiar with reading that, maybe I should
Dialogue: 0,0:10:53.02,0:10:59.07,Default,,0000,0000,0000,,ask "how old are you?", because myself I am used to the PUSH/JUMP/CALLs, but when it's about this,
Dialogue: 0,0:10:59.07,0:11:05.99,Default,,0000,0000,0000,,mmm... what is exactly being done. And it's still working on an i7, and it's still usable by malware,
Dialogue: 0,0:11:05.99,0:11:13.81,Default,,0000,0000,0000,,packers or anything, and yet some of them are -- totally unused now and they are still fully working on
Dialogue: 0,0:11:13.81,0:11:15.88,Default,,0000,0000,0000,,modern CPUs.
Dialogue: 0,0:11:15.88,0:11:21.43,Default,,0000,0000,0000,,And of course, it's a bit like English, it's an evolving language, and a bit like maybe the oldest generations
Dialogue: 0,0:11:21.43,0:11:27.49,Default,,0000,0000,0000,,of people -- of humans wouldn't be used to the buzzwords - the latest buzzwords.
Dialogue: 0,0:11:27.49,0:11:35.02,Default,,0000,0000,0000,,These opcodes are sometimes present in the most recent CPUs, so, and you have direct opcodes for
Dialogue: 0,0:11:35.02,0:11:41.27,Default,,0000,0000,0000,,CRC32 or AES decryption, string matching, and then some complex operation, in just one opcode.
Dialogue: 0,0:11:41.27,0:11:47.65,Default,,0000,0000,0000,,So this, this is possible, this exists in modern CPUs. Not all of them, of course.
Dialogue: 0,0:11:47.65,0:11:54.40,Default,,0000,0000,0000,,One thing that I like is the MOVBE -- move big endian -- opcode, because move big endian is the rejected
Dialogue: 0,0:11:54.40,0:12:01.92,Default,,0000,0000,0000,,offspring, it's only implemented in the Atom CPU, which means this netbook has -- supports this opcode
Dialogue: 0,0:12:01.92,0:12:09.04,Default,,0000,0000,0000,,and the i7 64-bit doesn't have this opcode, even though it will have CRC32 or maybe AES [op]code, so...
Dialogue: 0,0:12:09.04,0:12:12.05,Default,,0000,0000,0000,,so much for complete backward compatibility.
Dialogue: 0,0:12:12.05,0:12:20.03,Default,,0000,0000,0000,,There is no physical CPU as far as I know that can emulate -- execute CRC32 and MOVBE.
Dialogue: 0,0:12:20.03,0:12:24.08,Default,,0000,0000,0000,,And of course, MOVBE is quite meaningless itself because you already have an opcode for the big --
Dialogue: 0,0:12:24.08,0:12:32.00,Default,,0000,0000,0000,,endian-ness swapping. So I don't know, this small computer has an opcode that most PC's don't.
Dialogue: 0,0:12:32.00,0:12:35.02,Default,,0000,0000,0000,,Okay. Why? I don't know. If you know...
Dialogue: 0,0:12:35.02,0:12:37.59,Default,,0000,0000,0000,,[Audience member:] "Is this opcode documented in the CPU feature set?"
Dialogue: 0,0:12:37.59,0:12:38.09,Default,,0000,0000,0000,,Yeah.
Dialogue: 0,0:12:38.09,0:12:42.42,Default,,0000,0000,0000,,Yeah, it's totally -- this MOVBE -- it's totally documented, it's official.
Dialogue: 0,0:12:42.42,0:12:47.39,Default,,0000,0000,0000,,[Audience member:] "But, no; is it like a CPU flag just for this instruction or is it implicit by 'this
Dialogue: 0,0:12:47.39,0:12:50.24,Default,,0000,0000,0000,,is an Atom CPU'?"
Dialogue: 0,0:12:51.04,0:12:58.04,Default,,0000,0000,0000,,Uh... Yeah, I don't know. I check the value by CPUID but I don't know if it's relevant to the... but
Dialogue: 0,0:12:58.04,0:13:07.06,Default,,0000,0000,0000,,I think it's by itself. ...but the CPUID result is so big that I don't remember it all.
Dialogue: 0,0:13:07.95,0:13:13.06,Default,,0000,0000,0000,,Uh, another thing, a bit specific to Windows in my case, because I focus on malware, is that before you do
Dialogue: 0,0:13:13.06,0:13:22.05,Default,,0000,0000,0000,,actually any opcode, I was focusing on what are the register values when you start a program, and I found
Dialogue: 0,0:13:22.05,0:13:28.07,Default,,0000,0000,0000,,out that the register values by default when you start a program and you haven't executed, theoretically, any opcode,
Dialogue: 0,0:13:28.07,0:13:33.06,Default,,0000,0000,0000,,- theoretically- actually gives you some information that are actively used in malwares.
Dialogue: 0,0:13:33.06,0:13:40.05,Default,,0000,0000,0000,,So for example, at the start point, EAX gives you either gives you if it's older generation (XP or before),
Dialogue: 0,0:13:40.05,0:13:41.90,Default,,0000,0000,0000,,or Vista or later.
Dialogue: 0,0:13:42.08,0:13:50.62,Default,,0000,0000,0000,,This is not so used by malwares, I don't recall seeing it, but GS, if GS is null, then it's a 32-bit
Dialogue: 0,0:13:50.62,0:13:54.03,Default,,0000,0000,0000,,system, and if it's not it's a 64-bit system.
Dialogue: 0,0:13:54.03,0:13:56.09,Default,,0000,0000,0000,,I will actually use that later in one of the tricks.
Dialogue: 0,0:13:56.09,0:14:04.03,Default,,0000,0000,0000,,And also, the relations between the registers -- there are many registers on the Intel CPUs -- is not
Dialogue: 0,0:14:04.03,0:14:10.08,Default,,0000,0000,0000,,sometimes very clear. I was surprised that when you do a FPU operation, it changes the FPU status, the
Dialogue: 0,0:14:10.08,0:14:18.05,Default,,0000,0000,0000,,FPU registers themselves, but also the MMX registers, and somehow all the documentations I saw on the
Dialogue: 0,0:14:18.05,0:14:24.68,Default,,0000,0000,0000,,internet are always mapping ST0 and MM0 in front of each other which makes sense, but actually if you
Dialogue: 0,0:14:24.68,0:14:30.47,Default,,0000,0000,0000,,modify -- if you just do a single FPU operation, it will actually modify not MM0, but MM7.
Dialogue: 0,0:14:31.04,0:14:36.08,Default,,0000,0000,0000,,So if you do an FPU operation like "load PI" [FLDPI] and then you check the value of MM7, that could be used
Dialogue: 0,0:14:36.08,0:14:38.78,Default,,0000,0000,0000,,as a trick or it's just like the way it is.
Dialogue: 0,0:14:38.78,0:14:45.09,Default,,0000,0000,0000,,And like, all the documentations, wikipedia and so on, that I could find about the overlapping of the registers.
Dialogue: 0,0:14:45.09,0:14:53.03,Default,,0000,0000,0000,,Another thing is that this was used as an anti-emulation trick in XP, that FPU also changes CR0
Dialogue: 0,0:14:53.03,0:14:59.08,Default,,0000,0000,0000,,so you have quite an unexpected anti-emulation trick by just using FPU operation.
Dialogue: 0,0:14:59.08,0:15:08.65,Default,,0000,0000,0000,,So here is it; basically 'store machine status word' [SMSW] is an older 286 CPU opcode -- mnemonic, that was
Dialogue: 0,0:15:08.65,0:15:18.05,Default,,0000,0000,0000,,created at the 286 era, so before the protected mode was fully created, and so it allows you to access
Dialogue: 0,0:15:18.05,0:15:26.10,Default,,0000,0000,0000,,to read the value of CR0, even from user mode, while the 'MOV CR0' is actually a privileged opcode.
Dialogue: 0,0:15:26.10,0:15:33.64,Default,,0000,0000,0000,,For some reason, the higher word of the register is undefined officially by the documentation, so Intel
Dialogue: 0,0:15:33.64,0:15:40.04,Default,,0000,0000,0000,,just says "this is the value -- the lowest value is correct but you cannot expect the real value". So for
Dialogue: 0,0:15:40.04,0:15:45.07,Default,,0000,0000,0000,,some reason, I don't know why they say that, because it's actually the value - the higher bits - of CR0.
Dialogue: 0,0:15:45.07,0:15:52.72,Default,,0000,0000,0000,,And under XP, when you do FPU operations, the value of CR0 will be modified, and eventually reverts
Dialogue: 0,0:15:52.72,0:16:00.03,Default,,0000,0000,0000,,by itself. So you can have, just by doing -- SMSW, and then you expect the result, then
Dialogue: 0,0:16:00.03,0:16:05.09,Default,,0000,0000,0000,,you do a FPU operation, then the result should be different, and then eventually the result will revert
Dialogue: 0,0:16:05.09,0:16:10.26,Default,,0000,0000,0000,,to the original value. So it's quite a tricky and unexpected anti-emulator.
Dialogue: 0,0:16:11.00,0:16:18.92,Default,,0000,0000,0000,,You have a similar trick on 32-bit Windows, where GS is not stored in the context, so it means that on
Dialogue: 0,0:16:18.92,0:16:25.31,Default,,0000,0000,0000,,thread-switch the value of GS is lost, which means if you just wait for something, GS will eventually
Dialogue: 0,0:16:25.31,0:16:32.34,Default,,0000,0000,0000,,reset to 0. So if you set GS and you are stepping manually, this is slow and this creates a thread-switch,
Dialogue: 0,0:16:32.42,0:16:39.56,Default,,0000,0000,0000,,so instantly GS is lost. And also, like the previous trick, if you just wait for GS not to be...
Dialogue: 0,0:16:40.05,0:16:45.07,Default,,0000,0000,0000,,if you just loop until GS is not 0, this on a real system, will eventually exit from the loop.
Dialogue: 0,0:16:45.07,0:16:52.84,Default,,0000,0000,0000,,But the first time, it blew me, I was really wondering what can happen there, there's no other thread
Dialogue: 0,0:16:52.84,0:16:58.33,Default,,0000,0000,0000,,and of course in my proof of concept, it directly starts like this. What happens? What should happen now ,
Dialogue: 0,0:16:58.33,0:17:02.09,Default,,0000,0000,0000,,but on a real system? Eventually, it's reset to 0.
Dialogue: 0,0:17:02.09,0:17:10.31,Default,,0000,0000,0000,,Another thing is that of course it's reset to 0, but not in 0 time, so if you do wait for GS's reset
Dialogue: 0,0:17:10.31,0:17:17.05,Default,,0000,0000,0000,,and then another loop, this can only happen between two resets... thread switch, which means it should
Dialogue: 0,0:17:17.05,0:17:23.01,Default,,0000,0000,0000,,take a minimum of time, so you can use that for timing -- anti-emulation timing tricks.
Dialogue: 0,0:17:25.05,0:17:32.40,Default,,0000,0000,0000,,Of course, I was also thinking that NOP is perfect, because NOP is NOP, it does nothing.
Dialogue: 0,0:17:33.02,0:17:44.01,Default,,0000,0000,0000,,But originally NOP is 'exchange eax with eax' [xchg eax, eax], or 'ax with ax', but the problem is that NOP [encoded as] 0x90 is always doing nothing,
Dialogue: 0,0:17:44.01,0:17:51.02,Default,,0000,0000,0000,,but on 64-bit you always have, you have another encoding [87 c0] to do an 'exchange EAX AX' which this time again
Dialogue: 0,0:17:51.02,0:17:54.06,Default,,0000,0000,0000,,doesn't do anything on 32b, but like all the other opcodes
Dialogue: 0,0:17:54.06,0:17:58.08,Default,,0000,0000,0000,,in 64b mode, it actually resets the higher DWORD
Dialogue: 0,0:17:58.08,0:18:02.08,Default,,0000,0000,0000,,so you have an XCHG EAX [,EAX] that does something,
Dialogue: 0,0:18:02.08,0:18:05.08,Default,,0000,0000,0000,,even though at first it looks like it would do nothing
Dialogue: 0,0:18:05.08,0:18:09.25,Default,,0000,0000,0000,,but hopefully in this case the 90 NOP is still doing nothing
Dialogue: 0,0:18:10.02,0:18:13.63,Default,,0000,0000,0000,,and this is probably now common in malwares and stuff
Dialogue: 0,0:18:14.02,0:18:18.05,Default,,0000,0000,0000,,HINT NOP was the multi-byte nop
Dialogue: 0,0:18:18.05,0:18:22.52,Default,,0000,0000,0000,,that actually gives a hint about what will be executed next, by the CPU
Dialogue: 0,0:18:23.04,0:18:24.05,Default,,0000,0000,0000,,whatever the address here [in memory referenced HINT NOP]
Dialogue: 0,0:18:24.05,0:18:25.60,Default,,0000,0000,0000,,it wouldn't trigger an exception
Dialogue: 0,0:18:25.60,0:18:29.63,Default,,0000,0000,0000,,but as you can see, it's really a multi-byte opcode -- it can be a very long nop
Dialogue: 0,0:18:30.76,0:18:31.67,Default,,0000,0000,0000,,that's weird to say
Dialogue: 0,0:18:32.14,0:18:35.46,Default,,0000,0000,0000,,another thing is, once again it's partially undocumented by Intel
Dialogue: 0,0:18:37.02,0:18:44.06,Default,,0000,0000,0000,,the full range of HINT NOP encoding is bigger on AMD documentation
Dialogue: 0,0:18:44.06,0:18:47.70,Default,,0000,0000,0000,,and another thing is that, because it's a multi-byte opcode
Dialogue: 0,0:18:48.04,0:18:51.08,Default,,0000,0000,0000,,if you - at the end of a page - insert those bytes
Dialogue: 0,0:18:51.08,0:18:54.48,Default,,0000,0000,0000,,then it will look for the operands
Dialogue: 0,0:18:54.74,0:18:56.06,Default,,0000,0000,0000,,then it could trigger an exception,
Dialogue: 0,0:18:56.06,0:18:59.70,Default,,0000,0000,0000,,so it's a nop that could trigger an exception if at the end of the page
Dialogue: 0,0:19:01.04,0:19:04.06,Default,,0000,0000,0000,,so, thank you Intel -- or whatever, I don't know, I'm not sure
Dialogue: 0,0:19:04.06,0:19:06.27,Default,,0000,0000,0000,,MOV, once again, I thought...
Dialogue: 0,0:19:06.27,0:19:09.96,Default,,0000,0000,0000,,MOV being MOV, should be perfectly logical
Dialogue: 0,0:19:10.99,0:19:15.38,Default,,0000,0000,0000,,sadly not... first... all this is documented, but it's tricky
Dialogue: 0,0:19:15.44,0:19:19.08,Default,,0000,0000,0000,,because -- there were even bugs for that in all the disassemblers I tried, I think
Dialogue: 0,0:19:19.08,0:19:20.86,Default,,0000,0000,0000,,well, except Xed, maybe
Dialogue: 0,0:19:22.57,0:19:29.06,Default,,0000,0000,0000,,you cannot do MOV on or from CR0 on memory
Dialogue: 0,0:19:29.06,0:19:32.05,Default,,0000,0000,0000,,so the documentation says that the Mod/RM is ignored
Dialogue: 0,0:19:32.75,0:19:34.58,Default,,0000,0000,0000,,it doesn't mean it's illegal, it's just ignored
Dialogue: 0,0:19:34.70,0:19:36.60,Default,,0000,0000,0000,,so if you do this, which could lead to a crash
Dialogue: 0,0:19:36.60,0:19:39.05,Default,,0000,0000,0000,,it's actually interpreted as that
Dialogue: 0,0:19:39.05,0:19:42.03,Default,,0000,0000,0000,,and as far as I can remember, you'd fail all the disassemblers with that
Dialogue: 0,0:19:42.03,0:19:43.66,Default,,0000,0000,0000,,until recently [ ;) ]
Dialogue: 0,0:19:44.04,0:19:50.46,Default,,0000,0000,0000,,MOVSXD is a 64b opcode, is sign-extending, so theoretically
Dialogue: 0,0:19:50.46,0:19:55.04,Default,,0000,0000,0000,,it should work from a smaller register to a bigger register
Dialogue: 0,0:19:55.04,0:19:57.81,Default,,0000,0000,0000,,but if you use no REX prefix, which is discouraged
Dialogue: 0,0:19:57.81,0:20:00.23,Default,,0000,0000,0000,,you can actually make it work like a standard MOV,
Dialogue: 0,0:20:01.40,0:20:04.04,Default,,0000,0000,0000,,and the other way around,
Dialogue: 0,0:20:04.04,0:20:09.09,Default,,0000,0000,0000,,MOV from a selector to a 32b register actually works
Dialogue: 0,0:20:09.09,0:20:12.49,Default,,0000,0000,0000,,so many disassemblers were disassembling that as MOV AX, CS
Dialogue: 0,0:20:12.49,0:20:15.67,Default,,0000,0000,0000,,because that would make both operands the same size,
Dialogue: 0,0:20:15.67,0:20:19.31,Default,,0000,0000,0000,,but actually the upper word of the target register
Dialogue: 0,0:20:19.31,0:20:22.64,Default,,0000,0000,0000,,is 'undefined' but actually there is no funny thing here,
Dialogue: 0,0:20:22.64,0:20:24.82,Default,,0000,0000,0000,,there's no random value, it's zeroes
Dialogue: 0,0:20:24.82,0:20:29.27,Default,,0000,0000,0000,,so basically, it makes it equivalent to MOV EAX, CS
Dialogue: 0,0:20:30.36,0:20:32.06,Default,,0000,0000,0000,,BSWAP is one of my favorite
Dialogue: 0,0:20:32.06,0:20:34.69,Default,,0000,0000,0000,,because I think it's like an administration
Dialogue: 0,0:20:35.02,0:20:37.69,Default,,0000,0000,0000,,it's supposed to just swap the endianness of the registers
Dialogue: 0,0:20:37.69,0:20:42.41,Default,,0000,0000,0000,,but because of -- external reasons
Dialogue: 0,0:20:42.41,0:20:44.56,Default,,0000,0000,0000,,it's never really doing the work you expect
Dialogue: 0,0:20:44.56,0:20:50.04,Default,,0000,0000,0000,,so, only in 64b, it's actually correctly swapping the endianness
Dialogue: 0,0:20:50.04,0:20:51.10,Default,,0000,0000,0000,,as you would expect
Dialogue: 0,0:20:51.10,0:20:55.10,Default,,0000,0000,0000,,on EAX [32b], in 64b [mode], like all the 32b opcodes,
Dialogue: 0,0:20:55.10,0:20:58.34,Default,,0000,0000,0000,,it will actually register [clear] the higher dword -- ok !
Dialogue: 0,0:20:58.34,0:21:02.07,Default,,0000,0000,0000,,and, on word, it's actually 'undefined' again
Dialogue: 0,0:21:02.07,0:21:04.02,Default,,0000,0000,0000,,but it's commonly used in malwares and packers
Dialogue: 0,0:21:04.07,0:21:07.01,Default,,0000,0000,0000,,because it just resets [the register]
Dialogue: 0,0:21:07.01,0:21:09.06,Default,,0000,0000,0000,,so it's like a XOR AX, AX
Dialogue: 0,0:21:09.06,0:21:14.05,Default,,0000,0000,0000,,so, with this unexplainable result, I understand
Dialogue: 0,0:21:14.05,0:21:18.07,Default,,0000,0000,0000,,that Intel probably doesn't want to explain -- just say it's 'undefined'
Dialogue: 0,0:21:18.07,0:21:20.09,Default,,0000,0000,0000,,because they would be too ashamed to explain
Dialogue: 0,0:21:20.09,0:21:22.40,Default,,0000,0000,0000,,why we get this funny result
Dialogue: 0,0:21:24.07,0:21:31.13,Default,,0000,0000,0000,,BSWAP AX is also wrongly disassembled by WinDbg and so on
Dialogue: 0,0:21:33.04,0:21:35.07,Default,,0000,0000,0000,,it will be disassembled as BSWAP EAX
Dialogue: 0,0:21:35.07,0:21:36.78,Default,,0000,0000,0000,,and actually, you clear the register
Dialogue: 0,0:21:42.01,0:21:44.32,Default,,0000,0000,0000,,can everybody understand this code?
Dialogue: 0,0:21:47.04,0:21:49.51,Default,,0000,0000,0000,,anybody sees the potential trap?
Dialogue: 0,0:21:53.00,0:21:56.06,Default,,0000,0000,0000,,so, it pushes the address of  on the stack,
Dialogue: 0,0:21:56.06,0:21:59.50,Default,,0000,0000,0000,,then RETN takes the address from the stack,
Dialogue: 0,0:21:59.50,0:22:02.70,Default,,0000,0000,0000,,and, basically, you just jump to an immediate value,
Dialogue: 0,0:22:10.11,0:22:10.95,Default,,0000,0000,0000,,execution ordering ?
Dialogue: 0,0:22:10.97,0:22:12.85,Default,,0000,0000,0000,,yeah, the execution starts here
Dialogue: 0,0:22:14.03,0:22:17.12,Default,,0000,0000,0000,,???
Dialogue: 0,0:22:17.12,0:22:20.10,Default,,0000,0000,0000,,no -- ok, it's not the point here
Dialogue: 0,0:22:20.10,0:22:25.55,Default,,0000,0000,0000,,and of course, if you -- this is OllyDbg 1, it's fixed in OllyDbg 2
Dialogue: 0,0:22:25.55,0:22:28.03,Default,,0000,0000,0000,,but OllyDbg1 is even trying to be nice,
Dialogue: 0,0:22:28.03,0:22:30.06,Default,,0000,0000,0000,,telling you -- this is an automatic comment -- that RET
Dialogue: 0,0:22:30.06,0:22:32.38,Default,,0000,0000,0000,,is used as a jump to 
Dialogue: 0,0:22:33.06,0:22:36.03,Default,,0000,0000,0000,,and, as you can see, not exactly the same [happens]
Dialogue: 0,0:22:36.03,0:22:37.05,Default,,0000,0000,0000,,so, what happened ?
Dialogue: 0,0:22:37.05,0:22:38.24,Default,,0000,0000,0000,,no one sees ?
Dialogue: 0,0:22:40.02,0:22:42.46,Default,,0000,0000,0000,,so, basically, here, you have a 66 prefix on RETN
Dialogue: 0,0:22:42.83,0:22:46.08,Default,,0000,0000,0000,,which actually makes RETN to IP, and not EIP
Dialogue: 0,0:22:47.04,0:22:55.02,Default,,0000,0000,0000,,so, actually, you don't jump to 401008, but to 00001008
Dialogue: 0,0:22:55.66,0:22:58.56,Default,,0000,0000,0000,,and in this proof of concept, I mapped the NULL page
Dialogue: 0,0:22:58.56,0:23:01.01,Default,,0000,0000,0000,,and I created -- added some code at this address
Dialogue: 0,0:23:01.01,0:23:05.60,Default,,0000,0000,0000,,so, this is actually not a return to this []
Dialogue: 0,0:23:05.60,0:23:10.08,Default,,0000,0000,0000,,but the problem is that, officially, this is also called a 'return'
Dialogue: 0,0:23:10.08,0:23:15.08,Default,,0000,0000,0000,,it's not [different from the standard one] -- the disassemblers added their own, now, way of disassembling it
Dialogue: 0,0:23:15.08,0:23:19.06,Default,,0000,0000,0000,,like 'small retn', ret.16, or something like this
Dialogue: 0,0:23:19.06,0:23:22.08,Default,,0000,0000,0000,,but actually officially, it's the same mnemonic
Dialogue: 0,0:23:22.08,0:23:26.74,Default,,0000,0000,0000,,so, the latest Hiew, I think, and that's OllyDbg 1
Dialogue: 0,0:23:28.33,0:23:31.02,Default,,0000,0000,0000,,maybe the latest OllyDbg 2 fixed that
Dialogue: 0,0:23:31.02,0:23:33.02,Default,,0000,0000,0000,,but you can still be tricked just by that
Dialogue: 0,0:23:33.02,0:23:41.02,Default,,0000,0000,0000,,the 66 prefix - the jump to IP - also works on CALLs, RETs, LOOPs, [and JMPs]
Dialogue: 0,0:23:41.02,0:23:44.14,Default,,0000,0000,0000,,so all the flow control opcodes
Dialogue: 0,0:23:45.10,0:23:47.49,Default,,0000,0000,0000,,so, I won't enumerate all the tricks,
Dialogue: 0,0:23:47.49,0:23:51.07,Default,,0000,0000,0000,,because otherwise you'll die of boredom probably
Dialogue: 0,0:23:51.07,0:23:55.04,Default,,0000,0000,0000,,if you want more, then I created a page on Corkami [x86.corkami.com],
Dialogue: 0,0:23:55.04,0:24:00.08,Default,,0000,0000,0000,,and I already made some graphs and cheat sheets
Dialogue: 0,0:24:00.08,0:24:03.52,Default,,0000,0000,0000,,to have an easy [table] -- list of opcodes
Dialogue: 0,0:24:04.41,0:24:06.88,Default,,0000,0000,0000,,and, that's quite too much theory for now...
Dialogue: 0,0:24:06.88,0:24:11.78,Default,,0000,0000,0000,,So, I don't like just -- reading stuff and not having something to feed my debugger
Dialogue: 0,0:24:11.78,0:24:12.79,Default,,0000,0000,0000,,so I created CoST
Dialogue: 0,0:24:12.79,0:24:16.00,Default,,0000,0000,0000,,which stands for Corkami Standard Test
Dialogue: 0,0:24:16.00,0:24:20.68,Default,,0000,0000,0000,,CoST is a single binary, there is no option,
Dialogue: 0,0:24:20.68,0:24:25.05,Default,,0000,0000,0000,,you just run it, and it will just execute a lot of different tests
Dialogue: 0,0:24:25.05,0:24:28.07,Default,,0000,0000,0000,,and then, I also made it a hardened PE,
Dialogue: 0,0:24:28.07,0:24:35.02,Default,,0000,0000,0000,,so it may also help you to test the PE side of your tools
Dialogue: 0,0:24:35.02,0:24:36.04,Default,,0000,0000,0000,,or your knowledge
Dialogue: 0,0:24:36.04,0:24:40.02,Default,,0000,0000,0000,,but, because in hardened PE, it's actually quite difficult to debug,
Dialogue: 0,0:24:40.02,0:24:42.07,Default,,0000,0000,0000,,I also made an easy PE mode so that
Dialogue: 0,0:24:42.07,0:24:47.04,Default,,0000,0000,0000,,you can study only the assembly, and not have too much troubles
Dialogue: 0,0:24:47.04,0:24:48.17,Default,,0000,0000,0000,,debugging it
Dialogue: 0,0:24:49.04,0:24:50.98,Default,,0000,0000,0000,,so, CoST contains a lot of tests
Dialogue: 0,0:24:57.09,0:24:59.08,Default,,0000,0000,0000,,classic stuff -- very trivial stuff
Dialogue: 0,0:24:59.08,0:25:03.10,Default,,0000,0000,0000,,then, a few more complex stuff, like JMP to IP, IRET...
Dialogue: 0,0:25:03.10,0:25:05.03,Default,,0000,0000,0000,,undocumented opcodes
Dialogue: 0,0:25:05.03,0:25:10.04,Default,,0000,0000,0000,,CPU specific, like MOVBE, POPCNT, CRC32
Dialogue: 0,0:25:10.04,0:25:17.08,Default,,0000,0000,0000,,also some detections of OS and VM by using common opcodes
Dialogue: 0,0:25:17.08,0:25:25.05,Default,,0000,0000,0000,,like, the 'red pill trick'... yeah, just SLDT execution, and you get a value, and you compare...
Dialogue: 0,0:25:25.05,0:25:27.51,Default,,0000,0000,0000,,but it's 'the blue pill', or whatever...
Dialogue: 0,0:25:29.02,0:25:32.54,Default,,0000,0000,0000,,and also some OS bugs because sometimes, Windows XP
Dialogue: 0,0:25:32.54,0:25:35.05,Default,,0000,0000,0000,,was doing the wrong job trying to tell you which was
Dialogue: 0,0:25:35.05,0:25:38.06,Default,,0000,0000,0000,,the exception that just happened, and it would be a way
Dialogue: 0,0:25:38.06,0:25:44.08,Default,,0000,0000,0000,,to make the difference between an actual OS and an emulator that would try to be logical
Dialogue: 0,0:25:45.19,0:25:49.03,Default,,0000,0000,0000,,CoST is written in assembly, so, there's no extra
Dialogue: 0,0:25:50.03,0:25:52.08,Default,,0000,0000,0000,,it's not compiled, it's not generated, but
Dialogue: 0,0:25:52.08,0:25:56.08,Default,,0000,0000,0000,,to make it self-documented, I created internal exports
Dialogue: 0,0:25:56.08,0:25:59.62,Default,,0000,0000,0000,,so that each section of the file is easy to browse [to],
Dialogue: 0,0:25:59.62,0:26:05.09,Default,,0000,0000,0000,,so that you will know -- if you quickly want to jump to the 64b part
Dialogue: 0,0:26:06.35,0:26:08.03,Default,,0000,0000,0000,,then it's easier via the exports
Dialogue: 0,0:26:08.03,0:26:13.08,Default,,0000,0000,0000,,and also I wanted it to print messages in the most convenient way
Dialogue: 0,0:26:13.08,0:26:18.06,Default,,0000,0000,0000,,so, if you keep printing messages, then it will make the assembly
Dialogue: 0,0:26:18.06,0:26:21.09,Default,,0000,0000,0000,,wider, I mean longer to scroll, so I used
Dialogue: 0,0:26:21.09,0:26:25.07,Default,,0000,0000,0000,,Vectored Exception Handling, and a fake opcode
Dialogue: 0,0:26:25.07,0:26:28.05,Default,,0000,0000,0000,,so that you have the comments of what's gonna happen,
Dialogue: 0,0:26:28.05,0:26:30.04,Default,,0000,0000,0000,,appearing directly in the code
Dialogue: 0,0:26:30.04,0:26:34.09,Default,,0000,0000,0000,,so it's a kind of self-documented, without a debug symbols file
Dialogue: 0,0:26:34.09,0:26:38.09,Default,,0000,0000,0000,,and, you saw, it doesn't have much of output
Dialogue: 0,0:26:38.09,0:26:41.09,Default,,0000,0000,0000,,but actually it has a lot of debug output
Dialogue: 0,0:26:41.09,0:26:46.100,Default,,0000,0000,0000,,like 100 -- I forgot -- messages. it's even saying '[trick] I'm gonna do this'
Dialogue: 0,0:26:46.100,0:26:48.79,Default,,0000,0000,0000,,and then, 'i'm gonna do that...', so
Dialogue: 0,0:26:49.07,0:26:54.57,Default,,0000,0000,0000,,trying to make it helpful yet a bit hard to disassemble
Dialogue: 0,0:26:57.08,0:26:59.52,Default,,0000,0000,0000,,can anyone understand what this code is doing ?
Dialogue: 0,0:26:59.52,0:27:00.81,Default,,0000,0000,0000,,this is one of my favourite
Dialogue: 0,0:27:02.08,0:27:04.95,Default,,0000,0000,0000,,we can't see the opcodes
Dialogue: 0,0:27:06.01,0:27:07.38,Default,,0000,0000,0000,,no, there's no [opcode] trick this time
Dialogue: 0,0:27:17.07,0:27:19.07,Default,,0000,0000,0000,,so, basically you push some arguments on the stack
Dialogue: 0,0:27:19.07,0:27:21.00,Default,,0000,0000,0000,,you jump to here
Dialogue: 0,0:27:21.00,0:27:25.59,Default,,0000,0000,0000,,basically, with the return far [RETF]... I pushed 'push_eip' on the stack
Dialogue: 0,0:27:25.64,0:27:28.05,Default,,0000,0000,0000,,with a 33 word
Dialogue: 0,0:27:28.05,0:27:30.45,Default,,0000,0000,0000,,so basically I will RETurn Far to this
Dialogue: 0,0:27:30.45,0:27:35.06,Default,,0000,0000,0000,,basically I will return back to this EIP in selector 33
Dialogue: 0,0:27:35.06,0:27:38.74,Default,,0000,0000,0000,,if this is in a 64b OS, and this is a 32b process
Dialogue: 0,0:27:38.77,0:27:42.08,Default,,0000,0000,0000,,you will return back to execution here, in 64b mode
Dialogue: 0,0:27:42.08,0:27:47.08,Default,,0000,0000,0000,,because selector 33 is the selector for 64b mode
Dialogue: 0,0:27:47.08,0:27:49.08,Default,,0000,0000,0000,,which you can access from a 32b process
Dialogue: 0,0:27:49.08,0:27:53.57,Default,,0000,0000,0000,,so basically this code will be executed first in the current selector
Dialogue: 0,0:27:56.03,0:28:01.10,Default,,0000,0000,0000,,as you see, and then it's executed back on selector 33,
Dialogue: 0,0:28:01.10,0:28:03.53,Default,,0000,0000,0000,,which means in 64b mode
Dialogue: 0,0:28:03.53,0:28:08.04,Default,,0000,0000,0000,,so you have the same EIP, you have the same opcodes
Dialogue: 0,0:28:08.04,0:28:10.02,Default,,0000,0000,0000,,but the disassembly will be different,
Dialogue: 0,0:28:10.02,0:28:14.02,Default,,0000,0000,0000,,and I chose some opcodes will make mnemonics
Dialogue: 0,0:28:14.02,0:28:17.37,Default,,0000,0000,0000,,specific to each side, 32b or 64b sides
Dialogue: 0,0:28:17.37,0:28:22.09,Default,,0000,0000,0000,,so, it's already quite a b*tch to disassemble
Dialogue: 0,0:28:22.09,0:28:27.09,Default,,0000,0000,0000,,because, same EIP, so unless you're careful about the selector,
Dialogue: 0,0:28:27.09,0:28:29.01,Default,,0000,0000,0000,,well, it's a problem
Dialogue: 0,0:28:29.83,0:28:36.47,Default,,0000,0000,0000,,[Errata: you can debug this kind of code, check my berlinsides presentation (screencast on slide 58)]
Dialogue: 0,0:28:38.42,0:28:44.54,Default,,0000,0000,0000,,http://bsx2.corkami.com , slide 58 [screencast]
Dialogue: 0,0:28:46.62,0:28:50.06,Default,,0000,0000,0000,,if you run over it, you return to the original selector,
Dialogue: 0,0:28:50.06,0:28:52.06,Default,,0000,0000,0000,,which is why there is the PUSH CS here
Dialogue: 0,0:28:52.06,0:28:56.03,Default,,0000,0000,0000,,and you go back to with the original selector
Dialogue: 0,0:28:56.03,0:28:58.07,Default,,0000,0000,0000,,execution will go through quickly
Dialogue: 0,0:28:58.07,0:29:00.08,Default,,0000,0000,0000,,but you cannot step through that code [WRONG, you can with WinDbg+wow64exts]
Dialogue: 0,0:29:00.08,0:29:03.08,Default,,0000,0000,0000,,so, killing the disassemblers, and the debuggers
Dialogue: 0,0:29:03.08,0:29:04.09,Default,,0000,0000,0000,,and yet, simple
Dialogue: 0,0:29:04.09,0:29:07.04,Default,,0000,0000,0000,,so, here is the result that you get when you run CoST
Dialogue: 0,0:29:07.04,0:29:10.07,Default,,0000,0000,0000,,with the latest -- well the latest public version of Hiew
Dialogue: 0,0:29:10.07,0:29:13.03,Default,,0000,0000,0000,,I think it's gonna be fixed
Dialogue: 0,0:29:13.03,0:29:16.08,Default,,0000,0000,0000,,so, this is a HINT NOP that's not documented by Intel
Dialogue: 0,0:29:16.08,0:29:20.25,Default,,0000,0000,0000,,and it's a bit forgotten by most disassemblers
Dialogue: 0,0:29:20.25,0:29:24.05,Default,,0000,0000,0000,,so, WinDbg and Hiew are giving you
Dialogue: 0,0:29:24.05,0:29:28.54,Default,,0000,0000,0000,,undocumented, well -- questions marks, or the Hiew style of question marks
Dialogue: 0,0:29:28.54,0:29:34.39,Default,,0000,0000,0000,,then, since -- that was originally what I planned to present at Hashdays
Dialogue: 0,0:29:34.43,0:29:39.06,Default,,0000,0000,0000,,but then, I decided to bring a few tricks in CoST itself, on the PE side of things
Dialogue: 0,0:29:39.06,0:29:42.40,Default,,0000,0000,0000,,so, this is the header, so it has MZ, and then some text
Dialogue: 0,0:29:42.40,0:29:44.04,Default,,0000,0000,0000,,so you can 'type cost.exe'
Dialogue: 0,0:29:44.04,0:29:46.09,Default,,0000,0000,0000,,and it has some text - I made it type-able
Dialogue: 0,0:29:46.09,0:29:51.08,Default,,0000,0000,0000,,and the NT headers - the 'PE' header, the one starting with PE
Dialogue: 0,0:29:51.08,0:29:54.08,Default,,0000,0000,0000,,is actually starting at the bottom of the file -- the bottom of the file is here
Dialogue: 0,0:29:54.08,0:29:55.15,Default,,0000,0000,0000,,so it's a footer
Dialogue: 0,0:29:55.15,0:29:57.56,Default,,0000,0000,0000,,and I made it so the values are quite critical
Dialogue: 0,0:29:57.64,0:30:01.04,Default,,0000,0000,0000,,so, they are not the one you would expect
Dialogue: 0,0:30:01.04,0:30:03.04,Default,,0000,0000,0000,,so this is the result that you would get when you were
Dialogue: 0,0:30:03.04,0:30:05.46,Default,,0000,0000,0000,,loading CoST under IDA 6.1
Dialogue: 0,0:30:07.01,0:30:10.27,Default,,0000,0000,0000,,so, well, some values were random and everything
Dialogue: 0,0:30:11.02,0:30:15.33,Default,,0000,0000,0000,,but, if you have -- with CoST, you can test and set the value of a register
Dialogue: 0,0:30:15.33,0:30:16.62,Default,,0000,0000,0000,,then compare it
Dialogue: 0,0:30:16.62,0:30:19.06,Default,,0000,0000,0000,,but you cannot test all the possibilities of PE files
Dialogue: 0,0:30:19.06,0:30:21.07,Default,,0000,0000,0000,,with a single file, because you have to choose
Dialogue: 0,0:30:21.07,0:30:25.07,Default,,0000,0000,0000,,so, for example, CoST has no section, weird alignments and everything
Dialogue: 0,0:30:25.07,0:30:27.08,Default,,0000,0000,0000,,but you cannot make all the possible cases [in a single file]
Dialogue: 0,0:30:27.08,0:30:31.01,Default,,0000,0000,0000,,so, I went on and I created another page on Corkami
Dialogue: 0,0:30:31.01,0:30:37.02,Default,,0000,0000,0000,,with, as usual, the proof of concepts, some graphs about the PE files and everything
Dialogue: 0,0:30:37.02,0:30:40.07,Default,,0000,0000,0000,,I don't consider it finished but I consider it good enough to break
Dialogue: 0,0:30:40.07,0:30:41.50,Default,,0000,0000,0000,,a bit everything
Dialogue: 0,0:30:42.10,0:30:46.04,Default,,0000,0000,0000,,now, I already created more than 100 PoCs, which try
Dialogue: 0,0:30:46.04,0:30:50.68,Default,,0000,0000,0000,,0 section, big alignments, huge alignments, and I have some funny results...
Dialogue: 0,0:30:50.68,0:30:55.02,Default,,0000,0000,0000,,so, here is the 'virtual section table vs Hiew'
Dialogue: 0,0:30:55.02,0:31:00.01,Default,,0000,0000,0000,,so, when you're in low alignments, you can have no section,
Dialogue: 0,0:31:00.01,0:31:03.03,Default,,0000,0000,0000,,or the section table can be empty
Dialogue: 0,0:31:03.03,0:31:08.04,Default,,0000,0000,0000,,so basically, I made the SizeOfOptionalHeader point in virtual memory space
Dialogue: 0,0:31:08.04,0:31:11.10,Default,,0000,0000,0000,,which means the section table is out of the PE file [full of 00, in virtual space]
Dialogue: 0,0:31:11.10,0:31:16.03,Default,,0000,0000,0000,,and Hiew doesn't like this. A consequence of that it doesn't even think it's a PE file
Dialogue: 0,0:31:16.03,0:31:18.09,Default,,0000,0000,0000,,while it's fully working, but this trick only works under XP
Dialogue: 0,0:31:18.09,0:31:25.01,Default,,0000,0000,0000,,because Windows 7 is a bit more picky on the unused section table values
Dialogue: 0,0:31:29.05,0:31:34.03,Default,,0000,0000,0000,,so when you got some ASCII art in the Data Directories
Dialogue: 0,0:31:34.03,0:31:37.02,Default,,0000,0000,0000,,you can probably guess that there is something going on
Dialogue: 0,0:31:37.02,0:31:40.00,Default,,0000,0000,0000,,if you have better ASCII art suggestion, I'm all ears
Dialogue: 0,0:31:40.00,0:31:43.03,Default,,0000,0000,0000,,so, basically, this is the 'Dual PE header' that was presented by
Dialogue: 0,0:31:43.03,0:31:45.11,Default,,0000,0000,0000,,Reversing Labs in BlackHat
Dialogue: 0,0:31:45.11,0:31:47.82,Default,,0000,0000,0000,,so, are you familiar with that ?
Dialogue: 0,0:31:50.03,0:31:52.05,Default,,0000,0000,0000,,so, basically, you extend the SizeOfHeaders so that
Dialogue: 0,0:31:52.05,0:31:59.07,Default,,0000,0000,0000,,the NT headers will be actually mapped at the bottom of the file
Dialogue: 0,0:31:59.07,0:32:03.27,Default,,0000,0000,0000,,so that when it's far enough to reach section [not file] alignment
Dialogue: 0,0:32:03.68,0:32:05.05,Default,,0000,0000,0000,,and when you load that, in memory
Dialogue: 0,0:32:05.05,0:32:07.30,Default,,0000,0000,0000,,the first section will actually be mapped over it
Dialogue: 0,0:32:09.53,0:32:12.68,Default,,0000,0000,0000,,the first part of the OPTIONAL_HEADER is the one used on disk
Dialogue: 0,0:32:13.05,0:32:16.05,Default,,0000,0000,0000,,so, this is what is used to check if the file will load
Dialogue: 0,0:32:16.05,0:32:20.10,Default,,0000,0000,0000,,but the Data Directories are read from the values in memory
Dialogue: 0,0:32:20.10,0:32:25.00,Default,,0000,0000,0000,,so, first, the OPTIONAL_HEADER is parsed, mapped in memory
Dialogue: 0,0:32:25.00,0:32:29.04,Default,,0000,0000,0000,,then the section is folding itself over the bottom part of the header
Dialogue: 0,0:32:29.04,0:32:31.09,Default,,0000,0000,0000,,and then the true Data directories that were originally
Dialogue: 0,0:32:31.09,0:32:34.03,Default,,0000,0000,0000,,in the start of the section will be taken in account
Dialogue: 0,0:32:34.03,0:32:39.07,Default,,0000,0000,0000,,so all this is garbage and visible on disk, it follows the SizeOfOptionalHeader
Dialogue: 0,0:32:39.07,0:32:43.52,Default,,0000,0000,0000,,but actually in memory, this is not what is used to be parsed
Dialogue: 0,0:32:45.01,0:32:47.04,Default,,0000,0000,0000,,another weird thing is that the export names can just be
Dialogue: 0,0:32:47.04,0:32:51.01,Default,,0000,0000,0000,,absolutely anything, until a null character
Dialogue: 0,0:32:51.01,0:32:53.07,Default,,0000,0000,0000,,which means, non ASCII, whatever
Dialogue: 0,0:32:53.07,0:32:56.01,Default,,0000,0000,0000,,and another funny thing is that
Dialogue: 0,0:32:56.01,0:32:57.05,Default,,0000,0000,0000,,Hiew displays them in line
Dialogue: 0,0:32:57.05,0:32:59.04,Default,,0000,0000,0000,,so you can just add your own ads,
Dialogue: 0,0:32:59.04,0:33:02.06,Default,,0000,0000,0000,,because those are just export names, and one of the export
Dialogue: 0,0:33:02.06,0:33:05.09,Default,,0000,0000,0000,,[name] is actually more than 16 Kb
Dialogue: 0,0:33:05.09,0:33:08.03,Default,,0000,0000,0000,,so that it's good enough to create a buffer overflow
Dialogue: 0,0:33:08.03,0:33:10.05,Default,,0000,0000,0000,,if your tool is not careful about that
Dialogue: 0,0:33:10.05,0:33:14.03,Default,,0000,0000,0000,,and it's also possible to have a NULL export [name], just a character NULL
Dialogue: 0,0:33:14.03,0:33:15.48,Default,,0000,0000,0000,,and you can import a NULL API
Dialogue: 0,0:33:15.48,0:33:16.65,Default,,0000,0000,0000,,no problem
Dialogue: 0,0:33:19.02,0:33:23.00,Default,,0000,0000,0000,,I also just tried to see the different possibilities
Dialogue: 0,0:33:23.00,0:33:26.05,Default,,0000,0000,0000,,created a few files that had the maximum number of sections
Dialogue: 0,0:33:26.05,0:33:31.07,Default,,0000,0000,0000,,the limit is 96 under XP, and 64K under Vista and [Windows] 7
Dialogue: 0,0:33:31.07,0:33:33.01,Default,,0000,0000,0000,,which means, well
Dialogue: 0,0:33:33.01,0:33:36.07,Default,,0000,0000,0000,,OllyDbg 2 - the latest OllyDbg - gives you a funny message
Dialogue: 0,0:33:36.07,0:33:38.02,Default,,0000,0000,0000,,but it still loads the file.
Dialogue: 0,0:33:38.02,0:33:40.24,Default,,0000,0000,0000,,OllyDbg 1 crashes directly on this file
Dialogue: 0,0:33:42.10,0:33:42.96,Default,,0000,0000,0000,,err...still some time ?
Dialogue: 0,0:33:45.06,0:33:48.06,Default,,0000,0000,0000,,and the one last, not very visual, but I noticed
Dialogue: 0,0:33:48.06,0:33:52.07,Default,,0000,0000,0000,,that the AddressOfIndex of the TLS is overwritten on loading
Dialogue: 0,0:33:52.07,0:33:59.03,Default,,0000,0000,0000,,and imports - the terminator of imports doesn't need to be five null dwords
Dialogue: 0,0:33:59.03,0:34:03.01,Default,,0000,0000,0000,,but only if the name [of the DLL] is 0, then the import descriptor
Dialogue: 0,0:34:03.01,0:34:05.09,Default,,0000,0000,0000,,is considered a terminator
Dialogue: 0,0:34:05.09,0:34:09.29,Default,,0000,0000,0000,,so, basically, if you make AddressOfIndex point to the name of an import descriptor
Dialogue: 0,0:34:10.03,0:34:15.03,Default,,0000,0000,0000,,you could get that overwritten, and then the imports will be truncated
Dialogue: 0,0:34:15.03,0:34:16.07,Default,,0000,0000,0000,,will be considered truncated
Dialogue: 0,0:34:16.07,0:34:20.06,Default,,0000,0000,0000,,and actually, the behavior is different under XP or Windows 7
Dialogue: 0,0:34:20.06,0:34:25.08,Default,,0000,0000,0000,,so, under XP, it's overwritten after imports loading,
Dialogue: 0,0:34:25.08,0:34:28.03,Default,,0000,0000,0000,,so the whole imports table is not truncated,
Dialogue: 0,0:34:28.03,0:34:32.04,Default,,0000,0000,0000,,while under Windows 7, it's happening before the imports are loaded,
Dialogue: 0,0:34:32.04,0:34:35.03,Default,,0000,0000,0000,,which means you have the same PE, but different loading behaviour
Dialogue: 0,0:34:35.03,0:34:37.02,Default,,0000,0000,0000,,under different versions of windows
Dialogue: 0,0:34:37.02,0:34:40.62,Default,,0000,0000,0000,,and the file works on both versions of windows
Dialogue: 0,0:34:43.03,0:34:45.71,Default,,0000,0000,0000,,oh wait, before that... maybe I still have some time ?
Dialogue: 0,0:34:55.06,0:34:56.05,Default,,0000,0000,0000,,15 minutes left ? ok
Dialogue: 0,0:34:56.05,0:34:58.49,Default,,0000,0000,0000,,I'll do the demo
Dialogue: 0,0:35:00.59,0:35:01.46,Default,,0000,0000,0000,,This is just to prove...
Dialogue: 0,0:35:02.40,0:35:03.38,Default,,0000,0000,0000,,sorry?
Dialogue: 0,0:35:23.12,0:35:25.42,Default,,0000,0000,0000,,This is the kind of PE file that I typically create
Dialogue: 0,0:35:25.45,0:35:28.70,Default,,0000,0000,0000,,I only defined [required] elements that just need to work
Dialogue: 0,0:35:28.70,0:35:30.32,Default,,0000,0000,0000,,and this is actually a driver
Dialogue: 0,0:35:30.32,0:35:33.73,Default,,0000,0000,0000,,so, even though I used some undocumented opcodes
Dialogue: 0,0:35:36.67,0:35:39.01,Default,,0000,0000,0000,,It's a working driver and it doesn't have the usual
Dialogue: 0,0:35:40.36,0:35:41.61,Default,,0000,0000,0000,,[compiler] stuff you have in a driver
Dialogue: 0,0:35:43.60,0:35:47.09,Default,,0000,0000,0000,,just to say that this is the kind of PoC, clear to see
Dialogue: 0,0:35:47.09,0:35:51.05,Default,,0000,0000,0000,,you don't have external stuff that bother, that bugs your view
Dialogue: 0,0:35:51.05,0:35:52.09,Default,,0000,0000,0000,,or your debugging
Dialogue: 0,0:35:52.09,0:36:02.06,Default,,0000,0000,0000,,so, this one is just to see the possible values of CR0
Dialogue: 0,0:36:02.06,0:36:07.05,Default,,0000,0000,0000,,via the SMSW, theoretically undefined on DWORD
Dialogue: 0,0:36:07.05,0:36:08.68,Default,,0000,0000,0000,,but it actually gives you the same value
Dialogue: 0,0:36:08.68,0:36:11.07,Default,,0000,0000,0000,,[like] the standard MOV EAX, CR0
Dialogue: 0,0:36:11.07,0:36:16.06,Default,,0000,0000,0000,,and here is MOV EAX, CR0 with the wrong Mod/RM
Dialogue: 0,0:36:16.06,0:36:22.20,Default,,0000,0000,0000,,which, in the latest Hiew, is actually not disassembled at all
Dialogue: 0,0:36:37.81,0:36:38.84,Default,,0000,0000,0000,,let's hope it doesn't crash...
Dialogue: 0,0:36:43.07,0:36:47.03,Default,,0000,0000,0000,,so, as you can see, you get exactly the same value
Dialogue: 0,0:36:47.03,0:36:53.38,Default,,0000,0000,0000,,whether you're using the normal CR0, the 'invalid' one, and the 'undefined'
Dialogue: 0,0:36:55.07,0:36:57.06,Default,,0000,0000,0000,,the upper part is supposed to be undefined
Dialogue: 0,0:36:57.06,0:37:00.07,Default,,0000,0000,0000,,usually when it's undefined, it's zeroes, in Intel language
Dialogue: 0,0:37:00.07,0:37:02.03,Default,,0000,0000,0000,,but here it just works fine
Dialogue: 0,0:37:02.03,0:37:03.06,Default,,0000,0000,0000,,and my machine didn't even crash
Dialogue: 0,0:37:03.06,0:37:05.09,Default,,0000,0000,0000,,which means the driver is fine
Dialogue: 0,0:37:05.09,0:37:07.06,Default,,0000,0000,0000,,so you can study small drivers
Dialogue: 0,0:37:08.05,0:37:11.24,Default,,0000,0000,0000,,the first PoC that I presented here
Dialogue: 0,0:37:11.54,0:37:15.08,Default,,0000,0000,0000,,was the one with old disassembly
Dialogue: 0,0:37:15.08,0:37:17.67,Default,,0000,0000,0000,,anyone still knows what the value is?
Dialogue: 0,0:37:19.67,0:37:22.53,Default,,0000,0000,0000,,so basically, some opcodes are here for garbage
Dialogue: 0,0:37:22.53,0:37:28.03,Default,,0000,0000,0000,,just to prove that they are actually [supported], they are just used as junk
Dialogue: 0,0:37:28.03,0:37:30.09,Default,,0000,0000,0000,,but registers are actually modified [in the others]
Dialogue: 0,0:37:30.09,0:37:37.56,Default,,0000,0000,0000,,and these opcodes from the 70's, or something -- the early 80's
Dialogue: 0,0:37:37.56,0:37:40.90,Default,,0000,0000,0000,,are still perfectly working on a modern CPU or even an i7
Dialogue: 0,0:37:43.09,0:37:47.56,Default,,0000,0000,0000,,one of the PoC I created is the one that actually tests the values
Dialogue: 0,0:37:47.56,0:37:50.43,Default,,0000,0000,0000,,-- the initial values [of each registers] -- so that you can see
Dialogue: 0,0:37:50.51,0:37:54.62,Default,,0000,0000,0000,,what would be the possible values whether it's on XP or Windows 7
Dialogue: 0,0:37:56.02,0:38:01.08,Default,,0000,0000,0000,,each time [TLS, EntryPoint, DllMain], I just save all the values of the registers
Dialogue: 0,0:38:01.08,0:38:03.66,Default,,0000,0000,0000,,and then I compare them to possible values
Dialogue: 0,0:38:03.66,0:38:06.03,Default,,0000,0000,0000,,so I test them one after each other
Dialogue: 0,0:38:06.03,0:38:10.07,Default,,0000,0000,0000,,actually, on TLS, you have much more control of the values
Dialogue: 0,0:38:10.07,0:38:16.08,Default,,0000,0000,0000,,because the values you will get in the TLS -- on loading the TLS
Dialogue: 0,0:38:16.08,0:38:20.02,Default,,0000,0000,0000,,are the RVA [of the TLS data directory], the callbacks, the size of the TLS
Dialogue: 0,0:38:20.02,0:38:23.48,Default,,0000,0000,0000,,you get that in -- I forgot exactly, but it's in the source...
Dialogue: 0,0:38:26.08,0:38:33.06,Default,,0000,0000,0000,,running this will help you to mimic an OS better in your emulator
Dialogue: 0,0:38:33.06,0:38:35.06,Default,,0000,0000,0000,,if that's what you're interested [in]
Dialogue: 0,0:38:35.06,0:38:41.06,Default,,0000,0000,0000,,SMSW is actually the one comparing -- so, using SMSW,
Dialogue: 0,0:38:41.06,0:38:46.04,Default,,0000,0000,0000,,then comparing the value, then checking whether the register changed
Dialogue: 0,0:38:46.04,0:38:48.08,Default,,0000,0000,0000,,[after an FPU operation] and then when it reverts normally
Dialogue: 0,0:38:48.08,0:38:52.05,Default,,0000,0000,0000,,a funny fact that I would like an explanation [for],
Dialogue: 0,0:38:52.05,0:38:53.54,Default,,0000,0000,0000,,if you know it
Dialogue: 0,0:38:54.08,0:39:01.02,Default,,0000,0000,0000,,is that actually, this behaviour is different if you run the file normally
Dialogue: 0,0:39:01.02,0:39:04.06,Default,,0000,0000,0000,,or if you run it with a redirection
Dialogue: 0,0:39:04.06,0:39:08.05,Default,,0000,0000,0000,,if you pipe the output, you get a 'fail' result
Dialogue: 0,0:39:08.05,0:39:11.05,Default,,0000,0000,0000,,if you run the file normally, it just works
Dialogue: 0,0:39:11.05,0:39:17.44,Default,,0000,0000,0000,,so, I would like -- here, I will just run it, and then I will run it to a file, and just TYPE the result
Dialogue: 0,0:39:22.02,0:39:24.07,Default,,0000,0000,0000,,normal execution: OK
Dialogue: 0,0:39:24.07,0:39:26.06,Default,,0000,0000,0000,,redirection: FAIL
Dialogue: 0,0:39:26.06,0:39:28.74,Default,,0000,0000,0000,,if you guys have any explanation for that, I'm all ears
Dialogue: 0,0:39:30.07,0:39:37.01,Default,,0000,0000,0000,,did you try redirecting to something else ? like, a COM
Dialogue: 0,0:39:37.09,0:39:38.67,Default,,0000,0000,0000,,oh, I didn't try
Dialogue: 0,0:39:42.01,0:39:44.36,Default,,0000,0000,0000,,so, you would pipe to another device, and ...
Dialogue: 0,0:39:44.69,0:39:46.07,Default,,0000,0000,0000,,but then, how do you get it back ?
Dialogue: 0,0:39:46.07,0:39:48.02,Default,,0000,0000,0000,,printer, or ...
Dialogue: 0,0:39:48.02,0:39:51.09,Default,,0000,0000,0000,,yeah, I don't have a COM device or...
Dialogue: 0,0:39:54.02,0:39:56.08,Default,,0000,0000,0000,,yeah, I don't know
Dialogue: 0,0:39:56.08,0:39:59.09,Default,,0000,0000,0000,,but it was a big surprise, because I had a test bench
Dialogue: 0,0:39:59.09,0:40:01.25,Default,,0000,0000,0000,,and then, 'FAIL'. .. uh ?
Dialogue: 0,0:40:02.05,0:40:05.95,Default,,0000,0000,0000,,run, OK... so, I have no idea why...
Dialogue: 0,0:40:07.02,0:40:07.98,Default,,0000,0000,0000,,the GS trick...
Dialogue: 0,0:40:09.07,0:40:10.38,Default,,0000,0000,0000,,quite simple
Dialogue: 0,0:40:10.39,0:40:15.33,Default,,0000,0000,0000,,and I also have some output
Dialogue: 0,0:40:19.06,0:40:21.08,Default,,0000,0000,0000,,I modified GS then it's reset
Dialogue: 0,0:40:21.08,0:40:23.06,Default,,0000,0000,0000,,then it's waited for result
Dialogue: 0,0:40:23.06,0:40:26.06,Default,,0000,0000,0000,,then I'm doing 2 resets and checking the time in between
Dialogue: 0,0:40:26.06,0:40:28.71,Default,,0000,0000,0000,,so that, it shouldn't happen too quickly
Dialogue: 0,0:40:30.00,0:40:31.32,Default,,0000,0000,0000,,NOPs, so...
Dialogue: 0,0:40:37.02,0:40:39.06,Default,,0000,0000,0000,,I'm testing the undocumented NOPs
Dialogue: 0,0:40:39.06,0:40:44.00,Default,,0000,0000,0000,,testing the NOP that are on invalid page
Dialogue: 0,0:40:53.85,0:40:55.24,Default,,0000,0000,0000,,so, standard NOP
Dialogue: 0,0:41:00.42,0:41:01.94,Default,,0000,0000,0000,,32b nop
Dialogue: 0,0:41:07.06,0:41:15.07,Default,,0000,0000,0000,,so, all my 64b tests are still done in 32b process so that you can run them on normal OS
Dialogue: 0,0:41:15.07,0:41:19.03,Default,,0000,0000,0000,,then it detects via GS if 64b [mode] is available
Dialogue: 0,0:41:19.03,0:41:21.07,Default,,0000,0000,0000,,and in this case, you would get a different result
Dialogue: 0,0:41:21.07,0:41:26.06,Default,,0000,0000,0000,,so, if you run it on 64b, which I don't have here, you would get
Dialogue: 0,0:41:26.06,0:41:28.07,Default,,0000,0000,0000,,the actual tests on 64b
Dialogue: 0,0:41:28.07,0:41:30.16,Default,,0000,0000,0000,,and the results printed out.
Dialogue: 0,0:41:31.02,0:41:35.02,Default,,0000,0000,0000,,but still, it's not possible to debug that easily [wrong]
Dialogue: 0,0:41:35.02,0:41:39.05,Default,,0000,0000,0000,,but at least, there's no trick over there, so it's easy to bring back to a 64b process
Dialogue: 0,0:41:39.05,0:41:43.31,Default,,0000,0000,0000,,[to step over 64b code and return to the 32b process]
Dialogue: 0,0:41:45.00,0:41:45.77,Default,,0000,0000,0000,,PUSH/RET
Dialogue: 0,0:41:48.04,0:41:50.58,Default,,0000,0000,0000,,you print the output, and then...
Dialogue: 0,0:41:52.02,0:41:56.88,Default,,0000,0000,0000,,Olly nicely tells you that you will jump to 401008
Dialogue: 0,0:41:58.00,0:42:03.08,Default,,0000,0000,0000,,but actually -- here the display is actually correct
Dialogue: 0,0:42:03.08,0:42:05.10,Default,,0000,0000,0000,,and the TLS already created a null page
Dialogue: 0,0:42:05.10,0:42:06.70,Default,,0000,0000,0000,,which prints 'FAIL'
Dialogue: 0,0:42:09.06,0:42:13.67,Default,,0000,0000,0000,,so, as expected, but there is no standard way to disassemble that correctly
Dialogue: 0,0:42:15.04,0:42:23.07,Default,,0000,0000,0000,,I can't execute the working 64k sections.
Dialogue: 0,0:42:23.07,0:42:27.08,Default,,0000,0000,0000,,and actually I'm executing all the code [the complete virtual space of all 64k sections]
Dialogue: 0,0:42:27.08,0:42:29.03,Default,,0000,0000,0000,,the sections are quite big
Dialogue: 0,0:42:29.03,0:42:32.44,Default,,0000,0000,0000,,and I'm modifying EAX so that all the 00 00 are executed
Dialogue: 0,0:42:32.44,0:42:35.07,Default,,0000,0000,0000,,and just to do a printf in the end.
Dialogue: 0,0:42:35.07,0:42:39.01,Default,,0000,0000,0000,,it actually takes a few seconds to execute on an i7
Dialogue: 0,0:42:39.01,0:42:43.01,Default,,0000,0000,0000,,so it's actually quite funny to see... you launch it... even when the cache is loaded,
Dialogue: 0,0:42:43.01,0:42:48.24,Default,,0000,0000,0000,,and the OS is ready to be fast... you launch it... and printf comes a few seconds later
Dialogue: 0,0:42:50.10,0:42:58.49,Default,,0000,0000,0000,,virtual sections is the one that Hiew doesn't think it's a PE at all -- this is the latest Hiew
Dialogue: 0,0:43:00.06,0:43:02.04,Default,,0000,0000,0000,,well, it's been patched anyway
Dialogue: 0,0:43:02.04,0:43:08.07,Default,,0000,0000,0000,,well, I can't browse PE now that it doesn't think it's a PE file...
Dialogue: 0,0:43:08.07,0:43:13.02,Default,,0000,0000,0000,,but basically, it thinks that the OPTIONAL_HEADER points to the end of the file -- beyond the end of
Dialogue: 0,0:43:13.02,0:43:14.05,Default,,0000,0000,0000,,the file
Dialogue: 0,0:43:14.05,0:43:15.08,Default,,0000,0000,0000,,the folded header...
Dialogue: 0,0:43:16.56,0:43:17.51,Default,,0000,0000,0000,,a few error messages...
Dialogue: 0,0:43:18.06,0:43:20.10,Default,,0000,0000,0000,,because of the wrong data directories
Dialogue: 0,0:43:20.10,0:43:22.90,Default,,0000,0000,0000,,and the actual DD are at the start of...
Dialogue: 0,0:43:30.02,0:43:31.36,Default,,0000,0000,0000,,...the section
Dialogue: 0,0:43:33.01,0:43:40.91,Default,,0000,0000,0000,,this would be the imports and the actual real DD
Dialogue: 0,0:43:42.05,0:43:48.67,Default,,0000,0000,0000,,and last, the one with the TLS AddressOfIndex that is pointing...
Dialogue: 0,0:43:57.52,0:44:01.42,Default,,0000,0000,0000,,...inside the imports, at the AddressOfName
Dialogue: 0,0:44:02.04,0:44:04.04,Default,,0000,0000,0000,,so it will overwrite the loading [overwrite the pointer during loading]
Dialogue: 0,0:44:04.04,0:44:11.09,Default,,0000,0000,0000,,and when you just load it, it just says 'it's XP' because
Dialogue: 0,0:44:11.09,0:44:14.07,Default,,0000,0000,0000,,my imports were loaded this way, and not the other way.
Dialogue: 0,0:44:14.07,0:44:17.02,Default,,0000,0000,0000,,and if you run that file [under W7], it will give you another results
Dialogue: 0,0:44:17.02,0:44:18.17,Default,,0000,0000,0000,,and then, the exports...
Dialogue: 0,0:44:19.06,0:44:24.06,Default,,0000,0000,0000,,where some of the exports are actually very long
Dialogue: 0,0:44:24.06,0:44:30.05,Default,,0000,0000,0000,,you can see that actually, here I'm taking over the disassembly
Dialogue: 0,0:44:30.05,0:44:33.10,Default,,0000,0000,0000,,so I'm repeating the same fake opcodes and address
Dialogue: 0,0:44:33.10,0:44:36.15,Default,,0000,0000,0000,,so you fool the disassembler that way
Dialogue: 0,0:44:37.06,0:44:40.05,Default,,0000,0000,0000,,I think it's just a visual effect, they are no big problems
Dialogue: 0,0:44:40.05,0:44:43.02,Default,,0000,0000,0000,,but it's a known problem that was fixed recently in IDA
Dialogue: 0,0:44:43.02,0:44:46.55,Default,,0000,0000,0000,,that if you put an export in the middle of the instruction
Dialogue: 0,0:44:46.55,0:44:49.08,Default,,0000,0000,0000,,the fake export will actually take over the disassembly,
Dialogue: 0,0:44:49.08,0:44:52.01,Default,,0000,0000,0000,,and that would ruin the disassembly
Dialogue: 0,0:44:52.01,0:44:56.13,Default,,0000,0000,0000,,there's actually a PoC for that in Corkami, of course
Dialogue: 0,0:44:57.20,0:44:59.50,Default,,0000,0000,0000,,so, that's all for the demos
Dialogue: 0,0:45:04.56,0:45:09.12,Default,,0000,0000,0000,,so, I wanted to know more about x86 and PE
Dialogue: 0,0:45:09.62,0:45:12.07,Default,,0000,0000,0000,,which are far from perfectly documented
Dialogue: 0,0:45:12.07,0:45:14.08,Default,,0000,0000,0000,,and are still not perfectly documented,
Dialogue: 0,0:45:14.08,0:45:18.05,Default,,0000,0000,0000,,but at least, I've been covering some parts of it,
Dialogue: 0,0:45:18.05,0:45:20.04,Default,,0000,0000,0000,,there are still some gray areas,
Dialogue: 0,0:45:20.04,0:45:23.49,Default,,0000,0000,0000,,but at least, every day, I'm just learning a bit more,
Dialogue: 0,0:45:23.49,0:45:25.84,Default,,0000,0000,0000,,and publishing my results and sharing them openly,
Dialogue: 0,0:45:27.30,0:45:31.08,Default,,0000,0000,0000,,like WinDbg, if you follow only the official documentations,
Dialogue: 0,0:45:31.70,0:45:36.02,Default,,0000,0000,0000,,you will only get bad results, with malwares and packers out there,
Dialogue: 0,0:45:36.02,0:45:40.06,Default,,0000,0000,0000,,if you - yourself - are interested, or you develop a tool, an emulator, an engine, whatever...
Dialogue: 0,0:45:40.06,0:45:44.06,Default,,0000,0000,0000,,well you know you can just visit Corkami, read the pages,
Dialogue: 0,0:45:44.06,0:45:48.02,Default,,0000,0000,0000,,download the PoCs, which are [freely] available,
Dialogue: 0,0:45:48.02,0:45:50.08,Default,,0000,0000,0000,,and if you find any bugs - which might happen,
Dialogue: 0,0:45:50.08,0:45:54.27,Default,,0000,0000,0000,,then send me a postcard, or a red-cross T-shirt
Dialogue: 0,0:45:57.01,0:46:01.08,Default,,0000,0000,0000,,Thanks to Peter Ferrie, and all my reviewers, and people who contributed...
Dialogue: 0,0:46:01.08,0:46:02.25,Default,,0000,0000,0000,,do you have any questions ?
Dialogue: 0,0:46:03.07,0:46:10.08,Default,,0000,0000,0000,,did you ran them through AVs - antivirus scanners? you would find a sh*tload of 0days
Dialogue: 0,0:46:10.08,0:46:21.73,Default,,0000,0000,0000,,no, then, I wouldn't be good to actually turn them into exploits or anything, so...
Dialogue: 0,0:46:23.10,0:46:29.00,Default,,0000,0000,0000,,already breaking all the disassemblers and stuff was good enough for me
Dialogue: 0,0:46:29.00,0:46:32.79,Default,,0000,0000,0000,,I found a crash in Intel XED, which was good enough
Dialogue: 0,0:46:40.02,0:46:43.58,Default,,0000,0000,0000,,any other question? everybody survived the presentation?
Dialogue: 0,0:46:45.00,0:46:46.55,Default,,0000,0000,0000,,it's a great talk, man
Dialogue: 0,0:46:46.64,0:46:47.61,Default,,0000,0000,0000,,thank you!
Dialogue: 0,0:46:48.02,0:46:50.07,Default,,0000,0000,0000,,THANK YOU! [for watching]