I wanted to download a Web page in a program I’m writing for Windows. Windows provides some APIs to do this, like WinHttpConnect, WinHttpOpen, etc. Great, shouldn’t be an issue, right?

I copied some sample code from Microsoft to do a GET request and changed it to fit my needs. Awesome, this is super simple! However, Kaspersky flags my program as potentially malicious for using the DNS cache.

Now, it is beyond me how Kaspersky detects what is essentially sample code as malicious. And for doing DNS? Maybe if I’m hitting known malware websites, but I was hitting google.com. Any ways, that’s besides the point, so let’s move on with our lives and fix this AV detection, shall we?

Now, since we’re getting flagged for using the DNS cache, is there a way to get around that? After some MSN sifting, turns out there is! A function called DnsQuery() (duh…) can execute DNS requests for us. More importantly, there is a flag to bypass the DNS cache. So its a matter of using this call, bypassing the DNS cache, then simply passing raw IP addresses to other system calls (like WinHttpConnect).

Voila, no more AV detection! Some source code is below. If you have anymore tips or advice about AV avoidance, please leave a comment!

Notes: I was unable to get the codes to trigger on Windows 7, only on Windows XP, which is weird. I was using a trial version of Kaspersky PURE, so it might have been related to something specific about the signatures and algorithms used for those specific version? Not sure.

TL;DR: If Kaspersky flags your application as malicious for using the DNS cache, using DnsQuery() and the bypass cache option for your DNS queries, should be a good way to get around it.

Original Code:

// Specify an HTTP server.
WCHAR host[] = L"www.google.com";
if (hSession)
hConnect = WinHttpConnect( hSession, host, INTERNET_DEFAULT_HTTP_PORT, 0);


No DNS Cache Code:

DNS_STATUS status;
PDNS_RECORD pDnsRecord;
PIP4_ARRAY pSrvList = NULL;
WORD wType = DNS_TYPE_A;
char* pOwnerName;
char pReversedIP[255];
char DnsServIp[255];
DNS_FREE_TYPE freetype;
freetype = DnsFreeRecordListDeep;
IN_ADDR ipaddr;
WCHAR unicodeIpAddr[50];

// Now do the HTTP connect with a raw IP address instead of a host name
if (hSession)
hConnect = WinHttpConnect( hSession, unicodeIpAddr, INTERNET_DEFAULT_HTTP_PORT, 0);


I am using an ATmega32U4 (awesome chip!), but these steps should be appropriate for most AVRs.  Note that my clock is running at 8 MHz. If you change the clock speed, make sure to change the prescalar value.

ADCSRA |= (1 << ADPS2) | (1 << ADPS1); // prescalar = 64
ADMUX |= (1 << REFS0); // reference voltage from internal source
ADMUX |= (1 << ADLAR); // 8 bits, instead of 10
ADCSRA |= (1 << ADATE); // free running
ADCSRA |= (1 << ADEN); // enable ADC
ADCSRA |= (1 << ADSC); // start A2D conversions

Note that this code works for a continuously running, non-interrupt driven ADC program. If you want to use single shot conversions or interrupt driven ADC, you will need to change these lines appropriately. I might add that as another post eventually.

This Rhino is curious to find EXE paths of applications

So, while going through this process, I found 2 different ways of doing this, both from the Internet and combing through MSDN documentation. If you just want to get the full EXE path of a certain PID, turns out it is very simple. If you want to get a full PROCESSENTRY32 structure however, it’s a little more challenging.

First, the easier solution of just getting the full EXE path. Turns out there is a lovely system call called QueryFullProcessImageName that does exactly what I wanted. (Of course, I only found this after hours of searching and doing the other way, but that is besides the point.) It’s almost comical how easy it is to use:

DWORD PID = 1337; // something here
HANDLE hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, false, PID);

DWORD value = MAX_PATH;
char buffer[MAX_PATH];
QueryFullProcessImageName(hProcess, 0, buffer, &value);
printf("EXE Path: %s\n", buffer);

Simple, right?

The only downside to this method is that you only get the full EXE path, nothing else. For more information, you might want to fill a PROCESSENTRY32 structure, which can be done in a few steps:

1. Create a snapshot of all processes with CreateToolhelp32Snapshot()
2. Iterate through all processes with Process32First() and Process32Next()

A source example of this would look like:

DWORD PID = 1337; // something here

HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, PID);
if(hSnapshot)
{
    peInfo.dwSize = sizeof(peInfo); // this line is REQUIRED
    BOOL nextProcess = Process32First(hSnapshot, &peInfo);
    bool found = false;
    while(nextProcess)
    {
	if(peInfo.th32ProcessID == PID)
	{
	    found = true;
	    break;
	}
	nextProcess= Process32Next(hSnapshot, &peInfo);
    }
    if(found)
    {
        printf("%s",peInfo.szExeFile);
    }
    CloseHandle(hSnapshot);
}

What is happening in this code sample is that a snapshot is being taken of the current processes in the system. If the iterated process has the desired PID, the process is examined. Information about a process is stored in the PROCESSENTRY32 structure. There are a lot of interesting pieces of information in that structure, but we are only concerned with the szExeFile field, which is the EXE name of the application. Note that it is only the application, not the full path, such as ‘itunes.exe’, not ‘C:\Program Files\iTunes\iTunes.exe’. If you want the full path, use the first solution presented above.

A few months ago, I installed the Windows 8 RC on my computer. Call me crazy, right? It was OK, but I didn’t like it enough to pay for it. So, I decided to take the plunge and install Arch Linux on my computer and commit to sticking with it for at least a month. Initial set up went fine, as I have run and set up Arch before. However, I gave up as some critical programs I need would not work in Wine and virtualization was a lot slower in 2009. Windows 8 was going to expire anyways, so I figured why not try Arch again instead of going back to Windows 7.

I recently bought a Maschine from Native Instruments, but when I tried to install the software in Wine, no go. Fine, I’ll just fire up a Windows 7 virtual machine for it. The software went fine, but for some reason, the Maschine driver was not able to start and exited with error code 10.

