Friday, July 27, 2018

A Review Of Alex Ionescu's Windows Internals For Reverse Engineers

This year (2018) at Recon in Montreal I signed up to take a class from Alex Ionescu called "Windows Internals for Reverse Engineers", the following are my thoughts on the course and experience.

I decided to take this class after being completely demolished at Infiltrate's "Click Here for Ring Zero" course. That course, despite all its faults, told me I wasn't as strong in Windows Internals as I thought I was. I figured, taking the Windows Internals course from one of the guys that literally writes the book would be a good step. Boy, was I right.

I've taken a lot of training and had lots of bad teachers in the past. Some of those teachers were monotone, non-engaged, unable to map new information to existing concepts, unprepared course material, broken labs, etc. Alex and his course was none of these things. I'm going to break down my evaluation of the teacher and course separately since those are the two main components in all training. I'm going to end with any prerequisites, and final thoughts/recommendations.

Teacher - Alex Ionescu
After going through the training (and talking to several other people in the class) I can confidently say that Alex is at the top (or top 2) of my list in effective communication and teaching. Alex has struck a rare combination of technical mastery over a subject (Windows Internals) as well as the ability to map new information to other people's current understanding.

He exhibited many good teacher practices, below are some of the ones that stood out to me:
  • He would give context for the target material by explaining "neighbor" material that was related. Making it easier to understand technical context and draw logical conclusions.
  • He explained the history behind certain design choices in Windows to help eliminate the "Why the hell would they do it that way?" feeling.
  • Extremely well prepared with the hand out material. 
  • Extremely well prepared with presentation material. He had annotation software allowing him to draw data structures and quickly highlight information pertinent to his point. He also had a countdown timer for breaks/lunch so no one ever asked how much time we had left. He always showed up a minute or two before it expired and started on time.
  • Was engaging with humor (poked fun at Microsoft devs several times) and not monotone at all.
  • Almost never read from the slides, all the information was well understood and presented fluidly.
Course - Windows Internals for Reverse Engineers
The course and its materials were inextricably linked with the teacher so its difficult to speak to it in an independent fashion but here goes nothing.

Make no mistake, this course is not for beginners. It is a full blown firehose of information and topics for 4 days straight. He's pretty relentless and if it wasn't for the fact that he's a fantastic teacher, you'd be easily lost on day one. The course material is extremely technical, in depth, and just a whole lot of it too.

Some things you'll learn about:
  • Setting up local and remote kernel debug machines
  • Windbg syntax, functions, and capabilities
  • OS design/decisions for memory and execution models, address space layout, shared data fields (KUSER_SHARED_DATA), functions and capabilities of the hypervisor
  • Secure UEFI boot signing, hypervisor based code integrity, PatchGuard, HyperGuard, memory segmentation
  • Software guard extensions on new CPUs, kernel/etc interrupts, system calls w/wo hypervisor enabled, win32k.sys
  • Windows object manager, the object directory, kernel handle table, sandboxing
That's maybe 10% of the course right there. I just flipped through the handout and wrote down the slide titles and topics I could remember.

For a higher level explanation of the topics you'll cover, Recon's training site was fairly accurate, granted it doesn't give you a sense of the depth. It's deep, yo.

Prerequisites
On the course signup page he mentions the following in "Class Requirements":
IMPORTANT: It’s helpful to understand x86/x64/ARM assembly to take this course, but knowledge of obfuscation, packing, etc., is not required.
Basic knowledge of Windows, processor architecture, and operating systems is helpful – you should have some vague idea of what an interrupt is, and what is the difference between user and kernel mode (ring levels), a bit about virtual memory/paging, etc.
I would add a couple more to that list:
  • Familiarity with C++ notation/syntax (he uses it a lot in windbg)
  • An understanding of certain programming concepts such as common data structures, type casting, overloading, modules, macros, memory paging, kinds of linked lists, etc.
I personally recommend you give the latest Windows Internals book a read through before coming to this class. It will help tremendously in not being lost.

Areas of Improvement
I'm really reaching here since honestly if nothing changed about this course, it would still be towards the top of my list. I'd say the only thing I wish could change would be more hands on labs and perhaps some reference material in the back of the handout, things like common WinDBG commands, the C++ notation he uses, and other commonly referenced information. I'd also recommend maybe cutting out some pieces he feels aren't as necessary to distill the content a bit more. But like I said, I'm reaching pretty hard here. If you are ready for the course, take it. I extremely recommend it.

Recommendation
If you feel you are the point in your career where you need a better understanding of Windows Internals to be more effective, and you meet the prerequisites, I strongly recommend this course. While its marketed towards reverse engineers (which I am not) it does help the more senior pentester/red teamer who is looking to branch out into custom Windows malware.

If I could go back in time to my previous self trying to make the decision on whether or not to take this course, I'd tell him to definitely take it. But I'd also tell him to read more of the Windows Internals book before he started class :D

PS.
People pronounce windbg in many ways, "win-dee-bee-jee", "win-debug", etc. He pronounces it "wind-bag" which I find too weird for my tastes. I believe I've discovered the true sentiment and feeling of the tool by pronouncing it my own way: "win-deebag".

