WinDbg Basics for Malware Analysis

[Music] and welcome to open announcer slide so as you can probably tell today's episode is a little bit different from what we were doing in the past I have a special guest here and we're going to do today is we're going to talk about window bug and we're gonna talk about sort of the basics of how to set it up how to start debugging with it and if you guys aren't familiar with X 6040 bug which we use in most of our tutorials we're gonna kind of try to show you guys side by side if you're familiar with like 6040 bugs sorta how to do the same things in window bug and this is going to be sort of the first in a series of possibly two tutorials two or three depending on how this goes where we go a little bit deeper into bugging into the kernel but for this episode we're just going to do sort of initial how to set up when the bug had a big bug stuff with it how to navigate around so joining me today is Josh this is the third time we've tried to record with chocolate technical difficulties have thanks for coming here yeah so I've been doing reverse engineering for a few years now but I do malware analysis full time out and we actually worked together full disclosure which has been really really awesome as of recently and yeah effectively I've been doing a few talks here and there but I wanted to do a video tutorial for you guys today on window bug because I think it's a really useful tool especially when you start getting into areas that like things like x64 debug can't handle like transitioning from x86 to x64 code which we might do in a later video and a number of other reasons yeah I should also mention that when we first tried to record this I didn't actually work with Josh and I just met him at recon and we were talking with Trevor recording it and things went completely haywire hope you're doing it and Josh had to debug stuff live and I realized that he's actually like really good at debugging stuff so that's why that's why I had this quick good bugger yes what I wanted to just give you a brief background on it is what Wendy bug is why it seems to be important to use and why you should use it and why you probably hear about it a lot so there's a lot of people who are a lot better at using window bug than me but it's effectively like the fact that debugging interface for interfacing with the Windows operating systems so you'll see a lot of people like Alex E and s key you do debugging live and window bug and talks and things like that and I think the reason for this is just because it's effectively what Microsoft uses for debugging their content so I think a lot of people use it for exploit development during their exploit development process and for doing a lot of kernel debugging which I'm not really aware of many other commercial buggers or Frieda buggers that allow you to do that on Windows you'll often hear it called windbag I think that's mostly because of autocorrect I don't know why people call it that if you hear that in a conversation at a conference or whatever or talk they're probably talking about window bug so just give a brief overview of what the interface kind of looks like this is a workspace that I've customized with this fancy looking text usually it doesn't look as good when you initially open it but I can link this workspace in the bottom of this video but essentially what you want to take away here is when you open window bug it will effectively look like there are zero windows it will essentially look like this and this might be daunting at first because you'll basically usually just be given the command window and you can do everything you want in the command window but it will make visualizing memory and things like that a little bit more difficult which is why I like to set up the workspace properly with a bunch of different GUI windows so I'll just show you how to do that the first window obviously that I've already gone through is commands and if you want to open an executable click on this file menu and then go to open executable and then well let's just use notepad here is an example to start with and basically it'll give you a whole bunch of output right off the bat so there's a few tidbits that are really important here and I'll go into symbols work closely in a second here but basically what this is doing it's showing you all the module loads so these are all of the required modules that would be in the import table for no pet and then this is just showing as are loaded by the Windows loader itself and then there's some simple information associated with each of these modules and I'll show you how to resolve those symbols using the public symbols from Microsoft but just to give you a little bit of Mordy so here we have a breakpoint that is set it is a first transferring point those are exception related but we don't really have to go into that specifically today but basically when debug is set a breakpoint at this loader P do debugger break function within ntdll we've also gotten a dump of all the active registers here so since it's a x86 version of notepad then we get things like the IP and the stack pointer and stuff like that so that's kind of what things will look like we initially load it you can basically do everything from this window but as I said we want to set things up a little bit nicer if you want to add more windows it's very similar to like either any other debug interface where you can open additional windows from the view panel up here so here there's a bunch of different panels that we'll want to add some are more important than others so the first and I think probably one of the most important is memory so this will basically just show you the memory of the running process and you can adjust the formats for how the memory is displayed so currently it's in the byte format which is quite useful it's like the kind of xx Dao put of ASCII and hexadecimal and then the address to the left you can adjust that though to like be pure ASCII if you want to have it I don't know why you would want it in bits but II really wanted to and then yeah you can have like integers Unicode is also super useful but usually I'll leave most of my windows in bite just so you can see the ASCII representation and in the byte representation so there is some someone important syntax here scope IP is actually basically just gonna track the currency IP register and these are just some tactical things to help resolve the symbols quickly so this is what's referred to as a pseudo register so you can actually look up all the pseudo registers and in MSDN and this will basically show you each of the ones that will be within window bugs so if we go down to scope EIP basically the instruction pointer for the local context so I guess the local context is referred to as let's go just to give you some background there while we're here another really important suitor register is X entry which is essentially the entry point for the binary but before we go off in that tangent that's just kind of important to keep in mind for later so if we go back to this window we go back to our view panel let's look at a number of other important windows so on add registers so this is a will essentially just give you like a nicer register view similar to other debuggers so the current state of of all the registers cluding like the floating-point registers and all the flags that you would see in other debuggers and obviously flags are really important for things like jumps something to keep in mind then there's another super-important view which is disassembly so this will actually give you a linear disassembly of your current context or whatever you set this offset to be and so one important thing to note about the disassembly window that kind of bugs me i guess when i hate's window bug is that it's not really interactive in the same way that something like x64 debug is interactive where you can sort of I don't know click on jumps and follow the jumps and stuff like that it really is just kind of a view of the disassembly unfortunately so if you want to do something like follow a jump or something like that you'll have to actually copy that address and use it in the command which is I guess probably for me that's probably one of the hardest things getting used to with window bug I don't know if there's some plugins or something that make it more interactive but for me I guess that's probably just one heads up is if you're trying to click around to follow stuff it definitely doesn't work yeah I think like once you get used to the command lines and text and you can like you reference that occur in like yeah IP scope and stuff I got and then you can probably do it quickly in some fancy command-line ways but yeah when it comes to user accessibility at a baseline level I think x64 to bug ones there and yeah just one more note and I know I just mentioned this but this is linear sweep for the disassembly where I was something like Ida Pro which we will also be using today is recursive or they're just assembly techniques so it's not it's pretty primitive but it's it works for what we need it for so back to the windows if we look at it's a few more important ones things like call stack so I think this will actually try and resolve the call stack to symbols and based on return instructions I think it will attempt to resolve the call stack as well so this can be really useful when you have the actual assembles like if you are debugging a Windows application or if you have symbols from another manufacturer otherwise I think it will basically just try and try to unwind the stack as best as it can and then you have a whole bunch of useful headers here if you if you do have the debugging information like these are raw arguments which will basically just show you the first three arguments into that address regardless of whether or not they're valid and then I think there's like some additional header and different information that you can add here so a bunch of the other windows are quite important but I'll usually stack them on top of each other so like things like scratch pad it's literally just like a little notepad you can add so usual like stack this on top of calls and you can actually wants to do let me you can actually stack these on top of each other and then it'll open up these little tabs that you can go back and forth with I'll usually do that for Windows that I don't use as often that are not memory just assembly or command or registries other useful ones that I deem is like a little bit less important are the processes and threads window so like this will what's really awesome about window bug and I'll show you how to do it is you can actually like enable child process debugging so then you can actually debug multiple processes at the same time from the same window so then you can select different threads from this window here and different processes if you're debugging multiple processes and there's a few more that you can take a look at but that's basically what I use for malware analysis so one of the more interesting things that Josh showed me before was the way that the memory window actually works so in that little virtual box up at the top where we have the scope IP you can actually change that to be any address of course right and it'll show you the memory for that address and I noticed that like if we're trying to say mimic x64 debug I think Josh might have this one in workspace or something I'll show you in a minute but I just wanted to point out that like that memory went is basically like the same as the dump window in next 60/40 bug so you can look at any memory you want at all and you can have as many memory windows open as you want so you can have something sort of analogous to x64 debug where you have a bunch of different dump windows so if you want to follow a bunch of different memory segments it's quite simple to just open more and change that virtual address to be whatever address you want to follow again I think josh has that set up in his board space he's going to show you in a minute but it's definitely something if you're coming from x64 debug and you want to have that sort of setup which I find really useful for unpacking stuff to have all those memory view is open that memory window can be customized to show you anything you want basically yeah really useful memory address keep in one of these memory windows is the one of the stack pointer just because you'll want to keep track of arguments on the stack and everything like that so that's one example of one of the uses for a memory window at all times so yeah so I think we can get rid of this super ugly workspace that I've just created and then just open the one that I have pre-configured so if we open this again we essentially don't have many memory windows but we can add a few more and then they'll just snap in there like that which is really useful but I'm going to adjust these just because we are gonna be using the command window quite often and then we can get rid of stuff like scratch pad because but essentially this is very similar setup to how we had it before so as you can see the add syntax here is used to do you reference this register symbol and this will actually keep us within scope of the current stack pointers that will look very similar so if we open XQ here let's dive into some commands so and here we've actually used the pointer in symbol display format for memory and then it gives you like an actual nice if there's a symbol associated with the address then it will display them right here which is very similar to how something like x64 debug would work so now that we have this opens in window bug before we get into our actual commands I just want to show you how to resolve symbols for window bug because they are required for a whole bunch of different functionality within the debugger itself so if we just open our and prompt window here I'm just gonna clear out what we had before but basically if you go under C program files x86 windows kids 10 so this is this will differ based on your version of Windows so if you are using Windows 7 SDK then this path will differ debuggers x64 you will have this binary called sin check so just to back up a bit because some of you might not know what the Windows SDK is if you literally Google like SDK Windows 7 or SDK Windows 8.1 or SDK Windows 10 you can download this binary here if you go to download installer and then once that's downloaded it should let me select it yeah all you want to select in this window is debugging tools for Windows and you can deselect all the rest of this and then once you hit download it will install it and then you will have all your debugging tools under this path here so going back to actually resolving those symbols you have a SIM check Mint which will actually download and store the symbols for you at its best by path so they have some general examples here if you want to download symbols from Microsoft you can actually host your own symbol server or something like that if you'd really want to by just going back to how you would do that you can use simchah and specify a dll for which you want to resolve symbols and then you specify a path at which you want to download those symbols so in this case this is just the Microsoft symbol server over HTTP and then you specify a path to write those symbols to so in this case I'm just using C colon backslash symbols and once you hit enter these these symbols already downloaded but this will download the symbols for kernel 32 and then if it worked it will basically say passed plus ignored files equals to one one important note here is that obviously you're not going to have symbols for the malware sample paper analyzing by definitely for that Microsoft kilos that are being floated and of course that's really what we're downloading symbols for here and one thing to pay closer attention to is the difference between 86 86 and 60 or that dll's it's of course if you're on my 64-bit Windows system there's going to be two different sets of dll's ones for x86 execution so the 32-bit execution emmalin's for 64-bit make sure you download the correct DLL is for the correct type of malware that you're analyzing that's definitely bit me in the past as recently as the last time we recorded this video yeah and just to show you so the syslog 64 folder will give you the 32-bit version of each of those DLL is on a 64-bit Windows platform so if you want to specify which DLL to download the 32-bit symbols for then you can just specify the Cisco 64 pod and the 64-bit delos will reside under the normal system 32 path so for getting started the deal of that I'd suggest resolving the symbols for if you don't it download the symbols for every DLL say in the system 32 folder I would suggest getting ntdll because those are used by numbered for commands and window bug and then just getting kernel32 which will give you a large amount of symbols for functions that are often used by a different malware so this is really important to do ahead of time because you can actually make window bug automatically resolve symbols for any module that's loaded but obviously you don't want your Mountain alysus machine connected to the Internet when you are debugging malware unless around like a throw a VPS or something but I'll usually do my analysis on a disconnected machine so that's essentially just the symbols that's probably the most annoying part of using window bug it's just getting all of the school's results but once you do then things are quite ok and then once you have all the symbols results and you'll have a bunch of different commands that you can actually make use of so the first and probably some of the most important commands that I want to go over our break point commands so the first one that you'll want to set upon entry so obviously this is not the entry point of the firing question so if you want to do a break point on the entry point of the binary self thing you do bpx entry and then to continue it's actually g4 go and then that's essentially just a break point that's hit on the inch point of notepad here so that's a good tip for those of you for the next 60 40 bug you may just be used to X 60 40 bug automatically setting that breakpoint on the entry point to the loaded module or the loaded Exe when new bug doesn't do that right so when the bug is like running with scissors you can do whatever you want but they don't do it for you so pretty much every time you've load a binary you're gonna want to set a breakpoint on that entry point just let you end up at the entry point when you start debugging and then if we want to list the set breakpoints you do BL and then there's these little hyperlinks here and this will like actually do the commands for you but it's probably important to actually just try and do them yourself so it's faster CC which is great point clear and then specify the index to the breakpoint then you can actually do BC star obviously there's no more breakpoints set now and that will clear all breakpoints that you currently have for setting breakpoints on functions that we really actually care about you can just specify symbol itself so if we wanted to do a breakpoint on virtual a lock you just do VP virtual a lock obviously for most malware and packing we want to set a breakpoint on the return address of these functions so before that we can actually just we can navigate to the address of virtual a lock and this is assembly window and then we can just look up the return instruction for that function so this would be to suggest here and then set a breakpoint there you will actually do that when we are debugging real malware not notepad but I just want to show you a few more commands before we do that so really important stuff for getting the overall memory layout you can do a bang address and then this will just give you the general memory level one really useful thing you can do is actually specify bang address and then you provide an address so say I want to look up the memory information for our current instruction pointer address then this will actually give us base address of the module the end address so this will be useful for when we get like virtually a locked sections and then you get the memory permissions and then the type of the mapped image and all this information so it's really useful and then there's all these cool like little hyperlinks so if you do D H which is essentially the the header information for the portable executable this will all be dumped and kind of plain texture so that's super useful so if you guys are familiar with this setup from x64 debug so that's what Josh is just showing you with the bang address that's the same as saying a few memory map so where you're showing all those different allocated sections in the next 60 40 ugh this is just another way to do it basically do the same thing and with the buck yeah and then if we want to see the loaded modules for the current binary so obviously while we're debugging malware roll more often than not load additional modules and stuff like that so we can do LM which will essentially just list all the loading to yellows in memory and then whether or not we have resolved symbol information for each of those modules so in this case I've downloaded the symbol information for kernel32 and this is under that symbol path you can see here so it's called WW kernel32 because it's the syslog 64 or 32 bit version of that module and then you can see the ntdll one down here that we've also resolved the symbols for so this is really useful if you're like I don't know why this this symbol isn't resolving you can also list the modules this way so you can actually specify a module name so say this is kind of a lame example but if you do LM - m you can specify a string with a wild-card and then it will give you the modules with that associated with it then you can actually specify a memory offset so again if we just use the base dress of this then we can see the associated module with that address so let's take a look at actual symbols associated with said modules once we've resolved them we can use the X command for examining symbols of a specific modules so if we do X kernel32 bang virtual start then that will actually give us any virtual associated function symbol for eternal 32 module so this will actually you can see it there's like virtual protect in here these are they're just stubs I believe that's just because of this version of kernel32 and then this examining symbol information will also give you information as to whether or not there's like parameter information unfortunately with the Microsoft Windows versions of these symbol there's not a parameter information so it's quite frustrating but it's what they decided to do so so I think that's a pretty good overview of the modules and associated with those modules if you want to get things like call stack that would be in that call stack window you can UK you can also do fine stack which will basically look for a string within each stack of each thread it's quite useful it's a you're debugging like a whole bunch of different threads and you need to find like a certain function that's executing that's like writing a piece of unpacked memory or whatever you can search for a certain function within a certain thread here I just use internal 32 and it's and it's found that string and every single running thread there's one more thing that I wanted to cover so you can actually look at struct offsets and a bunch of other really useful things with the downloaded symbols as well so just as an example if we go to our memory window here and we specify notepad and it'll give us the P and as some of you may know a struct for the current PE header not the MZ header is image and T headers so if we actually specify the offset of the PE signature here so that is at 0 0 FD 0 f8 if we just copy that and specify our address at which that struct should resolve then we can just dereference that struct so really useful information for like obviously this is just a pietà in this instance but if there's a struck that's being returned by some function and it's really useful to be able to navigate the offsets of that structs using this DG command and then you can not like click on the struct offsets if they're resolved and you can like we could walk the whole p header just from like window bug itself which is pretty sweet so a few more things at like editing memory is pretty important so one like cool example that i found is for those of you who do not know the process environment block has a flag that is set when the process is being debugged and it's very common for malware to walk the process environment block and then try and see if that flag is set and then exit as an edgy bugging technique so if we want to set that flight to zero you can do like efore edit bite and you can specify dollar pet which is the process environment block and then the offset at which you want to edit the memory and then we can literally just set that to zero and then that will make it so that ng debugging trick no longer works so if we quickly pull up the pet in Wikipedia you guys can see the dial set to is actually the is debugged flag it's not to see here because you're just seeing an offset but if we see a visualization so basically you guys can see here so that's the structure of the process environment block and you can see that the second byte is this being debugged flag funny enough if you guys use things like silo hide or x64 debug this is one of the things that they do automatically for you is they killed that little flight there yeah so you can basically manipulate those structures any way you want from the debugger here you're simply writing to it awesome it's are just a few more things you can do things like restart and that will actually restart the running process you can also do all these things from the menu itself here so you know I was specifying that G command you can actually select to go from the menu here you can hit stop debugging here etc so let's actually open up a real peace malware and I'll show you things like stepping and another really useful debugging techniques so again we'll want to set a breakpoint at yet century is now we're running a real piece of malware you don't want it getting away on just to give you some backgrounds this is a sample from our traffic analysis that I used in a talk I did in September at besides and basically it is a crypto jacker spreader so I think it can be used for spreading anything it's just a specified situ a download an execution but at the time it was being used to spread a crypto jackin piece of malware which for those of you do not know is just a crypto minor running on somebody's machine without them knowing so if we could go here it'll actually be at the entry point and let's just take a quick look at this an idea because then we can get a better idea what we want to do with this so I'm just going to open it up and I'd appreciate it I just have the binary here and I will link to the Malheur traffic analysis post that this is from and specify exactly which fire it is but if we start looking at the strings for example things look pretty normal but there's not stuff like c2 etc that we want so if we go to really really common functions that are used for unpacking things like global outlook if we check out the opposite of global outlook here I knew this was used in the unpacking process ahead of time just because I had looked at the sample before but this is a really good example for something that we can unpack with window bug so if we look at global out here this is set to global variable was still Colette allocated memory for now just in case anybody missed that Josh was just looking at EAX and he just basically labelled the variable that e^x was moved into if you guys look up the definition for global a lock and MSDN you can see that it's a standard Windows API calls so that means the return variables can be stored in EAX so yeah I think we've showed this quite a few times in other videos but just in case anyone's new to this that's why you labeled that and then we see another really common call here of virtual protect of a parable this isn't a called virtual protector calling get proc address which will resolve the address of virtual protect and then they're putting that into a variable name so something really useful since we're you have I'd open is preface engrossed and function names with malware this is just really good for looking through things that you've already labeled that might not have already been automatically marked up by Ida so I'll just call it malware or virtual defect and then down here we can see that they're actually calling virtual protect with our allocated memory block and then they are calling that allocated memory blocks so this is really common to see with unpacker x' where they are writing piece of memory doing something with that memory and then jumping into it with the call instruction which is essentially like a jump so in previous videos we've called this self injection for lack of a better term well we showed you guys in other videos yeah this is a nice nice sample so what we'll want to do is since we already know this is going to be called we can actually just set breakpoints on these locations and then jump into the position independent code that's allocated by the unpacker here so to start with we can actually just set a breakpoint on this address luckily there's no a SLR with with this binary so it's the exact same address and window bug so we can so the end add breakpoint results properly so this one double check those into your caller and then if we go then we hit our breakpoint so kind of interesting here is this memory section is allocated here so say we wanted to like look up the memory information about that range then we can just hit our bang address command and then it'll give us the range for that memory so now at this point if we say we wanted to do full analysis of this piece of malware including the unpacking process then we would dump this to disk open and Ida and mark it up and figure out exactly how the unpacking is being done but what we really care about here is the final binary that we're going to extract so I actually know that this unpacker is going to call virtual Alec which is very often called by most Packers for allocation and memory so I'm just gonna set a breakpoint on virtual a lock and hit go and I know I should be setting this on the return address but in this case they're not checking for that but actually I kind of realized I haven't shown a single step in here just breakpoints so why don't we just single step into this so for that you can just hit f8 or you can use the debugging menu here but obviously you don't want to be opening this menu over and over again but step into you can use f8 so now we've jumped into that memory segment that we just looked up all the information about and we can single step through this so oh this is also very common so this is actually getting the process environment blog this is very common to see and unpacking as well where you'll see the malware itself manually do you referencing this offset so you get the process environment block and then it does a bunch of stuff through to resolve library addresses so that's a tip for you guys anytime you see that FS 30 hex and a piece of position independent code and then you see them start to dereference the pointers after they return or after they get that address FS 30 then you probably have found a place where they're doing some dynamic import resolution so that's probably where they're trying to resolve some api is dynamically usually what they do is they find an offset to kernel32 from the pad from the processing environment block and then they use that to actually resolve some api so they start calling them so yeah it has actually a dynamic resolution of functions that it needs but i am going to skip ahead just for for time sake so if we just say go we're gonna hit this virtual call and then you can actually do step out so step out is the same as run until return in x64 debug yeah exactly so if we look at ax here then we'll actually get the return address for this and since I did not set my workspace up properly I'm gonna add more memory windows and then I am going to get that address just in this memory here so that we can monitor it so now that we've actually done that I know that this is the unpacking function for the support of X Cuba so I'm actually going to set a breakpoint after this so let's just set the breakpoint on that raw address so BP and then that there and then but I am going to step into this because I just want to show you the unpacking process as it kind of unfolds so so this is a bunch of instructions that you can go through manually but I just wanted to go through quickly to show you that we can see the MZ and then I'm just gonna take g4 go and then we can see a full oral executable so since we set a breakpoint on the address that would be returned to after that function finishes it doesn't continue executing and then we can stay a full like P etter here so now if we want to write the memory from this memory offset to disk so you can analyze it we can use the right management and then we can specify file name so we'll just do them in under C colon backslash and then we'll specify the starting and ending offsets so since I don't really know the starting and ending offsets of this memory I can just do bang address and then 30,000 and then we can get the base dress and address here which is really useful and then we'll specify that and then this is just how you specify a memory range and then it says for whatever reason it goes like over by one bite and then it says it's inaccessible but we've actually written that binary to disk before we get out of window bug here and back into Ida some like really useful stuff that we can do with this memory image will it's sitting in memory or like unpacked code or do you have skated strings or stuff like that is being able to search it so if we do s - a that's looking for a ski and then we have to specify a range and then we can just say something like HTTP and then we got some like beginning sort of like C to use there so yeah that will so the problem with this search - a command is is it will only look forward to ASCII delimited strings so if there's like a random null byte in your config or whatever that you're trying to search for in memory using ASCII it might only find a part of it or might the search might not find your specified pattern because it might be terminated by a null byte so that's just something to keep in mind yeah so now that we've written that to disk let's open up our dump liner in Ida and make sure that it is our final stage so for those of you who are coming to this from next 60-40 bug that little right man with the range is that's equivalent to you right-clicking on the memory section and saying dump to disk in next 60/40 bug so as you guys can see Wendy book pretty much you know has the same functionality plus much more than exits for debug it's just that everything is pretty much powered by the command line and there's no like real shortcuts for it with like mouse clicks I think that's probably at least for me that's the biggest hurdle to starting to use it is that you just have to remember those command line arguments yeah and just the biggest things to keep in mind when you're taking baby steps with window bug is just make use of these menus right like if you forget if you forget the commands to continue just go and then these are really useful too because you're going to have exception or thrown exceptions by certain types of malware and stuff stop debugging detaching like all this stuff is mostly available in the menus and then you can the documentation for when debug is actually really good for Microsoft so it will belike stackoverflow posted your reading it's it's like actually really well documented trends I think what we're gonna do is we'll probably link to like Josh's favorite commands on our blog we'll probably put up a few things that we cover in this video just that you have a nice cheat sheet and that way they're all sort of like the was it used day-to-day or just well just be in one PDF for you guys cool yeah so it's just a quick look at this binary and it actually does have linked PDB information this way yeah and then if we look at strings for this binary we can actually see some Rossi juice here yeah it's definitely unpacked lights uh I'd highly suggest taking a look at this binary that I have some pretty cool stuff I called it in my talk I called it TLDR because it actually has that string here so I called it the TLDR drop rings I thought those kind of funny I think will probably link to that below if you guys want to go check out a stock on it I thought it was pretty interesting cool so I think with that that's gonna kind of wrap up like our introduction here so at least now starting out you guys should be able to set up your workspace get something loaded with the symbols sort of do some basic debugging with it put great points on API is dumb memory so these are all the things that we've covered in many of our other videos where use x64 debug hopefully we just sort of covered off the bases here and we'll sort of leave it up to you guys let us know in the comments below if you're interested in this if you want to sort of like see us do more stuff with window by bring Josh back let us know and we'll have them back to talk about some more advanced stuff like debugging with multiple threads debugging calls into the kernel that sort of stuff but we didn't want to just put out this sort of primer so that everyone gets on the same page everyone's able to at least debug a binary and win debug is there anything else you want to cover before we take off no it's great I just wanted to thank you for for having me I think how do you thanks to you I think these videos are amazing so I'm really really happy to be part of this project I'm gonna cut that thanks so much I really appreciate it and so yeah let us know if you want to see more we'll bring Josh back thanks everyone and until next time keep exposing our stay curious just take a little piece of be higher goal Saskatchewan Nova Scotia and New Brunswick we Bank a new and Alberta and Manitoba Ontario NBC 10 you'll have found the stop and rounds of all my friends in me

Channel: OALabs

Views: 36,354

Rating: 4.9882355 out of 5

Keywords: windbg, debugging, reverse engineering, malware analysis, tutorial, open analysis live, openanalysis

Id: QuFJpH3My7A

Length: 38min 35sec (2315 seconds)

Published: Tue Feb 19 2019

Reddit Comments

[u/Dwedit]

So when do you use WinDbg, when do you use OllyDbg/X64Debug, and when do you use the MSVC Debugger?