I have had driver problems before, so I simply re-installed the driver. Still nothing. About 3 hours of more failed attempts and I’m this close to going back to Windows 7. I posted a question on the forum for help and went to bed.

Today, I was playing around with VirtualBox again after getting some help on various forums. Turns out, in VirtualBox, you must enable EHCI (Enhanced Host Controller Interface) support for the VM. Sure enough, I had it disabled on my VM. I found the setting by looking under the USB settings for the VM and enabling it. I also had to make a USB filter for the Maschine so VirtualBox knew which devices to talk to using EHCI. After I did that, my Windows VM started the driver! Great! *BUZZ* Nope. True, the Maschine now works, but whenever I press a button, there is about a half second lag before any sound plays. Clearly, unacceptable.

Turns out, using the WASAPI sound drivers that come with Windows was the problem. To fix this, I installed ASIO4ALL, which is an alternative audio driver. Accepting the default settings immediately fixed the problems I was having! Now I have immediate feedback from all my MIDI stuff in my VM and the audio is crystal clear!

This adventure was a lot more irritating than my blog probably makes it sound, so I’m really glad I was able to remedy the situation. Hopefully this helps someone else out!

This rhino wishes he had a comfortable couch to lay on.

I am actually using my CouchDB instance as both my database and webserver. Since CouchDB has a REST API and everything in CouchDB is a document, so there is no reason why you cannot simply ues the browser to send an HTTP request and return HTML pages directly from the database! Pretty neat to eliminate Apache, PHP, and MySQL from the web stack and instead use just CouchDB.

Anyways, I have been chugging along merrily, serving static HTML pages or show functions from my database, until I started to use the list functions that CouchDB offers.

Specifically, I was having trouble getting it to return an HTML header, rather than just plaintext.

To solve this, you must format your list function as:

function(head, req)
{
    provides('html', function() {
    ... The list function ...
    send(data);
});
}

This tells the list function to send HTTP headers along with the data, rather than just the data itself.

This took me a while to figure it out, so hopefully it helps you!

He is so sick of looking up constants by hand

Well, I got quite sick of doing this, so I whipped up a few Python scripts and made a database of a lot of the Windows constants.

I do not claim that 100% of them are there, but on the initial import, I found over 100,000, so there are quite a few! In the future, I will be adding POSIX and other constants, as well as some of the Windows constants I missed. Parsing all the headers was a pretty interesting task, so I might publish another entry on it here in the future.

I thought this database might be helpful to others, so I am publicly publishing it at www.namethatwindowsconstant.com.

Enjoy

My inspiration for this project

This post will cover what I did for the various parts as well as some of the interesting bits of code, so that you can make your own!

The majority of DJing software and controller use what is called MIDI (Musical Instrument Digital Interface) to control interact with each other. In fact, most digital instruments also use this standard when plugged into a computer. Rather than transmitting analog sound data, the instrument will transmit MIDI commands, which could be of the types ‘note on’, ‘note off’, ‘pitch bend’, or one of many others. This greatly simplifies processing the signals as well as reduces the sheer amount of data that needs to be sent; MIDI messages are typically three bytes, as compared to how large an audio stream would be.

The first step to the project was to make sure that my computer could talk through a MIDI interface to my circuit. MIDI is a fairly uncommon peripheral on computers, so I had to go to Sam Ash to buy a 1×1 MidiSport, which provides 1 MIDI In/Out port and plugs into a USB port. Easy enough. I also purchased the MIDI Breakout Board from Sparkfun, which allows my ATtiny2313 AVR chip to connect to the MIDI cables.

This was a really handy board to have

MIDI is actually just a fancy serial port connection that runs at 31250 baud, and I already had some code for doing that type of communication (as shown below), so the step of transmitting data wasn’t all that complicated. I DID run into a gotcha in that I needed to apply voltage to the MIDI breakout board as well as a data line. That took me about a day to figure out. Anyways, here is the code:

void init_uart()
{
	/* Initialize the UART */
   UBRRH = (unsigned char)(15 >> 8);//(unsigned char)((unsigned int)((F_CPU / 16.0 / MIDI_BAUD)-1) >> 8);
   UBRRL = (unsigned char)(15);//(unsigned char)((F_CPU / 16.0 / MIDI_BAUD)-1);

   UCSRB = (1 << RXEN) | (1 << TXEN);

   UCSRC = (0 << USBS) | (0 << UCSZ2) | (1 << UCSZ1) | (1 << UCSZ0);
}

void usart_send_byte(uint8_t u8Data)
{
	// Wait if a byte is being transmitted
	 while (!(UCSRA & (1 << UDRE)));

	// Transmit data
	UDR = u8Data;
}

uint8_t usart_receive_byte()
{
	// Wait until a byte has been received
	while (!(UCSRA & (1 << RXC)));

	// Return received data
	return UDR;
}

After I had the micro controller talking over the MIDI port, I thought it would be exciting to actually have some buttons, rather than just hard coding sequences of notes. So, I got on DigiKey and bought a 4×4 keypad. I had never used a ‘matrix keypad’ before, but thought it couldn’t be too complicated. Boy was I wrong. The way a (4×4) matrix keypad works is that there are 8 I/O lines. 4 correspond to a row each and the other 4 correspond to a column each. When a button is pressed, a circuit is completed between the appropriate row and column pins. By detecting which pins are connected, the micro controller can deduce which specific button is pushed.

A basic 4x4 matrix keypad

There are other sites on the internet that explain a little bit more of the theory behind matrix keypads, so I won’t repeat them here. However, I could not get any of the sample code I found to work, so I had to end up writing my own. Before providing the code, I will explain the setup I was using. I was using PORTB on the ATtiny2313 to handle all 8 pins of the keypad, PB0-PB3 were the columns (H,G,F, and E, respectively) while PB4-PB7 were the rows (J, K, L, and M, respectively). I did not use any external resistors, despite some sites suggesting I do so.