Wednesday, July 25, 2018

Setting Up A Kali Interception VM

Twice now I've had to setup an interception proxy for testing protocol implementations. Below are the steps I took to configure the Kali VM as my main MITM box. I decided to not use a MITM attack like ARP Spoofing but instead setup Kali as a middling router. The networking setup is rather simple:
TargetDevice (over USB Ethernet adapter)-> Kali VM (Bridged Mode) -> Laptop's Wifi


  1. Download/install Kali as a virtual machine
  2. Set the VM in bridged mode (VMware breaks some things)
  3. Follow the guide here to get Internet sharing configured on Kali: http://itfanatic.com/?q=node/84
  4. Create an iptables rule to redirect your target traffic to your proxy software. Here i'm redirecting all traffic over 443 to 2020 (where striptls is listening): iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 2020
  5. Download striptls from github
  6. Run it locally with something like: ./striptls.py -s --listen 0.0.0.0:2020 --remote exampletarget.com:443
Running striptls is obviously not mandatory since step 3 configured a working middle machine. I just used it in my testing to strip the TLS command from XMPP and HTTPS. You now have a machine all traffic is flowing through and is at your disposal to do with as you wish.

Thursday, July 12, 2018

Noritake VFD Setup

I recently got my hands on a Noritake CU24025ECPB-U1J Vacuum Florescent Display. I always enjoyed the retro 80s/90s feel of VFDs and wanted to gain some experience with with one. Below is a picture of the back for reference:


The model VFD I got comes with its own driver board so its super easy just to send it the text you want over the parallel lines and the VFD driver takes care of the rest. Lots of Noritake's models state that there is a 5 or 6 pin serial port on the driver board allowing you to use sync/async serial instead of parallel. Well I must have been the unlucky one since apparently all I have is a parallel connection (on the far right of the above image). Luckily thats no big deal because Noritake's documentation and sample files make life quite easy.

There are several parts to getting this VFD to work.
  1. Hookup
  2. Downloading the Noritake Arduino Library
  3. Uploading the sample code
  4. Enjoying the VFD
The Hookup
Hookup was relatively easy once you found the proper documentation to tell you what the pins are.
The only thing even close to a datasheet for my exact model of VFD was off of DigiKey's website: https://media.digikey.com/pdf/Data%20Sheets/Noritake%20PDFs/CU24025ECPB-U1J.pdf
There you can see the pin layout towards the bottom of the page:

If you are using the sample code outlined later in this post, the connections for the parallel connector to the Arduino are below:

VFD -> Arduino Pin
1 (GND) > GND
2 (VCC) > VCC
3 (Not Connected)
4 (RS)    > 9
5 (RW)  > 10
6 (E)      > 11
7 (D0)   > 12 //Originally it was 0 but it causes problems with uploading the sketch, so I switched it.
8 (D1)   > 13 //Originally it was 1 but it causes problems with uploading the sketch, so I switched it.
9 (D2)   > 2
10 (D3) > 3
11 (D4) > 4
12 (D5) > 5
13 (D6) > 6
14 (D7) > 7


Now that you have it hooked up, double check your connections so it looks like this:


Downloading The Library

Download the Zip, add it to your Arduino Libraries by going to Sketch > Include Libraries > Add .Zip Library. Once I did that it didn't show up in the menu listing of my libraries but did show up if you clicked "Manage Libraries" as "cuu".

Uploading The Sample Code
Below is the code I used/modified to get it working for my board. I only changed the mode I was using and the pin configurations but other than that its basically the same as the sample code Noritake provides on their QuickStart guide:

 
#include <CUU_Interface.h>
#include <CUU_Parallel_I80.h>
#include <CUU_Parallel_M68.h>
#include <CUU_Serial.h>
#include <Noritake_VFD_CUU.h>
/*VFD > Arduino
1GND > GND
2VCC > VCC
3NC
4RS > 9
5RW > 10
6E > 11
7DBO > 12
8DB1 > 13
9DB2 > 2
10DB3 > 3
11DB4 > 4
12DB5 > 5
13DB6 > 6
14DB7 > 7
 */
 
//Changed D0, D1 from Arduino0,1 to Arduino12,13 so it will upload the sketch fine.
//Apparently it cant upload if there is anything connected to 0,1 on upload :/
CUU_Parallel_M68 interface(9,10,11, 12,13,2,3,4,5,6,7);//RS,WR,RD,D0-D7
 
Noritake_VFD_CUU vfd;
 
void setup() {
  _delay_ms(500);      // wait for device to power up
  vfd.begin(20, 2);    // 20x2 character module
  vfd.interface(interface); // select which interface to use
 
  vfd.CUU_init();      // initialize module
 
  vfd.print("O HAI THERE :D"); // print some text
}
 
void loop() {
}


Enjoying The VFD


And enjoying it, I am. Noritake made it relatively easy to get up and running quite quickly, so I greatly appreciate that.

Now the next step is to modify the code so it takes input from a serial connection so I can control it using a python script. Maybe a retro twitter scroller? I dunno :D

References For Reference :)