The INT 3 Blog https://docs.microsoft.com/archive/blogs/int3/feed.xml Developing the Reverse Engineering Mindset Wed, 17 Apr 2019 03:41:36 GMT en-US hourly 1 The Reverse Engineering Mindset – Is it Possible to Suspend a Kernel Thread from the Debugger? https://docs.microsoft.com/archive/blogs/int3/blog3-susp3nding_k3rnel_thr3ads_with_ebfe Thu, 01 Sep 2016 18:01:55 GMT https://blogs.msdn.microsoft.com/int3/?p=175 BlogHeader-Spacing Hello friends - I’m still compiling content for the upcoming REP series but I have an “interrupt to service" before the REP series drops on INT 3. Last week a member on my team was in a pinch which resulted in a thought-provoking team discussion over email. This is an outstanding way to start the morning.  His question was, “I’m live debugging a system using WinDbg. Is it possible to suspend a kernel thread directly from the debugger?” Surprisingly a quick search on the web showed other developer types asking the same question with the absence of any reasonable answers. The lack of any solution motivated me to post a video response on INT 3. The short answer is - “no”. The long answer is – “yes (a pseudo-suspend), with ebfe”. I’ll explain. Video: This is an edge case scenario but it provides an opportunity to walk through fundamental reverse engineering techniques. In the video we'll attach to a Hyper-V virtual machine using Windbg, set a breakpoint in the debugger, and step through code with the end goal of hot patching the assembly with the ebfe opcode. If you enjoy the content, please join our INT 3 YouTube channel. The scenario my teammate is debugging involves a reference count problem on a kernel object. One application makes a driver call to look for the object in the kernel. If the object is instantiated, the reference count is incremented. If the reference count drops to zero, the Object Manager destroys the object as you would expect. The problem is a second application utilizing the services from the same kernel object is concurrently decrementing the object’s reference count. This causes the object to be destroyed while the first application is using the object. His intent was to test various behavioral patterns of the kernel code and he wanted to suspend the first application’s thread while it was in the kernel, prior to the reference count increment operation. While this single thread was suspended, he planned to terminate the second application before the decrement operation, and then resume the suspended thread from the first application. He is debugging with a Debug Crash Cart. The “cart” consists of a Target computer and a second computer referred to as the Host where the Debugging Tools for Windows are installed. The two systems are attached via an Ethernet cable but there are other options such as a null-modem cable, 1394 cable, or a special USB cable. I discussed configuring this type of setup in an old article located here - https://blogs.msdn.microsoft.com/ntdebugging/2013/01/31/how-to-setup-a-debug-crash-cart-to-prevent-your-server-from-flat-lining CrashCart Warning: Only Do This in a Pinch This technique is useful when you find yourself in the proverbial pinch on a lab machine but this is not intended to be used for thread synchronization on a production machine. If this target thread owns a synchronization object, such as a mutex or ERESOURCE, it can lead to blocking if a calling thread tries to obtain a synchronization object owned by the thread we’re hot patching. Also the target thread will spin in a tight loop creating implications if the IRQL is at DISPATCH level or above. I don’t recommend this technique on a production system but it conveys the “reverse engineering mindset”. Here are the steps we used: 1. We used the ‘eb’ Windbg command to hot patch the assembly for the target thread with a ebfe opcode. This ‘JMP to self-opcode’ causes the target thread to loop forever. Make note of the original code so it can be replaced later. 2. Then we typed ‘g’ in the debugger command window to continue execution of the system. The target thread will loop on the one instruction. 3. Do you dirty work (e.g. kill the second application, test your scenario). 4. Then break in to the debugger to replace the JMP instruction with the original opcode. 5. Hit g and you're on your way. -Ron]]> The Reverse Engineering Mindset – The Reverse Engineering Principle (REP) Series https://docs.microsoft.com/archive/blogs/int3/blog2-rep1-r3verse-engin33ring-pr1n Wed, 17 Aug 2016 03:08:18 GMT https://blogs.msdn.microsoft.com/int3/?p=55 Header-Binary Hello friends – It would be neglectful for the INT 3 blog to initialize without discussing the fundamental principles necessary to develop the reverse engineering mindset. Last month I spoke at an internal, biyearly Microsoft conference in Seattle. The talk focused on my experience debugging a troublesome z-order bug causing a logon window to disappear while users attempted to logon to a third-party application from their field locations. Debugging z-order issues is an ugly business. Before stepping the audience through the debugger output projected on the big screen in the session room, I asked the question, “where do you start debugging an issue when there is no error message generated, no crash dump created, no blocking threads to examine, no event log message logged, nor any ETW trace output generated? Where is the debugging entry point for an elusive disappearing logon window?” The answer culminated into a discussion of the three “Reverse Engineering Principles” I have strived to cultivate over the last eighteen years. First I discussed the importance of building your reverse engineering toolbox by mastering tools such as Windbg, IDA Pro, debug extensions such as MEX, debug scripts, and the Sysinternals suite. Note: IDA Pro is great to have but there are also free disassemblers available including BeaEngine located here. We spent time discussing the importance of solid code comprehension skills which includes understanding language primitives, identifying design principles and possessing a familiarity with compiler specifics. This includes assembly language for both x64, x86 or whatever target platform is necessary. Then I wrapped up by deliberating on the importance of having a reasonable level of architecture knowledge including both operating system and processor semantics. Growing in all three of these areas will continue to develop the reverse engineering mindset. Over the next couple of months, I will unpack these principles in a 'Reverse Engineering Principles' series named REP for short. The series will be loaded with sample assembly snippets, C code examples and Windbg walkthroughs. The first REP article in the series will pay homage to Matt Pietrek’s ‘Under the Hood’ article from February of 1998 with extended register and assembly walk-throughs. You can also count on Trey and Dan to run concurrent series and articles discussing other topics. REP-Diagram   If you’re curious about the debugging starting point for the disappearing logon window issue, knowing the GDI architecture and how WinEvents operate (e.g. REP Principle of Architecture Knowledge) pointed me to my debug entry point. And one more thing before we part ways this week - I mentioned the MEX tool above. MEX is a newly released debug extension for Windbg sustained by my team. Our design goal is to make you ‘faster as a debugger’. Download MEX, load it into Windbg with the .load command and check it out. -Ron  ]]> The Reverse Engineering Mindset – Hello World https://docs.microsoft.com/archive/blogs/int3/blog1-h3ll0_w0rld Tue, 09 Aug 2016 19:46:26 GMT https://blogs.msdn.microsoft.com/int3/?p=45 Header-Binary __asm int 3
Hello friends – Welcome to the INT 3 blog. According to the Intel 64 and IA 32 Architecture Software Developer’s manual, “the INT 3 instruction explicitly calls the breakpoint exception (#BP) handler.” It gives a task or program the ability to call the exception handler to halt execution of a program or system. Much like the INT 3 is used to ‘break’ (or halt) code execution to give the debugger an opportunity to examine the execution state, it is our intent on the INT 3 blog to ‘break in’ and examine debugging techniques, debugger automation (debug scripts and extensions), kernel architecture, reverse engineering techniques, and a lot more. Our plan is to post a series of recurring articles on these topics.
  C:\>hostname My name is Ron Stock and I’m one of the three contributors to the INT 3 blog. I spend the majority of my day reviewing crash dumps, live debugging, code reviewing Windows bugs, and instrumenting source to troubleshoot issues for Enterprise customers. Dan Mattson is a fellow Senior Escalation Engineer and developer on my Support Escalation team at Microsoft. Trey Nash is a developer and consultant from our Cyber Security team who spends a lot of his time reverse engineering, debugging and writing books. We all look forward to publishing on INT 3. We will occasionally sneak in other personal passions such as my ‘guitar talk’, Dan’s diversions and Trey’s ‘synthesizer chats’.   0: kd>g -Ron
]]>