/************************************************************************/
/* Returns which button is pressed. Indexed, 0-15. 0xFE if none is pressed*/
/************************************************************************/
uint8_t button_pressed()
{
	/*
		// outputs (columns) low 4 bits
		E - PB0
		F - PB1
		G - PB2
		H - PB3

		// inputs (rows) high 4 bits
		J - PB4
		K - PB5
		L - PB6
		M - PB7
	*/

	/* Everything is an input */
	DDRB = 0x0;

	/* Columns are Hi-Z */
	PORTB = 0x0;

	/* Rows are pulled high */
	PORTB = PORTB | 0xF0;

	/* For each column */
	uint8_t c;
	for(c = 0; c < 4; c++)
	{
		/* Turn this column into an output. It will be a low output. */
		DDRB = DDRB | (1 << c);

		/* For each row */
		uint8_t r;
		for(r = 0; r < 4; r++)
		{
			uint8_t pins = PINB;

			/* Is this row low? (binary left shift by the row count + 4 to get into high nibble */
			if(! (pins & (1 << (r+4) ) ) )
			{
				/* If yes, */

				/* Return this button */
				return 15 - (r*4 + c); // Subtracting the value from 15 flips it so that the upper left is 0 and bottom right is 15
			}
			else
			{
				/* If no, */
				/* Continue */
			}
		}

		/* Turn this column back to Hi-Z */
		DDRB = 0;
	}

	return 0xFE;
}

After I was able to figure out how to interface with the 4×4 matrix keypad, I was able to configure each button to send a unique message to the computer. Currently, I am using Traktor for my DJ software and I have  it set up so each button causes a different function in Traktor; one button loops 8 bars, another performs a pitch bend, others fire off samples, and I haven’t figured out what to do with the rest!

The final results of the MIDI controller project.

The final result of my project looks like the picture to the left. It was a lot of fun to build and work on this project. For an extension, I might try to make a PCB, rather than a breadboard for all the components. I would also like to put a USB to MIDI chip directly on the board, rather than using an external one. That would be more convenient and I’m sure cheaper. Also, it would be fun to make a nice enclosure of some kind or to have fancier buttons than what I am currently using.

Leave me a comment and let me know what you think!

The main problem I ran into with this task is that Mac’s do not have loop devices and the losetup program. On Linux, these let you mount a disk image, such as a CD ISO or  a raw hard drive image,  to a folder. You can then easily mount the image, copy files, then unmount the image and be done. Since Macs do not have these loopback devices, it wouldn’t be possible to just build the losetup program either.

On a Mac, you can play with ISOs and other images using Disk Utility. For a bootable hard drive image, there is no filesystem on the disk initially, so there is nothing for Mac to mount. Too bad.

However, there is a set of tools called mtools, which allow you to play with DOS formatted images, i.e. FAT, which will work for my needs. They are especially helpful on Linux systems, since you can use them without being a root user, unlike losetup. Luckily, they are GNU open source, so there was a glimmer of hope that these may work on Mac. I tried Homebrew and MacPorts, but neither worked. There was source available though, so I could try building them myself.

Normally, GNU software is easy to install. Just do ‘./configure; make; make install’ and that’s it on a Linux system. Macs are a little different from Linux though, so sometimes this doesn’t work. In this case, I kept getting compile errors when running make. Something to do with the iconv library and not linking properly. I suspect that is from Apple providing a slightly different version of the library. Fortunately, this was an optional library, so I simply excluded it from the rebuild and tried again. Voila, it built and I now have mtools.

The next step was to create a hard drive image. This sounds simple, but it takes some math to make one of the proper size. It is important that the disk has less than 1023 cylinders, or else GRUB will complain later on.  I found a calculator online to help do this. For my needs, I only needed about a 10 MB disk, so I used the values: 4 heads, 500 cylinders, 10 sectors per track, and 512 per sector. This gives a 10.24 MB disk size. Great.

I made a raw file of the proper size with the command:

dd if=/dev/zero of=disk.img bs=512 count=20000

That command spits out disk.img, which will be the hard drive image we are working with. However, it is just filled with zeros right now, so mtools needed to format it. I pulled my hair out trying to figure out the right command line options for this. I kept confusing the -s flag for the number of sectors, but it’s actually number of sectors PER TRACK. That’s kind of a big deal. Anyways, here are the commands I used to get mtools to play nice:

echo 'drive a: file="disk.img"' > mtoolsrc
MTOOLSRC=./mtoolsrc mformat -t 2000 -s 10 -h 4 a:

Now, the disk is formatted with a FAT filesystem (at least as far as I understand it).  However, there are no files on it, so it’s pretty boring. First, we need to install GRUB, which is a bootloader, so that we can boot this stupid disk (At this point, I have done about 10 hours of Googling, compiling, and yelling). In the mtools package, there are two commands called ‘mmd’ and ‘mcopy’. These can make a directory and copy files for us. Exciting, I know. Here are the steps to copy GRUB (legacy) to the disk. Note that you must already have the files downloaded. You can grab them here. For grub.conf, you will have to play with that and make one yourself. There are tutorials, so I omit directions here.

 MTOOLSRC=./mtoolsrc mmd a:/boot
MTOOLSRC=./mtoolsrc mmd a:/boot/grub
MTOOLSRC=./mtoolsrc mcopy stage1 a:/boot/grub
MTOOLSRC=./mtoolsrc mcopy stage2 a:/boot/grub
MTOOLSRC=./mtoolsrc mcopy grub.conf a:/boot/grub

Well, now we have a hard disk image with GRUB on it, we’re done right? WRONG. Grub is stored on the disk, but not installed on the disk. To actually install it, we have to boot the disk and run some GRUB commands.

But how can we boot the disk if GRUB isn’t installed? Point for you if you asked that. We now need to go grab a bootable GRUB floppy. We’re only interested in the GRUB command line, so any will do. There is one from here that will work.

Now that we have the disk with GRUB stored on it and a bootable floppy, let’s finally start the virtual machine and install GRUB. I’m going to use QEMU. If you’re using something else, QEMU commands won’t help you, so use QEMU instead. First, boot the disk and floppy with the command:

