Password Lab: Breaking into things, for great good

Released: 12:00 AM Monday, March 30th, 2020.

Due: 11:59 PM Friday, April 10th, 2020.

This assignment has us reverse engineer some programs and find the appropriate passwords.

Weight: 10% of your total 50% Lab Grade

Note: You, again, want to get a head start on this!

Introduction

For this assignment, you will be given a set of executables without the source code. Each executable expects a line of input to be given and it will tell you whether or not the input is the expected password.

You will use the tools we have discussed throughout the course, and perhaps some new tricks, to determine how the executables work. With that knowledge, you can then determine the password and use it to unlock the executable.

For this assignment, we will only expect you to do the first three out of the total five executables. They begin with your username and end with a number indicating which of the five they are.

The difficulty for each executable is roughly understood by the number appended to it. <user>_1 is constructed in a simple way, relative to the others. Yet, <user>_5 has had some processing done on it to obstruct the normal process a bit. Yet, the difficulty comes down to your own capability with the tools.

If you are new to these tools and have not been using them on your other assignments, starting early is wise.

Downloading / Usage

To get your executables, on thoth, create a directory and navigate to it. Then, use the following command on thoth:

cp /u/SysLab/$USER/* .

This will copy the executables to your own space. Now, you can run each of them and do whatever you think of to learn how they work.

For instance, given my username is abc3:

./abc3_1

It will hang because it expects you to type in the password. Since I do not know what it is, I will type in some garbage. (If it still hangs after pressing enter it is expecting a longer string. This is a good hint to the expected password length.)

./abc3_1
asdfjasdflasdfhjkasd
Sorry! Not correct!

Ah, dang. I wasn’t very lucky! The expected strings have been generated at random, so you are not likely to be able to determine them from brute force.

Yet, after looking at the executable with the tools available, I can discover the appropriate password.

./abc3_1
WDgTPwrlnAOOhsYCbbKEsIeUqksfLG
Congratulations!
Unlocked with passphrase WDgTPwrlnAOOhsYCbbKEsIeUqksfLG

Often the passwords will be nonsense strings of characters and symbols. There may be more than one possible password, but you only need to come up with a single working password.

The more difficult programs may involve randomness of some kind during the runtime of the program, so the password may change slightly from one run to the next after a small window of time. For these, you will have to include all possible passwords, of which there will be a short list. This is not the case for any of the first three programs.

Implementation

You aren’t writing any code! Take a break from writing code (unless you want to write some helpful scripts for yourself.) This is about reading.

Helpful Tools

For this assignment, you will look toward using a set of useful debugging and exploratory tools. These are all useful, in general, for reverse engineering work.

strings

The first tool is a simple one. The strings command, when given any data file, which includes executables, it will print out every ASCII-encoded string it can find. It simply looks for uninterrupted patterns of valid printable characters and prints out each one that is of a certain length.

$ strings ./abc3_1
PTRhP
<[^_]
<8#}
L[^_]
,[^_]
[^_]
[^_]
[^_]
fffff.
[^_]
tr;E
...

You’ll find that there are a LOT of strings… you may want to just save the output to a file and open that up in a text editor.

$ strings ./abc3_1 > strings_1.txt

One strategy is to look for strings you know something about already. Often useful strings are near well-known strings.

objdump

The next great tool is objdump which can disassemble executables. Again, we just specify the executable and some flags and it will print the output to the screen. Again, we should probably redirect the output to a text file.

$ objdump -d ./abc3_1 > asm_1.asm

The -d flag disassembles the .text section of this ELF executable. You can explore other flags by running objdump -h to see a listing of them.

The output of objdump, here, will be the assembly dump. It shows several columns which we looked at in lecture. The left-hand column is the instruction address, which will be useful for gdb. The middle column is the machine code represented in hexadecimal octets. The right-hand column is the assembly code.

You will see the names of functions in the form 080482cf <main>: where the left-hand side is the address of that function and the part within the brackets is the name. For some of the most difficult executables, the names are not available. For most of the executables, the names are not that meaningful.

gdb

The final tool is gdb, which we have explored in lecture and recitation worksheets. This is a traditional debugger which allows you to pause and resume execution of a program while examining memory and register state as you go.

With gdb, and with the other tools, you should be able to find a reasonable place to start looking. Please look at the gdb worksheet for a good beginner’s tutorial on using gdb to reverse engineer an executable.

To use gdb, you simply invoke it with the executable as an argument.

$ gdb ./abc3_1

Then you follow the example set in the worksheet on how to proceed.

Your turn

For each of the first three executables, that is the ones ending in _1, _2, and _3, determine the password necessary to unlock. There may be more than one correct answer. You will only need to provide a single correct password to Gradescope for each program.

For some small extra credit, there will be an option to submit the answers to the _4 and _5 programs that will be open throughout the remainder of the semester. Note: Only the first three programs are due by the given due date.

Submission

You will submit the passwords to gradescope using plain text files named pw1, pw2 and pw3 to Gradescope. Each text file will contain just the password you want to use and nothing else.

When the submission window is open for passwords 4 and 5 (extra credit), those will work the same way using pw4 and pw5 in a separate Gradescope “assignment.”

The autograder will attempt to use every line of your text file as a password. So, if the password is arbitrary, you can specify every possible password and it will use the correct one. (This is a hint to the extra credit submission, mostly.)

Note: This means that your password cannot span multiple lines! It will not accept it, even if the password technically works on thoth.