I didn't finish the flare-on challenge. I'm reading the write-ups. I actually feel like I learn quite a bit from reading the write-ups, and other people's solutions. There is usually more than one method to solve a problem, and some methods are more efficient than others.
I'm in the midst of the SANS Cyber Defense Challenge. I'm currently in 3rd place. That may change soon because there are some really competitive and brilliant people in this challenge. I was happy to be in the top fifty. I never in my wildest dreams thought that I would be this close. The first and second place winners have a chance to go to San Diego for a couple of days for a chance to be named Ultimate Cyber Defender 2015.
The SANS Pen Testing blog just released a new contest today. It's a simple Twitter contest. All you have to do is take a photo of yourself wearing a NetWars shirt, OR with a coin or SANS sticker, OR with any item associated with SANS, OR with a SANS book, OR with the pen-testing blog website in your browser window and tweet it to @SANSPenTest with the hashtag #SANSHackFest. There is a chance to win free two day admission to HackFest on Nov 16th and 17th. You can enter as much as you like between 9-25-2015 and 10-02-2015. You can check that out at: https://pen-testing.sans.org/blog/pen-testing/2015/09/25/2015-sans-pen-test-hackfest-twitter-contest
Friday, September 25, 2015
Tuesday, September 1, 2015
Flare-On Challenge Part One Solution
Update: I mistakenly thought that the challenge answers were due today. It's actually not due until the 8th, which is next week. Fortunately, I don't think that this answer will affect the outcome. I will be more careful about posting solutions in the future. I apologize to the creators of the Flare-On Challenge. I will continue to work on the challenge then. :)
The Flare-On Challenge 2015 is a challenge created by Fire Eye about digital forensics and reverse engineering. In order to complete the challenge, one must find a series of e-mail addresses and send a message to those addresses to get each part of the challenge. They warned that there is live malware in this challenge. I used a SIFT VM and IDA Pro (Free version) for this part of the challenge. IDA Pro (Free version) ran just fine on WINE.
I did not complete this challenge. I solved one question, which is more than I expected to solve because I have hardly any prior experience in reverse engineering. The only reverse engineering that I have done is for previous challenges. I hope that they release the rest of the files in this challenge, because I tend to learn better by doing something, than seeing or hearing about it.
For the first Flare-On Challenge of 2015, I was given a program, i_am_happy_you_are_to_playing_the_flareon_challenge.exe that simply asked me to find a password.
I looked at the previous flare-on challenge answers to see if there was a similar problem to this one. There was. It was Challenge 3:Shellolololol. I learned that data starting at address 0x401000 can be interesting because according to the solutions from last year at www.fireeye.com/blog/threat-research/2014/11/the_flare_on_challen.html, "it is the beginning of the code section, which commonly is where the beginning of any user-written code exists."
I began looking at that section of code. I'm not familiar with assembly, but after looking at the code for a little bit, and using Google to understand what each instruction did, I saw:
text:0040104D loc_40104D: ; CODE XREF: start+61 j
.text:0040104D mov al, byte_402158[ecx]
.text:00401053 xor al, 7Dh
.text:00401055 cmp al, byte_402140[ecx]
.text:0040105B jnz short loc_40107B
.text:0040105D inc ecx
.text:0040105E cmp ecx, 18h
.text:00401061 jl short loc_40104D
I have studied a little C and Java, so I thought that when the program read in a person's response to "Enter the password", that it needed to put that information in a buffer. The buffer is at address 0x402158. I confirmed that statement by using the jump/jump to address functionality of IDA to jump to address 0x402158 and noted that all of the items in that buffer are set to 0. I didn't run the program and put anything in there, so there aren't any characters to put in those slots. The machine has to reserve a place in memory for them though, so it starts the items in the buffer at 0x402158 at 0. It's called initialization. Initialization of variables, or a buffer in this case, is recommended in most of the programming languages that I have studied.
I noted from the cmp statement that the password was probably started at the address of 0x402140. Cmp in assembly, in this case, means to compare the value in al with the byte stored at 0x402140. When you use cmp in assembly, it affects two flags, the zero flag(zf) and the carry flag(cf). If the byte in the 0x402158 address matches the byte in the 0x402140 address, then it sets the zf flag to 0. Otherwise, it sets the zf flag to 1. In this program's case, it jumps to the "You are a failure" part of the program if the zf is not equal to zero.
If you look later in the code above, it has a jl statement. What that means is that the program is telling the machine to jump to location 0x40104D if ecx is less than 18h. That means that the program is using a loop. The program increments the value at ecx by 1. ECX starts at 0. ECX is incrementing the address where the bytes of the password are being stored. To break out of the loop, the assembly says to compare ecx with 18h. The last password byte is at byte 0x402157. So it says that if ecx has incremented 18 hexidecimal, which it would if it started at 0x402140 and ended at 0x402158, then you need to break out of this loop, so it doesn't follow the next jump instruction once ecx is = 18h.
What the program is doing is xoring each byte in the buffer with the hex character 7D, then comparing each byte in the buffer with each byte of the password. I used the jump/jump to address function of IDA to jump to 0x402140 to confirm my analysis. I noticed a strange line of characters.
1F
8
13h
13h
4
22h
0Eh
11h
4Dh
0Dh
18h
3Dh
1Bh
11h
1Ch
0Fh
18h
50h
12h
13h
53h
1Eh
12h
10h
The similar example from last year showed exactly what to do. All I had to do to reverse engineer this password obfuscation was xor each byte of the password at address 0x402140 with the hex character 7Dh, and I had my answer. I could just take each byte and manually xor each byte, and then convert those values from hex to ascii using one of the many tools online, but there is a faster way. It's called scripting. I purchased a book called The IDA Pro Book: The Unofficial Guide to IDA Pro by Chris Eagle, which I highly recommend. It addressed scripting for IDA in it. Even though the name says, "Pro", it covers the difference between the IDA Pro and Free versions, and how one could effectively use the free version. It also shows excellent examples of assembly language, for those, like me, who don't have a lot of experience with assembly. I'm currently about halfway through the book, but plan on finishing it as soon as I can. (I am not getting paid to tell you about this book.)
The actual script that I used below, I found by using Google. It was at www.stackoverflow.com/questions/13495538/ida-pro-string-function Thanks user1354557 for having the insight to realize that not everyone has IDA Pro. Here is the script that I modified to fit my needs:
Version on Stack Exchange:
auto addr;
auto b;
addr = 0x00401000;
while(1){
b = Byte(addr) ^ 0x1F;
PatchByte(addr, b);
if (b == '\0'){
break;
}
addr = addr + 1;
}
I didn't need to start at that address, so I changed the starting address. I was xoring with the 7Dh byte, not 1Fh. I didn't care for the depending on a nul terminator to break out of the loop. I preferred stopping at the last address in the password byte addresses because there may be other code that would be overwritten if there is not a nul terminator to break out of the loop. So here is my modified version:
Modified version:
auto addr;
auto b;
addr = 0x402140;
while(1){
b = Byte(addr) ^ 0x7D;
PatchByte(addr, b);
if (addr == 0x402157){
break;
}
addr = addr + 1;
}
The byte at 402140 didn't automatically show a comment with a "b". There was already a cross reference comment in that spot, so maybe that had something to do with it? However, the script properly changed the value. So, all I had to do was to convert that one hex value into an ascii character, and add my own comment. Update: Used the right click command "undefine" at the address 0x402140, and it showed the "; b" comment. I guess that IDA thought that that character was something else, not a character. Right-clicking on it again gives the option of converting all the characters to a string.
62h ; b
75h ; u
6Eh ; n
6Eh ; n
79h ; y
5Fh ; _
73h ; s
6Ch ; l
30h ; 0
70h ; p
65h ; e
40h ; @
66h ; f
6Ch ; l
61h ; a
72h ; r
65h ; e
2Dh ; -
6Fh ; o
6Eh ; n
2Eh ; .
63h ; c
6Fh ; o
6Dh ; m
The password is:
bunny_sl0pe@flare-on.com
I sent a message to that e-mail and got the next challenge.
The Flare-On Challenge 2015 is a challenge created by Fire Eye about digital forensics and reverse engineering. In order to complete the challenge, one must find a series of e-mail addresses and send a message to those addresses to get each part of the challenge. They warned that there is live malware in this challenge. I used a SIFT VM and IDA Pro (Free version) for this part of the challenge. IDA Pro (Free version) ran just fine on WINE.
I did not complete this challenge. I solved one question, which is more than I expected to solve because I have hardly any prior experience in reverse engineering. The only reverse engineering that I have done is for previous challenges. I hope that they release the rest of the files in this challenge, because I tend to learn better by doing something, than seeing or hearing about it.
For the first Flare-On Challenge of 2015, I was given a program, i_am_happy_you_are_to_playing_the_flareon_challenge.exe that simply asked me to find a password.
I looked at the previous flare-on challenge answers to see if there was a similar problem to this one. There was. It was Challenge 3:Shellolololol. I learned that data starting at address 0x401000 can be interesting because according to the solutions from last year at www.fireeye.com/blog/threat-research/2014/11/the_flare_on_challen.html, "it is the beginning of the code section, which commonly is where the beginning of any user-written code exists."
I began looking at that section of code. I'm not familiar with assembly, but after looking at the code for a little bit, and using Google to understand what each instruction did, I saw:
text:0040104D loc_40104D: ; CODE XREF: start+61 j
.text:0040104D mov al, byte_402158[ecx]
.text:00401053 xor al, 7Dh
.text:00401055 cmp al, byte_402140[ecx]
.text:0040105B jnz short loc_40107B
.text:0040105D inc ecx
.text:0040105E cmp ecx, 18h
.text:00401061 jl short loc_40104D
I have studied a little C and Java, so I thought that when the program read in a person's response to "Enter the password", that it needed to put that information in a buffer. The buffer is at address 0x402158. I confirmed that statement by using the jump/jump to address functionality of IDA to jump to address 0x402158 and noted that all of the items in that buffer are set to 0. I didn't run the program and put anything in there, so there aren't any characters to put in those slots. The machine has to reserve a place in memory for them though, so it starts the items in the buffer at 0x402158 at 0. It's called initialization. Initialization of variables, or a buffer in this case, is recommended in most of the programming languages that I have studied.
I noted from the cmp statement that the password was probably started at the address of 0x402140. Cmp in assembly, in this case, means to compare the value in al with the byte stored at 0x402140. When you use cmp in assembly, it affects two flags, the zero flag(zf) and the carry flag(cf). If the byte in the 0x402158 address matches the byte in the 0x402140 address, then it sets the zf flag to 0. Otherwise, it sets the zf flag to 1. In this program's case, it jumps to the "You are a failure" part of the program if the zf is not equal to zero.
If you look later in the code above, it has a jl statement. What that means is that the program is telling the machine to jump to location 0x40104D if ecx is less than 18h. That means that the program is using a loop. The program increments the value at ecx by 1. ECX starts at 0. ECX is incrementing the address where the bytes of the password are being stored. To break out of the loop, the assembly says to compare ecx with 18h. The last password byte is at byte 0x402157. So it says that if ecx has incremented 18 hexidecimal, which it would if it started at 0x402140 and ended at 0x402158, then you need to break out of this loop, so it doesn't follow the next jump instruction once ecx is = 18h.
What the program is doing is xoring each byte in the buffer with the hex character 7D, then comparing each byte in the buffer with each byte of the password. I used the jump/jump to address function of IDA to jump to 0x402140 to confirm my analysis. I noticed a strange line of characters.
1F
8
13h
13h
4
22h
0Eh
11h
4Dh
0Dh
18h
3Dh
1Bh
11h
1Ch
0Fh
18h
50h
12h
13h
53h
1Eh
12h
10h
The similar example from last year showed exactly what to do. All I had to do to reverse engineer this password obfuscation was xor each byte of the password at address 0x402140 with the hex character 7Dh, and I had my answer. I could just take each byte and manually xor each byte, and then convert those values from hex to ascii using one of the many tools online, but there is a faster way. It's called scripting. I purchased a book called The IDA Pro Book: The Unofficial Guide to IDA Pro by Chris Eagle, which I highly recommend. It addressed scripting for IDA in it. Even though the name says, "Pro", it covers the difference between the IDA Pro and Free versions, and how one could effectively use the free version. It also shows excellent examples of assembly language, for those, like me, who don't have a lot of experience with assembly. I'm currently about halfway through the book, but plan on finishing it as soon as I can. (I am not getting paid to tell you about this book.)
The actual script that I used below, I found by using Google. It was at www.stackoverflow.com/questions/13495538/ida-pro-string-function Thanks user1354557 for having the insight to realize that not everyone has IDA Pro. Here is the script that I modified to fit my needs:
Version on Stack Exchange:
auto addr;
auto b;
addr = 0x00401000;
while(1){
b = Byte(addr) ^ 0x1F;
PatchByte(addr, b);
if (b == '\0'){
break;
}
addr = addr + 1;
}
I didn't need to start at that address, so I changed the starting address. I was xoring with the 7Dh byte, not 1Fh. I didn't care for the depending on a nul terminator to break out of the loop. I preferred stopping at the last address in the password byte addresses because there may be other code that would be overwritten if there is not a nul terminator to break out of the loop. So here is my modified version:
Modified version:
auto addr;
auto b;
addr = 0x402140;
while(1){
b = Byte(addr) ^ 0x7D;
PatchByte(addr, b);
if (addr == 0x402157){
break;
}
addr = addr + 1;
}
The byte at 402140 didn't automatically show a comment with a "b". There was already a cross reference comment in that spot, so maybe that had something to do with it? However, the script properly changed the value. So, all I had to do was to convert that one hex value into an ascii character, and add my own comment. Update: Used the right click command "undefine" at the address 0x402140, and it showed the "; b" comment. I guess that IDA thought that that character was something else, not a character. Right-clicking on it again gives the option of converting all the characters to a string.
62h ; b
75h ; u
6Eh ; n
6Eh ; n
79h ; y
5Fh ; _
73h ; s
6Ch ; l
30h ; 0
70h ; p
65h ; e
40h ; @
66h ; f
6Ch ; l
61h ; a
72h ; r
65h ; e
2Dh ; -
6Fh ; o
6Eh ; n
2Eh ; .
63h ; c
6Fh ; o
6Dh ; m
The password is:
bunny_sl0pe@flare-on.com
I sent a message to that e-mail and got the next challenge.
Subscribe to:
Posts (Atom)