qemu -hda disk.img -fda /floppy.img -boot order=a

That will start QEMU with both the floppy and hard disk inserted and boot the floppy. When the floppy first boots up, hit ‘c’ on the keyboard to get a command line. That’s all we actually needed the floppy for. Now, on the command line, enter the commands:

root (hd0,0)
setup (hd0,0)

Some text should fly by and if there are no errors, GRUB will now be installed. You can check by running QEMU again, but without the floppy disk and seeing what happens. Hopefully, you will get a boot screen, in which case you are done. You can now copy files as needed to the disk using ‘mcopy’ how we did before.

If you get errors about disk size and cylinders, use the command ‘geometry (hd0,0)’ to get some more information, when at the GRUB command line.

Well, I hope that helps someone else out there. I had no end of problems getting that to work. However, I can now use disk images so I can work on…. Well, I forgot what I was originally doing, it was so long ago!

I figured the MBR would be interesting to learn a little bit more about, so I decided to load it up into IDA Pro, a tool for disassembling programs, and see what I could find out.

This baby rhino was also curious about MBRs.

For this analysis, I assume that you are familiar with the x86 architecture and assembly. If not, WikiBooks has some great information about it here. I am also using IDA Pro to do this. I have tried to provide comments and labeling in my IDA work, but I also explain each block of code separately.

The first step in figuring out the MBR was to actually get a copy of it I could work with. To do this, I used Hex Workshop, which offers a way to do a binary copy of hard disks. The MBR is always located as the first sector of the disk, so I used Hex Workshop and extracted this file. It is only 1 sector long, so it is a mere 512 bytes.

After looking at Wikipedia, I figured out the MBR structure was:

0000h - 01B7h       Code Area (440 bytes)
01B8h - 01BBh       Disk Signature (4 bytes)
01BCh - 01BDh       Generally Zeroed out (2 bytes)
01BEh - 01FDh       List of Partition Records (4 16-byte structures)
01FEh - 01FFh       MBR Signature (2 bytes - Must be AA55h)

The above structure is what gets loaded into memory and executed. The code area is going to do a few different things, which I look at below. The disk signature can be used to uniquely identify a hard disk. The partition records define different operating systems and partitions on the hard disk. Have you ever noticed how you have to jump through some hoops if you want to have more than 4 operating systems or partitions on your computer? Well, that’s because you only have 4 partition records available. The MBR signature helps illustrate that this is in fact an MBR structure.

The partition records are a pretty important part of the MBR, so I also examined their structure. It is:

0000h - 0000h    Status byte (80h for bootable, 00h for non-bootable, others are invalid) (1 byte)
0001h - 0003h    CHS address of first absolute sector (3 bytes)
0004h - 0004h    Partition type (1 byte)
0005h - 0007h    CHS address of last absolute sector (3 bytes)
0008h - 000Bh    LBA of first absolute sector (4 bytes)
000Ch - 000Fh    Number of sectors in partition (4 bytes)

That is a pretty simple structure; just a start and stop address, length, and a few informational bytes. The CHS format is a little confusing though. CHS stands for Cylinder-Head-Sector and defines an address inside of a physical hard drive. You can read more about CHS here. The LBA address stands for Logical Block Address. LBA is a format to linearly address space on the hard drive, rather than defining 3 separate numbers for Cylinder-Head-Sector format. More information about LBA is here.

After examining the file MBR structure, I loaded the binary file into IDA Pro. Since it is a binary file, IDA doesn’t know where the correct segments or entry points are, or even if it is 16 or 32 bit code. Since we don’t have an OS yet, we know that this code is 16 bit. Looking at the MBR structure, the code starts at the very first byte of the file. Knowing this, I configured IDA and converted the first few bytes to code. I got the following:

s0:0000 ; ---------------------------------------------------------------------------
s0:0000
s0:0000 ; Segment type: Pure code
s0:0000 seg000          segment byte public 'CODE' use16
s0:0000                 assume cs:seg000
s0:0000                 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
s0:0000                 xor     ax, ax          ; Zero out AX
s0:0002                 mov     ss, ax          ; Set SS to 0
s0:0004                 mov     sp, 7C00h       ; Set SP to 7C00h
s0:0007                 mov     es, ax          ; Set ES to 0
s0:0009                 mov     ds, ax          ; Set DS to 0
s0:000B                 mov     si, 7C00h       ; Source for the copy
s0:000E                 mov     di, 600h        ; This is the destination for the copy
s0:0011                 mov     cx, 200h        ; We want to copy 200h bytes, which is the length
s0:0011                                         ;    of one sector, i.e. the whole MBR.
s0:0014                 cld                     ; Clear Direction Flag
s0:0015                 rep movsb               ; Copies CX bytes from [SI] to [DI]
s0:0015                                         ;    i.e. from [7C00h] to [600h]
s0:0017                 push    ax              ; New value for CS
s0:0018
s0:0018 loc_18:                                 ; New value for IP
s0:0018                 push    61Ch
s0:001B                 retf                    ; Pops the top of the stack into IP then pops CS
s0:001B	                                        ;    off next.
s0:001B                                         ;    i.e. we will run from 0000h:61Ch,
s0:001B                                         ;    which is where we just copied ourselves to.
s0:001B                                         ;
s0:001B                                         ; Execution continues at the next instruction.

I have tried to add a lot of comments to show what is going on. Essentially though, what this is doing is copying the MBR from 0000h:7C00h to 0000:600h. This is necessary, because it will later load the OS to 0000h:7C00h, so it needs to get itself out of the way. It does this using the ‘rep movsb’ which does a binary copy of 200 bytes from SI (7C00h) to DI (600h).

An interesting part about the code above is the way that the ‘retf’ instruction is used. This does what is known as a ‘far jump’. This means it not only jumps to a different instruction address, but also a different code segment. Both of these values are popped off of the stack, with the offset being on top and the new segment being second. Before the retf instruction, the program pushes 0 and then ’61Ch’ onto the stack to setup for this far jump. This may seem strange, but since it just copied all the program data to 0000h:0600h, 61Ch is actually the offset to the instruction directly after the retf in the binary.

