 That's it, without further ado, Cameron Hodgkes. All right, thanks everybody for showing up this early in the morning. My name is Cameron Hodgkes and I will be presenting basics to OSX reverse engineering. Who I am, I work at Tipping Points DV Labs. Part of my job is to work with the vulnerability research team, work on the ZDI team, so we do patch analysis, product security, reverse engineering of various formats. I do a lot of the Apple stuff, and we have our blog that I'm required to tell you all to check out. I write the line noise if anybody reads that. I also, in the past, have written and contributed to PiMay, if you've done any reversing or you use open RCE, that's Pedram's baby, and I worked on that a little bit. Farther back in the past, I wrote Absinth, which is a SQL injection tool, but I don't really do the web stuff anymore, that's sort of an old thing if you're like, hey, I think I saw that guy one time. But I also have a side project that I'm trying to push, like, crack on everybody who's interested in OSX reversing, which I think is everybody in this room, either that or you're just looking for a quiet place to sit down. But if you are interested in the stuff I'm talking about, I have the XSO mailing list, and there's a lot of really talented, smart people that are on that list. It's very low traffic, but if you have any questions, everybody's fairly friendly and can help you out with OSX specific reversing stuff. So this is roughly the format I'm gonna go through, the stuff I'm gonna cover. Basic stuff on file formats, which is the Mako file format. I'm not gonna spend a lot of time on that because you're not gonna spend a lot of time working with that, for the most part. Various tools that are available for reverse engineers on OSX or people who are just reversing OSX stuff, you'll figure out why I'm clarifying that. And then I'll go into common disassembly patterns, which is always helpful to look at if you've never looked at any of these binaries before. Cover carbon and object to C, which is gonna be the bulk of it, and then get onto a little bit on iPhones so everybody can be like, yay, I learned about iPhone stuff. So on OSX, how many people actually here use OSX regularly? Like we're all Apple users, okay. So I'm sorry if I'm gonna be talking down to you for the next little bit, and you're like, dude, I know what you're talking about, but it needs to be covered. App bundles, and for the three people who aren't Apple users, what they are, it's a file folder structure where the actual applications are stored with all the extra libraries and images and graphics and whatnot. And those are referred to as bundles or packages. Finder will treat that as like its own single entity, this atomic thing, and when it's really a folder structure, and you already know probably all of that. But this is what an app bundle will look like for the most part. You'll have a top-level program, which will be the directory structure Finder hides, the .app extension. Underneath that, you have the contents directory sitting by itself. And inside of the contents directory, you have the package info file, anything gray is a file, anything white is a directory, just in case you're curious. MacOS is the directory, and inside of that you have program, which is gonna be the same name as the Finder, or the app bundle name without the .app. Usually, it doesn't have to be, but for the most of the time, people will do the same thing. Resources, it's where you put your Nib files and PNG files, et cetera. Frameworks, plugins, shared frameworks, shared support. They're all optional directories, but they may end up in those directory structures. If you're just going straight for binary reversing and you don't care about all the supporting data, you're just gonna go straight to the MacOS directory and take a look at the program binary. So the info P-list file, which you can see is right underneath package info, the info P-list file is gonna store a lot of the application-specific properties. It has data, such as the version numbers, icon names, anything that's supporting that you might wanna change really quickly without having to recompile the binary. It's been fairly well documented by Apple, so I'm not gonna spend a lot of time covering it right now. The one thing is a lot of people are like, this is an XML file. It isn't always going to be an XML file. Sometimes it's going to be a binary file, but for that you have the PLU till, and that will just convert between the binary version and the XML version so then it can become the XML version that your friend told you it always was, and you'll know secretly in your heart that it isn't. But just a little hint that Apple, some of the people at Apple are still kind of like that old school, UNIX crazy people. If you go man, the PLU till utility, or check out the man pages right at the bottom, there's just this little thing, it's like the PLU till command obeys no one's rules but its own. It's sort of a non sequitur right at the bottom there, but you're like, okay, they're crazy. Package Info is another supporting file that's going to, in theory, have metadata, but it's usually only going to be eight bytes long. It's going to have APVL and a signature. So it's there, you're probably never going to use it. Now when you get into that Mac OS, Condense Directory, you're going to be looking at a Maco file format file. This is a standard binary format on OSX. It has the feed face magic number. If you're on a 64 bit platform, it's going to be feedfacf, which is just identifying that you're dealing with a 64 bit. Now there's the fat universal binary. So when Apple switched over to using the Intel chip set, they started putting both the PPC and the X86 code into the binaries together. And so they're just referred to the fat ones and they're identified by Cafe Babe. Now, Cafe Babe, it's also used in Java. So you're just like, how am I supposed to know the difference? You don't really need to know the difference though. Figure it out on its own. But the interesting thing about Maco binaries is that you want to be really careful when you Google for extra information on it. I'd say put site colon apple.com or something similar that you trust because otherwise you just get the most random screwed up stuff such as that. I read that paper. It was like a 12 page academic paper and I read it about three times. I still have no idea what the hell it was about. I think it was one of those auto-generated ones. But the Cafe Babe thing coming from Java, it's not actually from Java. Java, it actually came after the Maco file format and I'll get into that in the history of Objective C stuff later. But if you're looking at the Maco file format, it's changed and adapted over the years. Some of it's gonna be fairly constant. You have dot text, which if you're used to Windows, it's gonna, same as underscore, underscore text. And there's some stuff that's slowly been deprecated and removed and now is just not mentioned anywhere as if it never existed. So if you find really, really old docs, anything with the asterisks here is going to be older stuff that's not really relevant anymore. But if you're looking at old binaries, maybe some next step binaries, then these may very well be in the binary. So they're pretty straightforward. You have the code stored in the tag section. You have the constant stored in the constant section, static constant stored in the static constant section and so on and so on all the way through it. In the data section, that's where you're gonna have your variables, your symbol pointers, your constructors. So it's pretty straightforward as well. If you're using any modern disassembler, then it'll sort all this stuff out for you. This is the part that you actually want to pay attention to at one second. The Objective C segment is going to be storing, if you're looking at an Objective C binary, which is gonna be a lot of the binaries on Apple stuff, they're made by third parties, then a lot of metadata is stored in the Objective C segment. A lot of stuff is passed around by strings, so they need to store the string somewhere for reference. Now, if you look at any documentation from Apple, they'll say all sections in the Objective C segment, including old sections that are no longer used, future sections, whatever, they're reserved for the Objective C compiler's use. So what they're saying is you're good luck, you're on your own, we're not gonna tell you what they mean. Luckily, they're fairly decently named, so you can figure out their purpose, and the structure is a little weird if you're coming from somewhere else, but most of that's also documented. I have a Python script that's included on the Defcon CD that will rebuild a lot of this for you, so you don't have to worry about it, but if you're curious about the structure of it, you can take a look at the Python script. Now, this doesn't really fit anywhere else in the talk, but Tiller, when I was hanging out with him in Montreal, was talking to me as like, dude, you should put this in your slides. What this is, is VMMap is a tool available on OSX for mapping the binary at runtime, just to figure out where the memory is laid out. There's different tools on different platforms, this happens to be the one on OSX. Just out of curiosity, was anybody at Tiller and Dave's talk earlier? A few of you. If you missed it, what they did is they presented on retrace, and I'll get to that in a little bit, but you should definitely check out the slides because they did some really interesting work there. So, if you're on OSX doing some work, you're gonna need a hex editor. I've got a couple I'm gonna show you. Hexer is one that's written by Dynamics, formerly Saver, the same guys who do Bindiff. SB threw this together, and it's a fairly nice hex editor for OSX. It has a pretty solid architecture for building plugins and scripts. If you've used 010 editor on Windows, you can build very similar structures in either Ruby, Java, and Python, I believe, in the scripting architecture for Hexer. And if you ever have a question or bug report, SP will probably answer you by the end of the day. Hexveen is another one that the Modestano guys pointed out about a year ago, I believe, and they asked him to open source it, and he did open source it. At that point, I think he stopped maintaining it, so it's an open source hex editor. It handles really large files fairly well, and it runs natively on OSX, so if you just wanna mess around with that, it's available there. OXED, yet another one takes plugins. You're like, are you really gonna show me hex editors for the whole presentation? And the answer is, now I'm gonna stop now. I'm gonna move on to some real stuff. O-Tool, this is what a lot of people sort of started using when they were reverse engineering binaries on OSX. Some of the people who've been doing it for longer, they're fairly comfortable with it. But it gives you AT&T, no, yes. AT&T syntax disassembles all of the binaries. It's like object dump, except they call it O-Tool. And you can list the libraries like you could in object dump. And the problem with O-Tool is that it's just straight disassembly. There's a lot of very, very basic stuff you could put together, and somebody did it. And O-TX is that tool. I've colored it in blue, so you can see. If you don't know Objective-C, this is probably meaningless to you, but don't worry, I'm gonna give you a crash course in Objective-C in about three minutes. But you can see the strings being dereferenced, the alloc here, the NSMU to pull array. So if you know Objective-C, you're like, oh, cool, that just saved me the 30 seconds that it would take to figure it out on my own. But it works fairly fast, and it just takes the output of O-Tool. So you can pick it up there. Class dump, that's gonna dump the headers for you. Now, when I say the Objective-C stores a lot of metadata about the binaries, I mean, there's a shitload of metadata in the binaries. And you can rebuild, you can dump all of the headers out, and that's what class dump's there for. So if you wanna build, if you wanna take a library that's not really documented anywhere, you just run class dump on it, and it'll give you the straight up code to interface with all that stuff. This one little snippet to find something that would fit on a slide took about 20 minutes just because of the verbose-ness of all the information it's giving you, so it's pretty cool for that stuff. Now you're like, Cam, you've gone crazy. IDA, that's a Windows tool, we're all Mac users. IDA, I use IDA on parallels. I came from a Windows reverse engineering background. So I just run parallels. If you're running one instance of IDA, it'll be fairly stable. If you run two, then it looks roughly like this, and it starts to choke up. But we've got two, we'll get to those in a little bit. But for the most part, some people like O-Tool, I like a lot more information, and I like to add all the features that IDA has. And I'm really comfortable scripting and writing plugins on IDA. So I'll generally use it there. Now the second bullet point says IDA Pro for OSX runs on the console. It does. I have the 5.3 version, so the most recent version. It's really buggy. If you're creating, like just D words, it'll get segfault on you. And so for the most part, unless I'm gonna run it in batch mode, I'll, you keep using IDA on Windows. So there's IDA, there's parallels. This isn't new to most of you guys. They're not free, but easily worth the money if you're gonna be doing this seriously. And then debuggers, this is one of the short, this is one of the weaker aspects of reversing on OSX. Nobody I've talked to has really settled on one that they're like, dude, this is totally awesome. They're like, it kind of works and it fixes this one problem that's on their debugger head. But Charlie Miller ported PyDebug to OSX a while ago, which is the PyMay scriptable Python debugger. Obviously, GDB is gonna be on your stock install. When I say stock install, that means stock install with Xcode. Does anybody here not know what Xcode is? All right, cool. If I can save that 30 seconds. So PyGDB, which is another Python interface through GDB is available on Google code. Vtrace, yet another debugger, it's available at Kenshoto. And Tiller and Dave, the guys who were presenting earlier, I don't know if they released it today or they will be releasing it shortly or if you just have to email them and they'll send it to you. But they have Redbug, which is a Ruby scriptable debugger as well that's set to interface with the retrace set of tools. End of the day. Okay, that's cool. And end of the day, this is probably where you're gonna wanna go get it, pop-pop-ret.org. Retrace, what retrace is, is a Ruby framework to interact with detrace. And I'm not gonna spend a lot of time on it because you have all of their slides and they wrote a really good white paper so you can take a look at that after the fact. But it's just basically scripting detrace. So we're into the Objective C portion of the talk. I think I'm talking extremely fast, I am. Okay, I'm just gonna stand here for a second and stare at you. That guy. That guy got me a Red Bull right beforehand, which was a bad idea. Okay, Objective C is, or we're not even there, we're in the Calling Convention part. I'm not talking that fast. Okay, Calling Conventions. I saw Objective C and I panicked. The Calling Conventions are standard call which is going to be pushing the variables onto the stack except it's not pushing them. It preallocates the stack space. So if you're used to push, push, push, call, it's doing the exact same thing but it's preallocated so you can see right in the middle here you've got var98 which is actually just ESP with no modifier and then 94 which is the plus four. And so it's just putting it on the stack space and it'll call message send in this case and it takes care of all of that. Now the first tendency as somebody using IDA would be to write a quick script to rename all of these variables but it will allocate all the stack space and then possibly later allocate further stack space so there's a little hiccup into the naming scheme. Once again, I've already done that in the Python script that's included. Just so you know I'm not lying to you. Oh, totally lying to you. No, it's right here. Like this is the thing. It's just basically a scratch pad for stuff I've noticed when I've been working on this. So that's the only major difference between various other binaries that are using standard call. So just whatever you do before you rename them check the stack delta and as you should be good to go. Now in pretty much every OSX binary it's set up to be using position independent code. So you're going to be seeing this like EVX value that's all over the place. Now, just out of curiosity, how many people do you use IDA for reversing purposes? Couple of you guys. So the rest of you, if you don't have IDA then and you start to get IDA you're going to get version 5.3 which fixes this but for the four of you guys probably using 5.2 or older I'm going to keep going. EVX is the position independent anchor point. So it's just basically, it's not the start of the function it's just a random address in the function and they use that to reference all of the other position independent code or like the data that it's going to be referring to. EVX is most frequently, I don't think I've ever seen anything that's not EVX but I'm not going to say it won't be because I don't want you to like wake up six months from now and be like, yeah you lied to me, which I might. But there's two ways to generate the anchor. The first one is it's going to call up a function. I just call it getPC because that's what it's doing. It's going to probably be sub 90476 when you see it. All it's doing is moving the stack, de-referencing the stack pointer, moving it into EVX and returning which is just going to be the return address which is the exact same as calling five and popping EVX because the value would have been stored into EVX. If you've done any shell code the second half, the second version looks a lot very familiar because it's using a lot of shell code. This was all fixed in IDA-53. I wrote a script to fix it and I was working on a plugin to fix it and then ILFAC fixed it himself so you don't need any of my tools for this. And his works faster. So you can see at the top of this you have the call plus five, the pop EVX. That's saying that EVX is going to be the 1D06 variable or 1D06 address. Value, what not. And then later on, where is it? I can't even see it here. This was probably a bad example. No, you can see it. You can see the init. This is where the text is coming from. The EVX plus 13.16 in hex is actually a string to the NS auto release pool selector that's being called later. And depending on where it is in the binary it's either going to be just a small little value or it'll be this massive D word that's pulled from another section. Now there's two main ways of writing or there's two main frameworks for writing code on OSX systems. Carbon is the C, C plus plus based framework that's going to be used. It was descended from the original Mac toolbox. So this is the point where I asked how long you guys have been using Mac. So how many guys have been using Mac since they were actually next step machines? Okay, a couple of you guys. You guys are gonna be, feel free to correct me if I'm ever talking smack on this section because I'm not much of a carbon coder. Now, do we have many carbon programmers in the house? That guy? All right, do we have any objective C programmers in the house? All right, a couple more. So carbon is the C, C plus plus stuff. It's the stuff Windows programmers feel most comfortable moving to because they don't have to learn another language. Apple in there, all their documentation really encourages you to keep on trucking over to the cocoa objective C world. But a lot of people in their attempt to get stuff ported over quickly will be using cocoa or Pogre applications are written in cocoa. But there's usually a two letter prefix on framework libraries, so H, I, and C, G is going like they're very common. That'll indicate that they're probably written in carbon. Objective C, which is what I program in mainly now is created in the 80s by Stepstone. Then it was popularized by Next. So the five guys who were using Next in the late 80s remember this stuff, the original version, do you, my believe, was written in it. And it was inspired by Smalltalk. And so it's a set of decorators on top of C, which means they change it around. People, you start to try and explain to them, they're like, oh, it's like C plus plus and you're like, no, not really. But the functions aren't called. It's a message sending architecture. So when you see all these strings that I was showing you earlier that are just scattered around the binary, instead of having a direct cross-reference to those functions, it's going to pass in that string and the underlying system will go through and figure out which function you're actually trying to call and translate it. Unicode strings are standardized, but it's generally like two byte Unicodes are supposed to be standardized, but it's actually stored internally for the most part as Nelterminated UTF-8 strings, which is Unicode, but it looks like a standard C. Libraries are referred to as frameworks, so I keep dropping that name now you know what I was talking about. Now, Objective C has a lot of framework classes to call from, it's like other managed languages like .NET or Java, where there's a whole huge set of frameworks that are all built together. The common framework classes, they all have the NS or CF-prepended. NS is actually the Objective C stuff and CF might be derived from some of the other carbon like C++ stuff, but pretty much every, it's standardized that every framework is going to have a two capital letter prefix. And people will use Cocoa and Objective C interchangeably. The system API for OSX is actually what Cocoa is. AppKit is the set of GUI framework classes available on Cocoa. If you're working on the iPhone, it's going to be UIKit, which is a scaled down, slightly different, some totally different controls, custom libraries. So AppKit will be using the NS prefix and UI will be using UI. Now, you're probably wondering why I'm giving a crash course into Objective C programming if you're reverse engineering and not engineering, but it makes a huge difference if you understand what the original code was probably going to look like. And then when you see it in the binary, it's very easy to go backwards to what you think it might've been. So here's your super basic lesson in Objective C programming. You have your variable here X and then you have your statement, which is a method call. So you have the square brackets, which is your selector decorators, which is the way the Objective C compiler will identify an Objective C statement. And if you got a lot of arrays, C arrays and Objective C methods, all in top of each other, it gets kind of confusing. But it stands out fairly well. You've got the recipient, which is the blue object here. Now what that is, that's a pointer to any Objective C based object. And then we have the selectors, which are the text strings. It's very similar to named functions in various other scripting languages, like Python, except you can't mess around with the order. They always have to be in the same order, but they are there, so it makes it very easy to read Objective C code because you have to describe what's, you don't have to, you can have A, B, C and be a dick. But for the most part, people are going to describe what the actual variables are supposed to be doing. And then you have the arguments, obviously. So calls to these selectors are just basically taken and converted to this one function call. And this is, well, there's a couple versions of it, but this is the main function call that you're going to see in Objective C binaries. Now the problem with this is that if you've done any Ida work or various other disassembly work where the cross references are built up for you, you can do flow graphs, you can run Bindiff. You can't do it, because they're all calling that one function. So you have this awesome flow graph where everything calls message send and you're like, wow, that sucks. It does. But so what it does is it translates the square brackets into this message send call. So you can see here the recipient's still there and it's the first thing being passed in. The selectors are all combined together and they're separated by the colons. But you can still tell how many arguments they're going to be by the number of colons there are. And then you have the arguments, which is just an ellipse that it'll go on for as long as the arguments are being passed in. Message send super is another variation of the message send call. It's going to be very similar to the original message send call, but it's basically calling it on a super class. And so the big difference is it's passing in a pointer to this super and then it's the exact same with the rest of the arguments coming after it. And the return value is still passed in. It's going to be passed in through EX all the time, but it's still passed in the same way. Then you have floating point return value version of message send. Instead of passing a pointer back, it's going to pass a double back. You have the structure version. Now this is the one where it changes slightly because the return value that's coming back is actually going to be the first argument being passed into the function. And then after that, it repeats the same thing. And then super strat. Once again, I'm sure we can all figure out what that one is. I believe in you. So in assembly, this is what it's going to look like. I've described it, but you can see the selectors being passed in right here with the colon NSURL request. It's got a two capital letter prefix. So we all know that that's going to be one of the Objective C based framework classes. And this one's kind of weird because it sort of does it out of order, but I've added a script that will just go through and move these stuff around. So you've got A, which is going to be the return value being coming back through EAX. And so you can see NSURL, so it's a class method. It's not an instance method. And then it calls the selector URL with string with one argument, which is probably this one right here. And then it does it again for request with URL. But it's pretty straightforward because you can just see these Objective C message send calls. I usually rename these just so it's easier for me, but the message send calls, they just come one right after another. So you can imagine that if you're trying to trace this through, it's kind of a bitch because there's no way to double click. You have to go through and figure out where the URL with string function actually is. Luckily you can do that. So the suspense was killing you. But yes, all of this stuff is stored in the Objective C segment of the binary that I talked about earlier where all this metadata is stored. You can figure out that this is a download delegate class here and all of this stuff is stored in these structures. Depending on what version of IDA you're using, if you use it, it'll rebuild it for you. Or it's very, very easy to put together. You hit DD like three times in a row and then you're done. But for most OSX binaries with their Objective C stuff, you got an offset to the string, which is the actual selector string. You have an offset to these variable type arguments and you have an offset to the actual function itself. So if you know the name of the function and the function itself, it's really not that much more of a step to go through and name those. This is one of the really cool things about Objective C binaries and metadata is that there is all this information just waiting for you to go through and pull it out and screw with it. So some of the stuff you don't have, that you'd have on Windows, like cross references, you do have a ton of information being presented to you that will make your life a little bit easier. So instead of having to figure that this calls this and this calls this and this, I figured out this one does this and I traced these back, it'll just tell you, it's like, I think it's gonna download it and then the argument is gonna be the amount of data it received. Just a guess, because it says that's what it's doing. Sometimes double check, because some developers like to lie, but for the most part they're pretty trustworthy people. Now, if you look right here in this middle, there's this almost gibberish like thing, almost, it's a typing coding. And what that is is a collection of various characters that are used to indicate what kind of data types and how big the data types are that for the arguments and return value. So you can build up all the rest of it. So it's not only do you know you have two arguments, you know that one of them is a char and the other one's an id. Now id is this sort of concept of this, it's like a void pointer, but for object to see, saying that it's gonna be an object. So it's slightly a bit less ambiguous than void pointer, but roughly that's what it is. You have all the rest of the data types are assigned, you can identify that it's an array, a bit field, et cetera. This is straight from Apple's docs, I just put it in a nice latex table. So you can save your time if you wanna not look for it. So this is one of the type encodings from one of the previous examples. And first thing you're gonna see is return, which is a V. Cryptically it stands for void. The next thing being indicated is that there's an id here and so that means it's going to be an instance method. So it's not like you'll actually need the instance of the cocoa object being passed into the selector. Then you have the selector itself. There's always gonna be a colon in that case. The first argument is another at symbol, which is an id object. Second one is also an id object. This isn't the most cool, fun example, but it's pretty straightforward. So you also have these numbers, which I neglected to explain earlier. And what they are is stack offsets of where they are in the call stack or in being passed in. And you can use that if it's a data type that you're not really sure what size it is, but for the most part you're pretty sure what size it is because most pointers are going to be 32 bit in 32 bit architecture, which is the bulk of it and most integers are gonna be the same size after that. But the interesting thing is that you have this 16 that it starts with, and so that means 16 actually goes and lets you know that the last object is also gonna be four bytes. It doesn't mean anything else. I've asked around and nobody has any more insight to that. For memory management in Objective C, this is a way memories or objects are created. It's not a malloc-based, you don't call malloc directly from the Objective C stuff. You call malloc itself, which is a selector in it. It doesn't have to always be in it on the developer's choice on that one. But when you see these in the binary, that's what's going on. Release is the equivalent of free. Generally, it'll be, it's reference counting architecture. So release just decrements the references by one. And if you wanna add a reference so that it doesn't get automatically cleaned up, then retain is going to be what you call for that. And the thing, part of the Objective C runtime that's going to clean up all of these zero referenced objects is an auto-release pool for the most part. And so you'll see one of them declared at the beginning of a function. You'll see it released near the end or near any return statement if the code was written right. And it can be nested in loops. So if you see a pool getting allocated right at the beginning of a loop, you can try to find where that same pool would be getting released. And that'll help you figure out where the end of the loop is probably gonna be. So I'm just showing you the Objective C stuff, but it's pretty straightforward because you just have the same text strings all over in the binaries to save you the time. Garbage collection, this was added in OSX 10.5, the most recent version. And I haven't seen it used very much yet, but you'll probably start to see it used a little bit more because then people don't have to worry about calling release and retain as much. And developers tend to be really lazy. I know I did that for a while and I am lazy. So classes designed for garbage collection, they have a finalized selector somewhere in their class definitions. That's sort of your big tip off right there. So you're like, okay, there's gonna be, I'm not gonna really need to look for any of the other memory allocation stuff. They can be triggered by collect exhaustively, collect if needed. So those are also gonna indicate garbage collections going on. Those are probably a little bit more trustworthy than finalized because finalized is one word and maybe people wanna use it just so that the code knows that they're serious. Garbage collection is not available on the iPhone. So if you see it on an iPhone binary, they're lying to you and it's something else. And the iPhone developers are liars. Trust me on that one. But categories, this is one of those really crazy things that you really need to pay attention to at this point. A lot of the times, I've seen like three or four people write the same scripts I've written in IDA because it really doesn't take that much extra time to figure it out. But if you don't wanna spend the time, you can use one of the few ones that I show you at the end. But for some reason, when people start taking the metadata and renaming functions, they always pick the category section of the Object to See first. I'm gonna go right back and show you the Object to See sections and so you can see what the hell I'm talking about. Right here, third one down is cat class methods. Fourth one down is cat ints methods. These are the categories. Now, the structure is almost identical to, I don't know, way too far. The structure is almost identical to the other, the regular classes and the way that stuff's laid out. But the big thing is that a category is somebody overriding a class that they didn't write themselves. So you do the category to overwrite NSString, which is the default string type. And let's say you create a category for the string length and you have it return the string length plus seven just because you wanna screw with anybody who wants to know the length of your string and you're just kind of a jerk. Well, if you go through, and it's still gonna be called length. So in the metadata, it's gonna say length. You go through and you rename everything. You're like, oh, that's the string length. I don't really care what that is. So categories, pay attention to that because there's something extra going on and it's somebody messing with somebody else's code. So there might be some interesting stuff that you can find in those. But you can, let's see. Yeah, so it's just gonna be in the cat sections of the binary. If you're renaming stuff, keep that in mind. Maybe put a cat or some other symbol that's gonna be in the name. So you know when you're going through it later that, okay, there's something extra weird going on. Timers, this is probably only interesting to people who crack software. I'm talking about the people that crack software and totally pay for it afterwards because we're all honest. He knows what I'm talking about. So they're commonly used in protection schemes. Objective C supports various ways to create a timer. You'll see NS Timer with NS Threading Stuff or you'll see it with NS Operation Queue. This is a new one that's been added in 10.5 as well. And if you see these going on, it's pretty obvious what NS Timer is. NS Operation Queue is very frequently used with timers. Now, I mentioned I came from a Windows background and the one benefit with Windows that there's been decades of people well, I don't know if it's really been decades. It's like since 95, right? But a decade, a while of people doing RCE on Windows, there's a lot of documentation. There's a lot of various advances that people have been doing over the years. And they're very public about it. A lot of the Crag Me sites are gonna be primarily Windows-based Crag Me sites, all of the docs that people are still doing. You look on Open RCE, you'll find the obscure ARM post and then most of them are just gonna be Windows-based stuff. The interesting thing with Mac stuff is that now, like the fact that I filled this room means that there's a lot more people starting to pay attention to Mac and it's not just on our side, it's on the development side. So some guy walks up to their Windows developers and be like, oh, we totally need a Mac version of our product. And you need to write it and they're just like, oh shit, I don't know anything about writing for Mac products. So usually they're gonna switch over and write to Carbon. And you're gonna see a lot of really weird stuff, unless they move in the other direction because you work for Apple and they're like, we totally need Safari on Windows because that makes sense. But I don't work for Apple in case you picked up on that. But there's gonna be various stuff that's ported over. You can tell it's a Windows app because we know who develops Objective C, who here has developed Windows code in Visual C, something like that, like real apps before. I mean real Windows, I don't know what I'm saying, OSX are not real. Okay, so you got a bunch of people, you know HWND, it's all over any Windows code? Yeah, it's not a Mac thing. So if you see HWND, variables and functions with that named in there, ChangesArt was a Windows guy and he's just learning how to code for OSX right now. So take a little closer look because he's probably done some really other interesting, fun stuff that makes no sense. Now, there's benefits for looking at Mac executables. Compression and executables aren't really that common on OSX, they're not as common as they are on Windows. I have coworkers that recently busted into the Disney's Pirates of the Caribbean game. You can see their videos on YouTube and then like a million teenagers being OMG hacks, show me hows. But the one, they spent about three, four days just making this really nice unpacker for the Disney stuff. And I'm like, dude, check it out, there's no packing on the OSX version. And they just, the look they shot me was just like, oh, they were not pleasantly happy. I thought it was funny though. Cause we at one point, we all used apples and I'm the only guy left. But, yay for the Apple guy. So as I mentioned, you can easily identify a lot of the Windows stuff that's been ported over, like the HW and D stuff. And if there is a Windows version, don't be afraid to look at that as well because that's just yet another source of information that you can pull from. They're not gonna be identical. A good example is QuickTime. QuickTime for Windows and QuickTime for Apple are fairly different animals. So there's gonna be some weird stuff you find in QuickTime for Windows, but that's only cause it was moved in the other direction. But you can find relative structures and you can get an idea of what it was going for, especially if it was like the code that somebody just forced to work on the other platform. So try looking at both of them because it'll just give you more of an idea of what's going on. So now we're in the iPhone section of the talk, just in time. I don't do a ton of home stuff. I actually just got my iPhone a few weeks ago. I was one of those guys who waited in line way too long. And I'm not the only one I saw the rest of you guys. But actually, is there anybody from the iPhone dev team here in the audience? That's too bad. Okay, I'll have a link to these guys. These are the guys who jail-braked the iPhone. They do a lot of the iPhone research. They do some bad-ass stuff. They're pretty sharp guys. I wanted to applaud them if they're here. We can applaud them if they're not here, but it's sort of me. The amount of stuff that's come from that is pretty impressive. Now, the iPhone, it's an ARM chipset, as opposed to the PPC and X86 that you're gonna be looking at on regular Macs. It's Objective-C applications, so that's why I still covered all that stuff. And it uses UIKit instead of AppKit, which means you're gonna be dealing with slightly different controls when you're looking at the binaries. The biggest thing is gonna be ARM. If you don't know ARM, then you're just gonna be like, wow, this is fucked up. If you do know ARM, you're like, dude, that's easy. But so the bundles. Now, I said I wasn't gonna lie to you. I was totally lying when I said that, so you gotta conundrum, because the bundles I showed you earlier, they don't apply to the iPhone. The iPhone flattened the whole directory structure. So if you're used to looking at nicely organized bundles and you're like, oh, I don't even have to worry about all the graphics being in the same area. No, it's all there, so you just like, it's just this giant clusterfuck of files all in one directory. And they have the code signature in there. It's really easy, though, for every, I haven't seen an iPhone app that has a different name for the binary than for the actual folder structure. And you can always use file just to tell what it is. But the Objective-C sections, my previous slide that had the documented sections, that was before I got an iPhone. The Objective-C sections doesn't really look the same and isn't quite handled the same. So the names don't quite line up exactly. I'll be spending tomorrow, instead of chilling at the hard rock, I'll be writing, updating my script for you guys for Monday. So I should have some stuff to clean up some of the iPhone binaries by Monday. And the other thing is, Apple really hasn't standardized anything here. I was hanging out with a couple of the Apple security guys at Black Hat, and I was basically bitching at them. Like, dude, this makes my job far more pain in the ass. And like, first off, that we don't care. Second off, it's a moving target. So Apple still hasn't quite figured out the structure they want for all of these files yet, so they're still changing it from patch to patch. But when in doubt, refer to the iPhone dev team. They have a wiki app, which I'll link to, and if they don't have the information, then if you figure it out, put it on the wiki. So this is, we've hit the end of my talk, and you're like, dude, that was all you're saying, but iPhone's on my, yeah, kind of a jerk. But this is a couple of links to get you started with. If you, and I can't not say this link, the first link, if you've ever seen any OSX talk, you gotta give props to Nemo. Nemo was doing stuff when nobody else was. He was working in a vacuum, and it was a sad life, and he gets all the respect finally years later. But that's who we should also applaud. So big ups for Nemo, he's not here right now, but he was doing a lot of this work years and years and years ago. So I can't not mention him. It's me, wrote an Objective-C fixer upper script in IDC. So I was talking about mine, and this is a separate one, it works just as well. File offset also did the same thing. Went through OTX and wrote a Lewis script that will convert the OTX output and stick it into IDC and stick that in IDA. So we all take different approaches for the same thing. Then there's a couple other Objective-C based reversing or just Objective-C coding debugging sites that are out there. And then you have the iPhone Dev team. So you have the blog.iphone.dev, which is just gonna keep their up to date, and then their wiki at the bottom. And they did release a new jailbreak for any of you guys who accidentally updated it earlier this week, you should be able to fix your phone. And the other thing that I'm really excited coming out soon is Dino and Charlie, the guys who have won the CanSec West Pwn to Own contest. Charlie took out the MacBook this year on the second day in the first 35 seconds. So he knows a little bit about exploiting stuff. He has Feng Shui ported to the iPhone, so your iPhone is totally not safe, even though there's not a huge memory footprint. You're like, you couldn't heave spray me. He's kind of screwed you. But they're writing a book, and it's gonna cover reverse engineering. It's gonna cover exploitation. It's like Shellcode is handbook for Apple users by two really smart guys. So, and they're gonna be releasing a tool when this book comes out to fix that cross-references problem that I was talking about. He basically took Chrissy Eagle's emulator and just went ninja on it and made it rebuild all the cross-references. So that'll come out at the same time, so I can't not pimp them. So that's the both of my talk. I will be available for Q and A right across the hall right after this, but thank you guys for showing up. Really appreciate it. Thank you.