[MUSIC]. 
Hi there, I'm just here to do a quick 
tutorial on how to use the new debugger 
inside our virtual machine. 
I have a little terminal pulled up here, 
and we can jump over into that terminal. 
And quickly look at the files we have 
accessible to us. 
There's this handy little test.c program 
that I'll use to do a quick demo of some 
simple GDB features. 
And then, we're going to jump into 
looking at the first stage of lab two, 
which may be useful to you when you start 
working on that yourself. 
So, here's our little test program, it 
prints, hello world. 
You may have seen something like this at 
some time previously in your life. 
we're going to compile it. 
but we're going to add the special flag G 
for adding Debug information. 
I know Debug doesn't start with G but it 
does end in G. 
So, small, you know, favors. 
so we can compile that and then we have 
this a.out file. 
Going to run that in GDB, the new 
debugger. 
And we're going to put a break point at 
main, the method that we definitely have, 
actually a function. 
And we're going to say run the program 
until that point. 
Now it's going to stop here, and we can 
say, let's see what the source code looks 
like. 
Say, List, shows us all our source code. 
We can also look at the assembly code 
that actually executes each of these 
steps. 
There's a number of ways that we can look 
at this. 
we can step through a single step of the 
C code. 
We've already printed hello world now, 
and we're about to return 0. 
Now what if you didn't have all that 
handy debug information. 
What if instead we compiled it maybe 
accidentally without the debug 
information, we left our source file at 
home. 
So, we can now look at this new a.out 
compiled without debug info. 
So again, break at main, run the file, 
and what do we try and list? 
Well, there's no single table listed. 
We don't have the debug information, we 
can't look at our source. 
We can still look at our assembly, and 
this is going to be true pretty much 
regardless of what you do or don't put 
into your file. 
Which is a little detail that will come 
in extremely handy in lab two. 
We have also this mysterious executable 
file called Bomb. 
We don't know what's in it. 
We can run the disassembler against, or 
the debugger against it. 
But if we try to list the source, we 
don't have any of it. 
So, this is a small difficulty for our 
debugging, but we can I've learned from 
my sources that we may have a method 
called Phase One. 
Somewhere in this bond and look there it 
is. 
We tried to break against a function that 
didn't exist, it's not going to do it. 
So, there definitely is a function called 
Phase One. 
If you also try to look at the current 
assembly code being executed before you 
start running the program, you're also 
not going to have any luck. 
Alright, so let's go look at this Phase 
One program. 
put together by a madman I see. 
So, what is something that we can 
recognize in assembly code? 
Often programmers like to use words like 
Foo and Bar to easily detect them later 
when they turn up in their tests. 
But they're not particularly obvious if 
they're not represented as strings. 
So, maybe we should use something that we 
can definitely recognize like a whole 
bunch of A's. 
All the A's will be represented the same 
way, and we can definitely see them 
later. 
Alright, so well put this input in, now 
we've hit our break point. 
Well again we can't list we don't have 
any source, so what if we disassemble 
instead. 
Alright here's an assembly code that 
looks pretty interesting to us pretty 
familiar too. 
GDB, by the way has a vast amount of help 
you can get help on pretty much any topic 
you are interested in. 
And then once you've looked at the help 
for it, you can get help on your help. 
So, for instance if we want to look at 
health info, it gives us a whole bunch of 
different commands that we can do with 
info. 
We can look at sources, we can look at 
records, we can look at, well, in this 
case, I guess we can't look at sources, 
can we? 
But, we can definitely look at Registers. 
so here's our SP, which you may already 
have learned is the Stack Pointer, this 
is pointing into the stack. 
Here's our IP, the Instruction Pointer. 
C, here's the name of the function that 
we're inside of. 
RAX often holds a return, and the first 
two parameters to a function, will often 
be an RDI, and RSI. 
Certainly in a 62-bit machine like this, 
62? 
Goodness. 
Certainly in a 64-bit machine like this 
one. 
Alright, so we will go back to the 
assembly code, and if you take a step 
like we did before we're going to run all 
the way to the single line of execution 
in the source code and blow off the Bomb. 
So, instead we're going to type all those 
A's back in, and we're going to take one 
step instruction by instruction. 
So, now if you see this little arrow on 
the screen here, this is pointing to the 
func, or the instruction that we're about 
to execute, not the one we've just done. 
This one is particular is pretty 
interesting. 
We're about to make a call to a function 
called Strings not equal. 
Well that sounds like the kind of thing 
that we might care about. 
So, let's look again at these registers, 
and it looks like there's a little more 
going on here than there was before. 
So, you may recall that we can look at 
what's on the stack. 
That could be interesting, looking at the 
stack, NGDB, can be a little bit complex. 
but, basically, any, data source that you 
want to look at, you can type this X. 
And then what we're going to type in is 
in the format number, number of units 
that we want to look at and format, how 
we want to see this data represented. 
If you just type it like this it'll get 
confused, it doesn't understand what 
you're talking about. 
So we say, X, we're going to look at 
let's say 24 words, quad words in this 
case, and oh, let's say HEX. 
Everybody likes HEX, and we're going to 
look at it on the stack so we'll say RSP. 
And here we have all of the things on the 
stack. 
And you'll recognize this address from 
previously when we looked at RSP to see 
where it is. 
Alright, great. 
But, the stack isn't too interesting to 
us because we're looking at a 64 bit 
program. 
So, it's going to be putting its 
arguments to this string's not equal 
function that we're interested in, right 
into registers. 
Well, specifically, the registers that 
we're interested in are likely to be the 
first two registers that arguments get 
stored in. 
So, again we can look at this X, and we 
can say look at two words maybe. 
And we'll represent them in HEX, and 
we'll look at the first argument register 
RDI. 
It's a bunch of 61's, it's almost as if a 
single value is being repeated a bunch of 
times like those A's we typed in. 
Now if there's an easy way that we can 
look at them, that might be better. 
We could say, let's look at these as 
Strings instead of as HEX numbers. 
Oops RDI, sorry about that. 
And look, there's our A's, you can also 
look at them as integers which is not 
particularly useful for us right now. 
by the way, just a quick tangent, I know 
that the way we are representing 
registers in GDB is an awful lot like the 
way that assembly represents Constance. 
This is an unfortunate, but true fact 
that you're just going to have to get 
used to. 
It can be a little confusing at first. 
if we try and tell it to look at a 
register using the assembly code method 
of a percent sign. 
It's not going to know what we're talking 
about. 
I'm not sure why they decided to do it 
this way, they just did. 
Alright, so let's look at that other 
register because we already found our 
input. 
But what could we be looking to see if 
it's equal to. 
Well, we could say let's look, and if 
looking for Strings not equal, so we 
probably want to look at them in String 
format. 
And we'll look at RSI, oh, now there's an 
interesting String. 
I'll put a couple breaks in so that you 
can see it more clearly higher on the 
screen. 
Well I didn't type that string in so I 
wonder where it could have come from. 
Maybe it's important to look at in HEX, 
59? 
That doesn't look nearly as meaningful, 
but let's copy it. 
Oops, that's the wrong kind of copying. 
Copy it, and we'll leave GDB, so I can 
show you really quickly one last feature 
of this Bomb that we have prepared for 
you. 
You can look at a text file, user.txt. 
And we can paste in this value that we've 
just received. 
And we can run this Bomb. 
First let's just run it without any 
input. 
We say Foo Bar Baz, I know what computer 
scientists like, that's not the key. 
Alright, we'll say bomb diffuser.text. 
Well, that's not the key either, but you 
see that I didn't need to enter any 
input. 
It's taking input from this diffuser.text 
file. 
So, is there any input that we've seen 
earlier? 
That might actually be the key to this 
Bomb? 
You should check it out.