The next few instructions are:

s0:001C                 sti                     ; Enable interrupts
s0:001D                 mov     cx, 4           ; This will be used for the loop.
s0:001D                                         ;    We only want to examine 4 partition records.
s0:0020                 mov     bp, 7BEh        ; This is the offset to the first partition
s0:0020                                         ;   record.
s0:0020                                         ; In the MBR structure, the first partition
s0:0020                                         ;    record is at base+1BEh,
s0:0023                                              so it is 600h + 1BEh = 7BEh
s0:0023

First thing this code does is to enable interrupts so that it can be interrupted if necessary. Next, it sets the CX register to 4 and BP to 7BEh. BP is the offset to the partition records (there is a description of these records here). CX is indicating that we will only examine 4 records (since there are only 4 in the MBR). So this is setting up to iterate over the 4 partition records to find the bootable one that we want.

After this is a loop that tries to find a bootable partition entry. The code is:

s0:0023 loc_23:                                 ; CODE XREF: seg000:0030j
s0:0023                 cmp     byte ptr [bp+0], 0 ; Compares the status byte to 0
s0:0027                 jl      short FoundBootableEntry ; Jumps if the status flag is not 0.
s0:0027                                         ;    This will happen if the MSB of [bp+0]
s0:0027                                         ;    is 1, essentially saying that if it
s0:0027                                         ;    is 0x80, it will jump.
s0:0027                                         ;
s0:0027                                         ; This jump indicates that we have found the
s0:0027                                         ;    bootable partition.
s0:0029                 jnz     PrintInvalidPartitionTable ; It's not 0x80 and it's not 0x0, so
s0:0029                                         ;    it's invalid. Jump to an error state.
s0:002D                 add     bp, 10h         ; Go to the next partition record.
s0:0030                 loop    loc_23          ; Loop while CX != 0
s0:0032                 int     18h             ; TRANSFER TO ROM BASIC
s0:0032                                         ; causes transfer to ROM-based BASIC (IBM-PC)
s0:0032                                         ; often reboots a compatible; often has no effect
s0:0034                                         ; at all

Remember how above we moved the offset of 7BEh into BP? That is so this loop can then examine the partition records. The comparison is checking the status byte of the partition record and comparing it to 0. If it is 0, the first jump will not be taken, nor will the second jump, so 10h is added to BP and the loop is restarted. Advancing the BP register means that we will examine a different partition record. If, after 4 iterations, we have still not found a bootable partition entry, an ‘int 18h’ call will be made. On old IBM PCs, this would run a BASIC interpreter from ROM, but few computers have this. So essentially, an int 18h call will just stop the system. Imagine that, if you have no bootable entries, you’re computer won’t boot!

If the status byte of the parition record was in fact 80h, the first jump would have been taken. The JL instruction does a jump if the status flag is set to 1. This flag will get set by the previous CMP instruction if the high order bit is set in the status byte, i.e. the status byte is 80h. If the entries status byte is neither 80h or 00h, a jump is made to the PrintInvalidPartitionTable location. I’ll talk about that a little bit, but it’s pretty boring (it just prints an error message); when a bootable entry is found, things are much more fun.

The next block of code is run when a bootable entry is found. Here it is:

s0:0034 FoundBootableEntry:                     ; CODE XREF: seg000:0027j
s0:0034                                         ; seg000:00AEj
s0:0034                 mov     [bp+0], dl      ; Save the drive number for later
s0:0034                                         ;    Note that since this will most likely be the
s0:0034                                         ;    first hard drive, DL will probably be 0x80
s0:0037                 push    bp
s0:0038                 mov     byte ptr [bp+11h], 5
s0:003C                 mov     byte ptr [bp+10h], 0 ; This is a sentinel value for later
s0:0040
s0:0040 loc_40:                                 ; DATA XREF: seg000:014Fr
s0:0040                 mov     ah, 41h ; 'A'
s0:0042                 mov     bx, 55AAh
s0:0045                 int     13h             ; DISK - Installation Check
s0:0045                                         ;   CF set on error
s0:0045                                         ;   CF cleared on success
s0:0045                                         ;   BX = AA55 if installed
s0:0045                                         ;   AH = major version of extensions
s0:0045                                         ;   CX = API subset
s0:0045                                         ;   DH = Extension version
s0:0047                 pop     bp
s0:0048                 jb      short AttemptLoadFromDisk ; Jump if Below (CF=1)
s0:004A                 cmp     bx, 0AA55h      ; DATA XREF: seg000:0045r
s0:004A                                         ; seg000:007Er ...
s0:004A                                         ; Compare Two Operands
s0:004E                 jnz     short AttemptLoadFromDisk ; Jump if Not Zero (ZF=0)
s0:0050                 test    cx, 1           ; Logical Compare
s0:0054                 jz      short AttemptLoadFromDisk ; Jump if Zero (ZF=1)
s0:0056                 inc     byte ptr [bp+10h] ; This acts like a sentinel value
s0:0056                                         ;    for whether or not the INT 13
s0:0056                                         ;    extended read is installed
s0:0059

First part of this block does is moves the DL register into where the entry’s status byte used to be. I wasn’t really too sure what was going on here for a long time, since if it overwrites the partition record, won’t it not boot correctly next time? Well, it turns out that the first hard drive is represented by 80h, so most of the time, things will be fine. I don’t have 2 hard drives, so I’m not sure what would happen if you had two hard drives and had your bootable entry on the second hard drive. I suspect that the 2nd hard drive would just have its own MBR and would run that instead. Running code on 1 hard drive and loading data from another hard drive seems a little bit silly anyways, so I’m pretty sure that’s whats going on. If you know more, please leave a comment!

