wannabe hacker

At Long Last

2017-05-08T00:00:00+00:00

Hacking post day eeelevenish, and it’s finally time! We start the code exploitation chapter and begin hacking.

Recall that exploitation is making programs do unintended things. Security flaws, often, are extra pieces of functionality used in ways the original programmer did not expect. Small logic errors or seemingly unused code can lead to larger consequences.

One typical flaw is the off by one error. This happens when programmer miscounts the number of elements in a loop or conditional check. For example, suppose you want to build a one-hundred meter long fence with posts every 10 meters. How many posts do you need? Intuitively, the answer is ten. But that is incorrect; you actually require eleven. These sorts of errors occur regularly while coding.

Another common problem is quickly expanding complexity. Programmers sometimes get in a hurry and are unable to fully test functionality. The book gives the example of Microsoft’s IIS handling Unicode characters. IIS is designed to serve both read-only and read-write content. Read-write directories give the user of a website full control of the system, so it’s important to limit that access to certain subdirectories. Unfortunately, IIS later added Unicode support. Unicode expansion happened after the backslash check, so attackers could pass in Unicode characters to escape to different directories. Several worms used this vulnerability to deface websites.

Next we come to the classic security fault: buffer overflows. Suppose a C programmer allocates 8 bytes of memory, and tries to write 9 bytes to that space. This action is not stopped by the operating system (until more recent security measures), and it often causes the program to crash. But if we’re careful, we can execute arbitrary code this way. Here’s some sample code with a buffer overflow in it.

overflow_example.c

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[]) {
   int value = 5;
   char buffer_one[8], buffer_two[8];

   strcpy(buffer_one, "one");
   strcpy(buffer_two, "two");

   printf("[BEFORE] buffer_one is at %p and contains \'%s\'\n", buffer_one, buffer_one);
   printf("[BEFORE] buffer_two is at %p and contains \'%s\'\n", buffer_two, buffer_two);
   printf("[BEFORE] value is at %p and is %d (0x%08x)\n", &value, value, value);

   printf("\n[STRCPY] copying %d bytes into buffer_two\n\n", strlen(argv[1]));
   strcpy(buffer_two, argv[1]);

   printf("[AFTER] buffer_one is at %p and contains \'%s\'\n", buffer_one, buffer_one);
   printf("[AFTER] buffer_two is at %p and contains \'%s\'\n", buffer_two, buffer_two);
   printf("[BEFORE] value is at %p and is %d (0x%08x)\n", &value, value, value);
}

And here it is in action:

vagrant@vagrant-laptop:~/src $ gcc overflow_example.c 
vagrant@vagrant-laptop:~/src $ ./a.out 12345
[BEFORE] buffer_one is at 0xbffffc78 and contains 'one'
[BEFORE] buffer_two is at 0xbffffc70 and contains 'two'
[BEFORE] value is at 0xbffffc84 and is 5 (0x00000005)

[STRCPY] copying 5 bytes into buffer_two

[AFTER] buffer_one is at 0xbffffc78 and contains 'one'
[AFTER] buffer_two is at 0xbffffc70 and contains '12345'
[AFTER] value is at 0xbffffc84 and is 5 (0x00000005)
vagrant@vagrant-laptop:~/src $ ./a.out 12345678901234567890                           
[BEFORE] buffer_one is at 0xbffffc68 and contains 'one'
[BEFORE] buffer_two is at 0xbffffc60 and contains 'two'
[BEFORE] value is at 0xbffffc74 and is 5 (0x00000005)

[STRCPY] copying 20 bytes into buffer_two

[AFTER] buffer_one is at 0xbffffc68 and contains '901234567890'
[AFTER] buffer_two is at 0xbffffc60 and contains '12345678901234567890'
[AFTER] value is at 0xbffffc74 and is 0 (0x00000000)
vagrant@vagrant-laptop:~/src $

The buffers are 8 bytes long, so we can safely store anything up to 8 characters in them. When we pass in a longer input, the extra bytes overwrite other variables. How, exactly is this exploitable? Tune in tomorrow to find out.

More to come.

What the Struct

2017-05-07T00:00:00+00:00

Hacking post day ten. I skipped out on writing yesterday because it was too late at night. This week I am focusing on writing, and sleeping, earlier. But, enough about me! Let’s dive into some more C material. Today is mostly about structs.

Yo dog, we heard you like variables. So we made a variable you can put more variables into. In C we call it a struct. structs are continuous areas of memory. You declare them like this:

struct brewery {
    int bottles_of_beer;
    double cash_on_hand;   
};

We get a struct called brewery, which tracks bottles of beer and cash. Next, we must access these values somehow.

// declare struct and vars
struct brewery mybrew, *brewptr;
brewptr = &mybrew;
// three ways to access:
bottles = mybrew.bottles_of_beer; // direct access
cash = brewptr->cash_on_hand; // pointer access
num_bottles = *((int *) brewptr); // hacky pointer cast

To access values the first way, we must have the struct in memory. This works sometimes, but can be a hassle. Passing structs around takes a lot of space on the stack. To migigate this, we use the second access method. Having a pointer to the struct is just as good. Note the arrow (->) notation is for convenience; it’s the same as dereferencing the struct pointer. The first two access methods are proper ways to use structs in C. The third way technically works, but it’s discouraged. How it works, is we cast the pointer as an int pointer and then directly access the memory location. It’s messy because you have to track exactly how the memory is laid out in the struct.

Next, a quick note on pointers. Pointers hold a memory location, and we typically use them to refer to variables. However, we can also get a pointer to a function’s location, known as a function pointer. Here’s some source from the book showing their use.

funcptr_example.c

#include <stdio.h>

int func_one() {
    printf("This is function one"\n");
    return 1;
}

int func_two() {
    printf("This is function two"\n");
    return 2;
}

int main() {
    int value;
    int (*function_ptr) (); // funciton pointer!

    function_ptr = func_one;
    printf("function_ptr = 0x%08x\n", function_ptr);
    value = function_ptr();
    printf("value returned was %d\n", value);

    function_ptr = func_two;
    printf("function_ptr = 0x%08x\n", function_ptr);
    value = function_ptr();
    printf("value returned was %d\n", value);
    return 0;
}

So the function pointer gets set to the locations of two different functions and called. This works as you’d expect; both functions get called properly and we see that they live at different memory addresses. I’m not sure what these are used for in C, but it’s here just in case.

Finally, we look at pseudo-random numbers. Truly random numbers require non-determinism. Computers produce outputs based on inputs, ie they are deterministic, so they cannot provide true randomness. However, some programs require random numbers. AI in games and cryptography are two easy examples which come to mind. In C, we can use the srand() and rand() functions from <stdlib.h>. srand() takes a seed value, then rand() produces pseudo-random numbers from that seed. It is common to use the seconds elapsed since the epoch (how Linux tracks time) as a seed. Pseudo-random numbers appear random, but if you know the seed you could calculate them.

This is the end of the C tutorial, whoo!! From here, the book shows one large C program: game_of_chance.c. Maybe I’ll post source later? (it’s on github). Next up is the chapter on exploitation, aka making a program do unintended things. I am quite excited to start, as that will be totally new material. Cannot wait!

More to come.

Cyber Burr Brrr

2017-05-05T00:00:00+00:00

Hacking post day the ninth. These days, it’s all about the cyber. We continue with a discussion of Linux user IDs (aka UIDs (aka cyber UIDs)).

Every user and group in Linux has a unique ID number; they are UIDs and GIDs respectively. View IDs using the id command on Linux shell.

$ id user
$ id $(whoami)

First command will return results of “user” UIDs plus any applicable GIDs. The second command gets the logged in user (via subshell) then asks for IDs related to that. So far, so good.

Sometimes, multiple users must make changes to a shared file. Linux has a permission to allow this, called set user ID aka setuid. Set it on myfile.sh like so: sudo chmod u+s ./myfile.sh. When a program has this permission, it runs as the file’s owner instead of current user. The UID we’re running as currently is known as the effective UID or euid.

In C, we can view both uid and euid with very simple functions. Here’s a brief demo program:

#include <stdio.h>

int main() {
    printf("real uid: %d\n", getuid());
    printf("effective uid: %d\n", geteuid());
}

So, when we need to provide access to some shared resource, we can give root access to that resource. Set our program to run as root. Then, track the uid running the program. When writing to resource, record uid of author. To retrieve data from resource, read uid and only return results written by that uid. Clear as mud.

Thus ends our discussion of UID, GUID, and eUID. Tomorrow we’ll continue travelling the way of C with structs.

More to come.

Rabbit Trail Redux

2017-05-04T00:00:00+00:00

Today I am again time-poor, so I have again opted to write a little about my tooling. Hacking: the Art of Exploitation comes with a live CD for all your hacking needs, so I made it into a virtual machine for easy access. Here I’ll talk about that process and link to a nice guide.

At first I was going to rip the iso off the included physical CD, which is time-consuming and lame. Then I found that No Starch Press’s product page for Hacking: Art of Exploitation links to a torrent of the iso. I happily torrented it.

Next I used the iso file to build a virtual machine. A virtual machine is basically a miniature computer within your computer. In this case, since the Hacking live CD was based on Ubuntu, I now have a miniature Ubuntu system. It’s especially nice, because the Hacking toolset is over seven years old. Anti-exploit tools in the Linux kernel have matured since then, making some of the books’ exploits invalid. Additionally, the memory inspection sections are based on 32-bit architecture while I have a 64-bit machine. Using a virtual machine I can see the exact same things as the author. Everything works exactly as expected.

This setup was nice, but I wanted more. I found myself writing code in the virtual machine, and wanting to post it. This is possible with extra software provided by the virtual machine software. In my case, I tried to install some tools from VirtualBox. However, the provided installation did not work for me! I found out later this was due to the age of the gcc compiler provided with the Hacking disc. Anyway, in googling for a solution I came across a very interesting github gist. The gist described making a Vagrant box out of the Hacking CD. Vagrant is a semi-recent virtualization technology. It lets you configure virtual machines using command line, and the default access is SSH. Perfect for me! If everything worked out correctly, I would be able to talk to the Hacking box using SSH. This adds a lot of convenience to my workflow.

In short, I followed the gist’s guide and set up my box. Along the way, I ran into a couple snags. The total setup took me three hours and some extra googling. So I forked the gist. I will add to it and write again about my modifications.

Long story short, I ended up with a very nice setup. Now, I open a shell at my vagrant directory and issue these commands.

    vagrant up
    vagrant ssh

This boots my virtual machine and connects me via ssh. I have the ~/src folder shared between the virtual machine and my computer. This lets me write code using my local (customized) vim, then switch to the virtual machine to compile and disassemble what I’ve written. Sending code to a post is as easy as using cat to read the file, copying relevant code, and pasting into the post. Very nice!

Anyway, I’ve very content with my setup now. Next time we’ll continue the discussion of Linux UIDs.

More to come.

Student Becomes Teacher

2017-05-03T00:00:00+00:00

Hacking book day eight, whoa dude. Today we’re going all-in on advanced C topics. Enjoy.

Recall that yesterday’s discussion included a section on file system. Today we continue that conversation by discussing access mode flags. Access mode flags describe how C will access a file. The flags are defined in the C language headers fcntl.h and sys/stat.h. Access mode must use at least one of these flags:

O_RDONLY: read-only access
O_WRONLY: write-only access
O_RDWR: both read and write

Additionally, access mode may have optional flags. Here are some of the more useful ones (p84):

O_APPEND: write data to file end
O_TRUNC: if file exists, shorten it to length 0
O_CREAT: if file does not exist, make it

To combine these flags, we use bitwise OR operator (the pipe “|”). For example, write only with create option is: O_WRONLY|O_CREAT. Internally, these flags are strings of bits in different positions. So bitwise ORing them adds the bits together and erases no information.

When creating a file with O_CREAT, additional flags are required to specify the file’s permissions. They are defined in sys/stat.h, can be combined using bitwise OR, and are as follows (p87):

S_IRUSR: File owner can read this file.
S_IWUSR: File owner can write this file.
S_IXUSR: File owner can execute this file.
S_IRGRP: File group can read this file.
S_IWGRP: File group can write this file.
S_IXGRP: File group can execute this file.
S_IROTH: Others can read this file.
S_IWOTH: Others can write this file.
S_IXOTH: Others can execute this file.

If you know Linux file permissions, these are exactly the same. If not, we’re going to go over them right now. On Linux, whomever creates a file is the owner. The group that owner belongs to is assigned to the group of the file. And anyone is other users who are not a member of the group. Each of these have three permissions which may be set in any permutation: read, write, and execute. Here’s a concrete example:

 ~/src $ ls -l
total 16
-rwxr-xr-x 1 billy workers 7257 May  2 23:09 a.out
-rw-r--r-- 1 billy workers  994 Apr 30 23:53 scope.c
-rw-r--r-- 1 root  root     169 May  2 23:09 stack_example.c

As you can see, running ls -l displays the file permissions as well as owner and group information. Above, a.out belongs to billy and the workers group. Billy can read, write, and execute a.out; anyone in the workers group can read and execute a.out; and anyone else can read and execute a.out.

Shorthand for these permissions is (base 10) 4, 2, 1 because each permission has three binary bits. Read permission alone is 100, write alone is 010, and execute alone is 001 in binary. Each of {read, write, execute} can apply to each of {owner, group; others}. That’s three sets of three bits for a total of nine binary bits. Thus, it is common in Linux to express file permissions using a set of three base ten numbers. For example, the permissions on a.out above would be (base 10) 755 which is 111|101|101.

Finally, the chmod utility lets us change file permissions. Basic usage is chmod 644 myfile. See man chmod for more advanced usage.

Today we wrapped up our discussion of file access in C. We looked at the different access mode flags, combining them, and the different file permissions under Linux. Permissions seem odd at first, but once you’ve studied them a bit they become very simple. Next up we continue our discussion of advanced topics with User IDs.

More to come.

A Stack of Turtles

2017-05-02T00:00:00+00:00

Hacking book day seven. And how. Today we continue the looking at memory segments. This is a continuation of yesterday’s topic.

Recall C uses five different segments in memory: code, data, bss, heap, and stack. Where a variable is stored depends on how it is defined. Initialized static and global variables go to data; uninitialized variables remain in the bss. Heap memory is controlled by programmer; we allocate more space using malloc(). Remaining function variables are stored in stack, where all local context values reside (p75).

Let’s dive further into the heap, shall we? Using the other four variable segments just depends on how you initialize variables; using heap requires explicit effort (p77). Use malloc() to initialize memory. It returns a pointer to the memory or null if unable. When finished, release memory using free(). Note that malloc() doesn’t know what type of memory it is allocating. Thus malloc() returns a void pointer to the memory, and we the programmer must cast the pointer to the correct type.

This concludes the essentials of C programming. Next we move on to more advanced C topics using functions.

Our first advanced C topic is file access. C language supports low-level file management, using file descriptors, as well as high-level file buffered I/O using file streams. We’re going to look at file descriptors; they are more direct (p81). A file descriptor is a unique number used to reference open files. It’s like a social security card for open C files. There are four primary functions that operate on file descriptors, and they are as follows:

function	args	description	return values
open()	pointer to file, access mode flags	opens file for reading/writing	int file descriptor; -1 on error
close()	file descriptor	closes file	-1 on error
read()	file descriptor, pointer to data, #bytes to read	reads #bytes from file to pointer	-1 on error
write()	file descriptor, pointer to data, #bytes to write	writes #bytes from pointer to file	-1 on error

The access mode flags sent to open() require more time than I’ve got tonight. So our discussion of file access is placed on hold. Today we concluded our discussion of memory segments, and began looking into file access. Next time we’ll finish up file access and try to move through file permissions and user ids. In the next week, I hope to cover actual code exploitation. Can’t wait!

More to come.

Make my Day

2017-05-01T00:00:00+00:00

Hacking book day six, what what? Let’s do this. We’re moving on from variable scoping, globals, and statics. Not like way beyond, just into-the-next-city beyond.

Big topic today is memory segmentation. C divides program’s memory into five segments: text, data, bss, heap, and stack (p69). Relevant chart:

name	what it holds	permissions	growth
text (code)	assembled machine language instructions	read-only	fixed size
data	initialized global and static program vars	writeable	fixed size
bss	uninitialized global and static program vars	writeable	fixed size
heap	programmer-allocatable blocks of memory	writeable	grows down to higher memory addresses
stack	temp ‘scractch pad’ for local vars and context during func call	writeable	grows up to lower memory addresses

Here we come to an interesting aside on program execution. Program does not expect to read straight through text/code segment; control structures alter the flow through. As a program executes, EIP is set to first instruction in text. The processor then loops as follows (p69):

Read instruction at $EIP
$EIP += byte-length (at $EIP)
Execute instruction from #1
Loop back to #1

Let’s go into more depth on the stack segment. In general, stacks are FILO (First In Last Out) data structure. Think of it like putting beads on a string, with a knot at one end (p70). Cannot get the first bead without taking the rest off. This behavior is convenient when calling functions. The outermost, or first function, has it’s context buried most deeply in the stack. As function calls return, their context is easily available. It also makes sense that this must be dynamically-sized, because function calls are dynamic. Our program may have zero or many function calls on the stack at any time.

Function’s context is held in data store called stack frame. EBP register, aka FP frame pointer or LBP local base pointer, references local function variables in current stack frame (p70). Each stack frame holds: function parameters, local variables, the saved frame pointer (SFP), and the return address. SFP restores EBP to its previous value, and return address stores EIP’s next instruction after function call (p70).

And that’s all for today. We looked into memory segmentation, and defined the five segments. Tune in next time for more discussion on memory segmentation and using the heap.

More to come.

Hairs of my Head

2017-04-30T00:00:00+00:00

Hacking book day five. Let’s get right to it.

Previously, we talked about sending input to a C program using the scanf() function. This works, but there is a more efficient way– command-line arguments. Command-line arguments is a fancy way of saying provide input as we run the program. C language provides command line arguments to the main function when we pass in two additional parameters: int arg_count, and char *arg_list[]. The first, arg_count, holds number of arguments passed. The second is a pointer to an array of strings where each element is an argument. The zeroth argument is always the name of the executing binary (program).

It’s important to note that, in C, programmer is responsible for keeping track of memory bounds. That is, if a program tries to access memory out of it’s segments it crashes. C compiler does not automatically catch this for us. So, if you assume commmand-line arguments are there but they’re not, your program will probably crash (seg fault).

Our next topic is variable scoping. In C, functions are their own context independent of anything else. So, variable declared within a function is “invisible” to main() context and other functions. This means we can have variables named the same thing, but pointing to different values, as long as they exist in different function contexts.

Variables can also have global scope if they’re declared outside any function. In such case, the variable is the same throughout function contexts unless it is declared again. This can lead to confusion; best practice is to avoid using global variables.

Static scope is another way variables can be declared; to do so, we prepend the keyword static. Static variables remain intact across function calls; however, they remain local to a particular context. That is, if you call a function multiple times, the values of it’s static variables remain the same.

Following example demonstrates the concepts of scope, globals, and static variables.

#include <stdio.h>

int j = 42; // j is a global variable

int func4() {
    static int k = 0; // k is static variable
    return ++k; // every call it increments then returns
}

void func3() {
    int i = 1, j = 999; // i and j are local vars
    printf("\t\t\t[in func 3] i = %d, j = %d, k = %d\n", i, j, func4());
}

void func2() {
    int i = 7;
    printf("\t\t[in func2] i = %d, j = %d, k = %d\n", i, j, func4());
    printf("\t\t[in func2] setting j = 1337\n");
    j = 1337; // writing to global j
    func3();
    printf("\t\t[back in func2] i = %d, j = %d, k = %d\n", i, j, func4());
}

void func1() {
    int i = 5;
    printf("\t[in func1] i = %d, j = %d, k = %d\n", i, j, func4());
    func2();
    printf("\t[back in func1] i = %d, j = %d, k = %d\n", i, j, func4());
}

int main() {
    int i = 3; // main's local i
    printf("[in main] i = %d, j = %d, k = %d\n", i, j, func4());
    func1();
    printf("[back in main] i = %d, j = %d, k = %d\n", i, j, func4());
    return 0;
}

Compile and run

gcc scope.c
./a.out

And we get the following output.

[in main] i = 3, j = 42, k = 1
	[in func1] i = 5, j = 42, k = 2
		[in func2] i = 7, j = 42, k = 3
		[in func2] setting j = 1337
			[in func 3] i = 1, j = 999, k = 4
		[back in func2] i = 7, j = 1337, k = 5
	[back in func1] i = 5, j = 1337, k = 6
[back in main] i = 3, j = 1337, k = 7

As you can see, value of i remains local to contexts. k increments every time we call the function. And, j is global except when we declare it locally.

That’s a wrap for today. We discussed command line args, variable scope, globals, and static vars. Next topics are memory segmentation, the stac, and the heap.

More to come.

It Could Always Be Worse

2017-04-29T00:00:00+00:00

Hacking book day four (or so…just realized my numbering is incredibly inconsistent). Today there’ll be more introductory programming concepts paired with low-level architecture discussion. Let’s get started.

Last discussion ended with pointers plus the unary operators address-of (&) and dereference (*). Here’s a good mnemonic for remembering their usage:

When the unary operators are used with pointers, the address-of operator can be thought of as moving backward, while the dereference operator moves forward in the direction the pointer is pointing (p47; emphasis added).

Next up in our C discussion: format strings. The printf() function can be used to format data for output. By adding parameters, called format parameters, printf() knows to replace some part of the string with a value. Format parameters in printf() look like: %d. For each format parameter we use, we must pass an extra argument for printf() to insert into the string. For example, to print a decimal we might write:

printf("Value of myvar is: %d", myvar);

Here, %d is the format parameter; myvar is a variable we wish to print formatted as a decimal. Remember- myvar is just some bits in memory. C will print it out as whatever we choose, regardless of the data type we stored it as. The 1s and 0s are inherently meaningless; they get their meaning from the way they are interpreted (sort of like life).

In format parameters, there is an optional numeric argument. You can specify minimum width, eg %10d. C will pad with empty space, unless your minmum space starts with a 0 eg %09d. Here is a chart of the different parameter options; the data column is the type of format of the parameter printf() expects.

Parameter	Output Type	Data
%d	Signed Decimal	Value
%u	Unsigned Decimal	Value
%x	Hexadecimal	Value
%s	String (prints chars until null byte)	Char Pointer
%n	Number of bytes written so far	Pointer
%p	Memory address (equiv to 0x%08x)	Pointer

These parameters are also used for reading input. Use scanf() to get values from user input. Here’s a sample showing usage of scanf()

int myint;
printf("Enter an integer: ");
scanf("%d", &myint);

Running this prompts the user, and then saves whatever you enter into myint.

Writing data into, and out of, a program is foundational. I strongly agree that “Having some form of immediate feedback is fairly vital to the hacker’s learning process” (p51). Even just printing the values of a variable can be enormously helpful. The sooner you get feedback from a system, the sooner you can validate assumptions.

Next big concept is type-casting. This lets us (the C compiler) interpret values as a certain data type. Typecasting syntax is: (data type) variable, eg “(int) myvar”. Having explicit types is mainly to prevent programming errors; it’s all just bits at the end of the day.

We use type-casting to save precision with division as well as using pointers for values. It also comes up when dealing with pointer types. Character data type takes up four bytes, so adding one to a character pointer increments the memory four bytes. This gives unexpected behavior when using pointers of one type to refer to memory locations of another type. So, generally we just don’t do that, but if we must we can cast the pointer to fix the size.

Using pointers of the correct type is the best practice. However, at times a void pointer is desirable. Void pointers have type void; they must be typecast when dereferencing or performing pointer arithmetic. In short, void pointers just hold a memory address. We have to tell the compiler what type of address as we use it.

This concludes today’s basic programming discussion. We covered C format strings and type-casting. The big idea was that memory is only bits; it’s up to the compiler to interpret correctly. The programmer guides the compiler to interpretations via data typing.

Looking forward, tomorrow’s discussion will include more programming bits like command-line arguments and variable scoping. We are halfway through the book’s programming discussion. So far I am enjoying the review; the book gives great examples. The book also does a good job showing the larger context through examining program memory. Still, I’m looking forward to finishing the basics and moving on to exploiting some code.

More to come.

Five Five Five

2017-04-28T00:00:00+00:00

Hacking book day 3 whoop whoop! 30 minutes to write and publish here we go. More basic programming concepts than you can shake a stick at.

First up, it’s “Signed, Unsigned, Long, and Short”. These have to do with variable sizing. Signed vars can be + or -; they have a sign. Unsigned, are only positive. All values are stored as binary, so what’s the difference? Signed values require one bit to indicate positive or negative, so they store a smaller range than unsigned. Note that signed negative values are stored as two’s complement. Storing in two’s complement gives us a nice property: negative binary plus it’s oppostive ends up being zero. So we can do subtraction with a simple adder circuit. And finally, long and short just vary the amount of memory, so they store larger or smaller values. The exact amount is architecture-dependent.

Next we turn our attention to pointers. Recall that

The EIP register is a pointer that “points” to the current insruction during a program’s execution by containing its memory address (p43).

This idea, that one area of memory points to another, is used in C as well. Moving physical memory takes time, storage space, and computation, so it’s much easier to simply pass around a pointer to memory. In C, pointers are defined using asterisk (*). The pointer type determines what type of data is pointed to. For example,

int *pointer; // points to an int
char *pointer2; // points to char
int a = 12;
pointer = a;

It’s very important to remember that these pointers hold the address (memory location), not a value. To retrieve memory contents of a variable, we dereference it using the asterisk (*) operator. In the example above, pointer is set to the memory location of variable a. To retrieve the value of a (12), we write *pointer. If we want the memory location of any variable, we simply prepend the ampersand (&) operator. Note that both the asterisk and ampersand notations exist in gdb as well as C.

Tonight’s session was a brief overview of data scoping as well as pointers. Can’t wait to see where we go next.

More to come.