Next, the code saves the partition record to the stack and moves the values 5 and 0 into the status byte. The 5 indicates the number of attempts that will be made to read from disk later. Multiple attempts will be made because the disk read might fail while the disk spins up. The 0 value is a sentinel value for whether or not the BIOS supports the extended interrupt 13h feature. This is an advanced, easier way to load lots of data from disk into memory, but not all BIOSs support it. The code above runs several different checks and if they all succeed, it stores a 1 where it had just stored a 0, indicating the extended read feature is supported. If any of those checks fails, it just jumps down a few lines and continues executing and will use the older method.

The next section of code loads the first sector of the OS into memory, using a different method depending on whether or not the extended read is supported. Here it is:

s0:0059 AttemptLoadFromDisk:                    ; CODE XREF: seg000:0048j
s0:0059                                         ; seg000:004Ej ...
s0:0059                 pushad                  ; Save all our registers for a little bit
s0:005B                 cmp     byte ptr [bp+10h], 0 ; Did our sentinel value get changed?
s0:005F                 jz      short InstallationFailed ; DATA XREF: seg000:0032r
s0:005F                                         ; Jump if Zero (ZF=1)
s0:0061                 push    large 0         ; LBA of 0
s0:0067                 push    large dword ptr [bp+8] ; DATA XREF: seg000:00E5r
s0:0067                                         ; seg000:0125r
s0:0067                                         ; Transfer buffer
s0:0067                                         ;    This is also the LBA of first absolute sector
s0:0067                                         ;    in the MBR partition record
s0:006B                 push    0               ; Transfer buffer
s0:006E                 push    7C00h           ; Number of blocks
s0:006E                                         ;    Note that only the first byte is relevant,
s0:006E                                         ;    and the second is ignored, so we are only
s0:006E                                         ;    reading 7Ch
s0:0071                 push    1               ; Reserved
s0:0074                 push    10h             ; Packet is size 10h
s0:0077                 mov     ah, 42h ; 'B'
s0:0079                 mov     dl, [bp+0]      ; Drive number
s0:007C                 mov     si, sp          ; Point to the address packet we just made
s0:007E                 int     13h             ; DISK - Extended Read
s0:007E                                         ;
s0:007E                                         ;    Reads DS:SI into a disk appress packet
s0:007E                                         ;      a disk address packet is:
s0:007E                                         ;      00 BYTE: Size of packet (10h or 18h)
s0:007E                                         ;      01 BYTE: Reserved
s0:007E                                         ;      02 WORD: Number of blocks to transfer
s0:007E                                         ;      04 DWORD: Transfer buffer
s0:007E                                         ;      08 QWORD: Starting absolute block number (LBA)
s0:007E                                         ;      10 QWORD: 64-bit flat address of transfer buffer (optional, used if the DWORD at 04 is FFFFh:FFFFh)
s0:007E                                         ;
s0:007E                                         ;    CF cleared if successful
s0:007E                                         ;    AH = 0 on success
s0:0080                 lahf                    ; Preserve the flags for a second
s0:0081                 add     sp, 10h         ; Pop the address packet we were using off the stack
s0:0084                 sahf                    ; Store AH into Flags Register
s0:0085                 jmp     short PostDiskReadState ; Jump
s0:0087 ; ---------------------------------------------------------------------------
s0:0087
s0:0087 InstallationFailed:                     ; CODE XREF: seg000:005Fj
s0:0087                 mov     ax, 201h        ; The extended read interrupt is not installed,
s0:0087                                         ;    so use the legacy version
s0:0087                                         ; AH = 2 (Disk read sectors into memory)
s0:0087                                         ; AL = 1 (Read 1 sector)
s0:008A                 mov     bx, 7C00h       ; This is the destination buffer
s0:008D                 mov     dl, [bp+0]      ; Drive number
s0:0090                 mov     dh, [bp+1]      ; These 3 bytes are a CHS structure
s0:0093                 mov     cl, [bp+2]
s0:0096                 mov     ch, [bp+3]
s0:0099                 int     13h             ; DISK - READ SECTORS INTO MEMORY
s0:0099                                         ; AL = number of sectors to read, CH = track, CL = sector
s0:0099                                         ; DH = head, DL = drive, ES:BX -> buffer to fill
s0:0099                                         ; Return: CF set on error, AH = status, AL = number of sectors read

Right away, a comparison is done against the sentinel value. If it is 0 (indicating no extended read), a jump is taken to the InstallationFailed label. If the extended read is supported, an “address packet” is set up for the interrupt and then the int 13h call is made, performing the read. This was actually a pretty tricky section to figure out, mostly because I found all the documentation about address packets was pretty confusing. After the extended read is completed, the code jumps to the PostDiskReadState location. I expect there are a few errors in my comments about the address packet, which I might try to figure out more about later.

Both the extended read and the non-extended read code do essentially the same thing though. They load the first sector of the bootable partition into memory at 0000h:7C00h. This will most likely be the operating system’s loader which will get things started up properly. Before we jump to the OS though, first we have a little bit of maintenance to do, to make sure we are set up and good to go.

After the disk reads are done, we need to make sure that everything succeeded, which is what this block of code does:

s0:009B PostDiskReadState:                      ; CODE XREF: seg000:0085j
s0:009B                 popad                   ; Restore all our registers
s0:009D                 jnb     short DiskReadSuccess ; Jump if CF = 0
s0:009D                                         ;    i.e. The interrupt we just executed (either one)
s0:009D                                         ;    just succeeded.
s0:009F                 dec     byte ptr [bp+11h] ; Remember this was set to 5 before?
s0:009F                                         ;    This is looping and trying the disk several times,
s0:009F                                         ;    (it might have failed while the disk spun up)
s0:00A2                 jnz     short ReattemptDiskRead ; Jump if Not Zero (ZF=0)
s0:00A4                 cmp     byte ptr [bp+0], 80h ; 'Ç' ; Is this drive letter 80h, i.e. the
s0:00A4                                                    ; first hard drive?
s0:00A8                 jz      PrintErrorLoadingOperatingSystem ; Jump if Zero (ZF=1)
s0:00AC                 mov     dl, 80h ; 'Ç'   ; Re-try on the first hard drive
s0:00AE                 jmp     short FoundBootableEntry ; Jump
s0:00B0 ; ---------------------------------------------------------------------------
s0:00B0
s0:00B0 ReattemptDiskRead:                      ; CODE XREF: seg000:00A2j
s0:00B0                 push    bp
s0:00B1                 xor     ah, ah          ; Logical Exclusive OR
s0:00B3                 mov     dl, [bp+0]
s0:00B6                 int     13h             ; DISK - RESET DISK SYSTEM
s0:00B6                                         ; DL = drive (if bit 7 is set both hard disks and
s0:00B6                                         ;   floppy disks reset)
s0:00B6                                         ;
s0:00B6                                         ; This is important so we can try the read again
s0:00B8                 pop     bp
s0:00B9                 jmp     short AttemptLoadFromDisk ; Jump

For both style of disk reads, if the operation succeeded, the carry flag will be cleared. As such, there is a JNB instruction that is taken if the load succeeded and jumps to the DiskReadSuccess location. If not, the counter we previously set to 5 is decremented. Remember how I talked about that the disk read might fail sometimes? This code is taking into account the drive being busy, not being spun up, or any other reason by just re-trying a few times. If however, it has failed after the 5 attempts, something is wrong. A comparison is then made to see if we are on the first hard drive by comparing the drive letter we wrote to [BP+0] with 80h. If it is, there is a problem loading the OS, so we print an error message. If not, we change the DL register to 80h, indicating the first hard drive, and try the whole process again.

The ReattemptDiskRead code is pretty straightforward. All it does is resets the disk system and jumps back to the AttemptLoadFromDisk location. Pretty simple, huh?

Hopefully the disk read will succeed though, and the code will get to the DiskReadSuccess location. We are very close to actually jumping to the OS in that case. Here is the code:

s0:00BB DiskReadSuccess:                        ; CODE XREF: seg000:009Dj
s0:00BB                 cmp     word ptr ds:7DFEh, 0AA55h ; We just loaded new code to 7C00h. Check
s0:00BB                                         ;    to see if it has the bootable signature AA55.
s0:00BB                                         ;    This signature indicates a VBR, which indicates
s0:00BB                                         ;    an operating system
s0:00C1                 jnz     short PrintMissingOperatingSystem ; The last two bytes are NOT AA55h
s0:00C1                                                           ; so there is no OS.
s0:00C1                                         ;    Print an error message.
s0:00C3                 push    word ptr [bp+0]
s0:00C6                 call    CheckKeyboardSystemFlag ; Call Procedure
s0:00C9                 jnz     short CheckForTPM ; Jump if Not Zero (ZF=0)
s0:00CB                 cli                     ; Disable interrupts for a while
s0:00CC                 mov     al, 0D1h ; '-'
s0:00CE                 out     64h, al         ; AT Keyboard controller 8042.
s0:00CE                                         ;    Enables writing the output port
s0:00D0                 call    CheckKeyboardSystemFlag ; Call Procedure
s0:00D3                 mov     al, 0DFh ; '¯'
s0:00D5                 out     60h, al         ; AT Keyboard controller 8042.
s0:00D5                                         ;    Enables writing to the status register
s0:00D7                 call    CheckKeyboardSystemFlag ; Call Procedure
s0:00DA                 mov     al, 0FFh        ; Enable A20 memory line
s0:00DC                 out     64h, al         ; AT Keyboard controller 8042.
s0:00DC                                         ; Reset the keyboard and start internal diagnostics
s0:00DE                 call    CheckKeyboardSystemFlag ; Call Procedure
s0:00E1                 sti                     ; Enable interrupts
s0:0156 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
s0:0156
s0:0156
s0:0156 CheckKeyboardSystemFlag proc near       ; CODE XREF: seg000:00C6p
s0:0156                                         ; seg000:00D0p ...
s0:0156                 sub     cx, cx          ; CX = 0
s0:0158
s0:0158 CheckByte2:                             ; CODE XREF: CheckKeyboardSystemFlag+8j
s0:0158                 in      al, 64h         ; AT Keyboard controller 8042.
s0:015A                 jmp     short $+2       ; Jump
s0:015C                 and     al, 2           ; Logical AND
s0:015E                 loopne  CheckByte2      ; Loop while rCX != 0 and ZF=0
s0:0160                 and     al, 2           ; Logical AND
s0:0162                 retn                    ; Return Near from Procedure
s0:0162 CheckKeyboardSystemFlag endp

This code first checks to see that we did, in fact load an OS and not just some garbage into memory by checking for the AA55h signature. If it is not there, we print an error message. Otherwise, we’re going to fiddle with the keyboard controller a bit. This code makes several calls to the CheckKeyboardSystemFlag function, which basically loops until the keyboard controller is ready to talk to to the CPU. I’m a little fuzzy on what the output to the ports is doing, but I’m pretty sure that it is enabling the A20 address line, which enables larger amounts of memory to be used. It’s a pretty common task and there are write-ups all over the Internet, so I won’t go into it.

After the MBR is done fiddling with the keyboard controller, it decides to check for a Trusted Platform Module. The TPM is used to do several security related things, such as for Windows BitLocker encryption. There is a lot of complex documentation, so after I figured out that this was TPM code, I decided not to investigate it further. It is listed below:

s0:00E2 CheckForTPM:                            ; CODE XREF: seg000:00C9j
s0:00E2                 mov     ax, 0BB00h
s0:00E5                 int     1Ah
s0:00E7                 and     eax, eax        ; Logical AND
s0:00EA                 jnz     short JumpToLoadedMemory ; Jump if Not Zero (ZF=0)
s0:00EC                 cmp     ebx, 41504354h  ; Compare Two Operands
s0:00F3                 jnz     short JumpToLoadedMemory ; Jump if Not Zero (ZF=0)
s0:00F5                 cmp     cx, 102h        ; Compare Two Operands
s0:00F9                 jb      short JumpToLoadedMemory ; Jump if Below (CF=1)
s0:00FB                 push    large 0BB07h
s0:0101                 push    large 200h
s0:0107                 push    large 8
s0:010D                 push    ebx
s0:010F                 push    ebx
s0:0111                 push    ebp
s0:0113                 push    large 0
s0:0119                 push    large 7C00h
s0:011F                 popad                   ; Pop all General Registers (use32)
s0:0121                 push    0
s0:0124                 pop     es
s0:0125                 int     1Ah             ; This makes a call to the TPM

The code first checks for the presence of a TPM module. If it is not there, it jumps to the JumpToLoadedMemory location, otherwise it makes a call to the TPM.

Well, ladies and gentlement, thanks for sticking with me. After all that, we are finally ready to jump to the operating system that we loaded into memory. It’s very simple, so without further adieu:

s0:0127 JumpToLoadedMemory:                     ; CODE XREF: seg000:00EAj
s0:0127                                         ; seg000:00F3j ...
s0:0127                 pop     dx
s0:0128                 xor     dh, dh          ; Logical Exclusive OR
s0:012A                 jmp     far ptr 0:7C00h ; Jump to the code we have loaded

That’s it?! Yup, that’s it. Anti-climactic, though I guess Master Boot Records aren’t supposed to be entertaining.

There is some more code that I didn’t talk about yet, because it has to do with printing the error messages out. I’m not going to explain it here, since I’m already over 3000 words and I’m sure you’re sick of reading. Here it is:

s0:0131 PrintMissingOperatingSystem:            ; CODE XREF: seg000:00C1j
s0:0131                 mov     al, ds:7B7h
s0:0134                 jmp     short DisplayErrorMessage ; Jump
s0:0136 ; ---------------------------------------------------------------------------
s0:0136
s0:0136 PrintErrorLoadingOperatingSystem:       ; CODE XREF: seg000:00A8j
s0:0136                 mov     al, ds:7B6h
s0:0139                 jmp     short DisplayErrorMessage ; Jump
s0:013B ; ---------------------------------------------------------------------------
s0:013B
s0:013B PrintInvalidPartitionTable:             ; CODE XREF: seg000:0029j
s0:013B                 mov     al, ds:7B5h
s0:013E
s0:013E DisplayErrorMessage:                    ; CODE XREF: seg000:0134j
s0:013E                                         ; seg000:0139j
s0:013E                 xor     ah, ah          ; Clear out the high byte of the AX register.
s0:0140                 add     ax, 700h        ; We now point to 700h + whatever offset we were given
s0:0140                                         ;    above.
s0:0143                 mov     si, ax
s0:0145
s0:0145 PrintErrorStringLoop:                   ; CODE XREF: seg000:0151j
s0:0145                 lodsb                   ; Load byte at DS:SI into AL
s0:0146                 cmp     al, 0           ; Is the next byte 0? We're looking at a 0 terminated
s0:0146                                         ;     string, so this is important.
s0:0148                 jz      short HaltSystem ; Jump if Zero (ZF=1)
s0:014A                 mov     bx, 7
s0:014D                 mov     ah, 0Eh
s0:014F                 int     10h             ; - VIDEO - WRITE CHARACTER AND ADVANCE CURSOR (TTY WRITE)
s0:014F                                         ; AL = character, BH = display page (alpha modes)
s0:014F                                         ; BL = foreground color (graphics modes)
s0:0151                 jmp     short PrintErrorStringLoop ; Jump
s0:0153 ; ---------------------------------------------------------------------------
s0:0153
s0:0153 HaltSystem:                             ; CODE XREF: seg000:0148j
s0:0153                                         ; seg000:0154j
s0:0153                 hlt                     ; This stops the computer.
s0:0154                 jmp     short HaltSystem ; Jump
s0:0156
s0:0162 ; ---------------------------------------------------------------------------
s0:0163 aInvalidPartiti db 'Invalid partition table',0
s0:017B aErrorLoadingOp db 'Error loading operating system',0
s0:019A aMissingOperati db 'Missing operating system',0
s0:01B3                 db    0
s0:01B4                 db    0
s0:01B5                 db  63h ; c             ; Redirect to the error message at 63h,
s0:01B5                                         ;    i.e. "Invalid Partition Table"
s0:01B6                 db  7Bh ; {             ; Redirect to the error message at 7Bh,
s0:01B6                                         ;    i.e. "Error loading operating system"
s0:01B7                 db  9Ah ; Ü             ; Redirect to the error message at 9Ah,
s0:01B7                                         ;    i.e. "Missing operating system"

I realize that a blog post is a pretty difficult way to explain an RE task like this well. As such, I’m going to make my IDA Pro database available for download here. If you don’t have IDA, there is a free version (which I use) available here. It is missing quite a few features, but the price is right, and for work like this (16-bit MBR code), a lot of the newer features aren’t even relevant.

If you’re interested, you could do this analysis on your own computer. Depending on your computer’s manufacturer, you might have some small differences, but those are what makes it fun, right? To get started, get the trial of Hex Workshop, extract the MBR (it’s the first sector on the disk), then use the free version of IDA Pro to examine it. Happy hunting!

Yesterday, I submitted a paper to the 2010 ACM DIM (Digital Identity Management) workshop. My paper was  about a project I have been working on the last semester. I used several different things in my projects, some of which I have written about before. Rather than try to explain the project now, I will show you the abstract. I’ll post the full paper once it is either officially accepted or rejected.

PEAR: A Hardware Based Protocol Authentication System

Abstract

As users have to manage an increasing number of ac-

counts, they have to balance password security and pass-

word usability. As such, many users use insecure pass-

words resulting in their accounts and data being vulnerable

to unauthorized accesses. In this paper, we present Phys-

ically Enhanced Authentication Ring, or PEAR, a system

that alleviates this problem. We leverage Physically Un-

clonable Functions (PUF) to create unclonable hardware

devices, which users use to authenticate. Using a hardware

device, our system uses zero-knowledge proofs, which pro-

vide better security than traditional passwords, yet users

must only enter a simple PIN. As such, our system is very

usable and imposes little to no burden on end users and

service providers. We present transaction levels on top of

PEAR of as an extension and then discuss some other work

that could be done in the future.