REE-Project

Reverse Engineering Project Notes

10/09/2016

1. Started new visual studio project, added Main_Students.cpp, SHA-256.cpp, SHA-256.h, and Test_Main_Students.cpp
2. Ran EDTool_D.exe from command line, successfully decrypted "encrypted.tx".
3. Opened EDTool_D.exe with WinDbg and Ida Pro.
4. Ran program in WinDbg without arguments, got error output "Error – Could not open input file ..."
5. Searched for error string in Ida Pro, found at 498D80. Referenced by sub_434EB0. Followed link.
6. Renamed sub_434EB0 to openInputFile as refered to in Main_Student.cpp
7. Renamed sub_434A20 to decryptText as refered to in Main_Student.cpp

10/23/2016

1. Previous Notes were for the wrong project file. Thankfully locations for the two functions were the same. Repeating work from above on new PE file.
2. Pretty sure sub_434F40 is Main_Student. Renamed.
3. Stepping through Main_Student, found locfation of default file name at 00498db8. Very interesting stuff right after:
   1. cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0
   2. 248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1
   3. ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
   4. abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq
4. Pretty sure function sub_43CDA0 at 00434ED7 is to fopen. Renamed.
5. Pretty sure function sub_43E230 at 00434EF1 is printf. Renamed
6. function sub_0043DD20 at 00434A9B is probably a call to memset. Renamed
7. Not sure what the call at 00434AB3 is doing, but I think it may be fread or mmap or something similiar. On return, the value is %$2TTSkjshdfo9087@, which is the start of the encrypted.txt file.
8. The call at 00434AC2 sends the above ptr as param. The return is 0x13 which is 19 (the length of the ptr). This is probably strlen. The program then compares this value to 1 and 256. If below 1 or above 256, print error.
9. Stopped at loc_434B03:

11/01/2016

1. After reading through the call at 00434AC2, pretty sure that is strlen. Renamed
2. ebp+154 holds the byte length of the password.
3. loc_434B03 has to do with hashing - need to look at this
4. Renamed call at 00434B73 to malloc
5. ebp+160 contains the number of bytes to allocate and ebp+114 is the pointer to the allocated space
6. arg0 is the pointer to the encrypted.txt file
7. started going thru the call at 00434AB3. It does refer to fgets - but it also does some comparisions. (got back to this on 11/05 - it is fgets) I'm tired. Going to sleep.

11/03/2016

1. looking at call to sub_433153 at break point 00434B37. Signature is siminiar to ret = func(0, fp, len_pass-1, buf), where fp is the pointer to the encrypted.txt file, len_pass-1 is the length of the password -1, and buf is a pointer to a local variable that hasn't been used yet.
2. Immediatly after pushing ebp and moving esp into ebp, apon entering the function calls sub_432483 with a value stored in eax (not pushed to stack). It does some address arithmetic in a loop using the value in eax as a counter of sorts. Not sure what's happening. No return value. esp has chaned, difference between ebp and esp is the value pushed into eax. This call is some funky way of making room on the stack for local variables.
3. Nest, it checks if the first arg was 0. If so, it calls memset(buf, 0, 64). If not, it looks like it opens the file in rb mode and reads arg_0 bytes. Either way arg_0 get stored in local variable vaar_C.
4. Next (at 0043BFFF) it calls sub_432A55 with a pointer to a local variable as a parameter. This is where I stop for now. Been at the office for 10 hours, think my butt may be rooted to this chair. Need to go home.

11/05/2016

1. sub_434FE0 (jmp point from sub_432A55) loads 00 00 00 00 00 00 00 00 67 e6 09 6a 85 ae 67 bb 72 f3 6e 3c 3a f5 4f a5 7f 52 0e 51 8c 68 05 9b ab d9 83 1f 19 cd e0 5b into eax and returns
2. Was looking back on fopen and ended up at the function call at t00434AB3 - stated to go thru that - found "fgets" in there - so remamed this unknow function as fgets. I was pretty sure it was reading the file and knew it wasn't fread based on the parameters.
3. Ok... So it looks like sub_43BF80 is calling sha256 - got to a point in Windbg where I was no longer in any recongnizable code - so I took a look at the sha256 cpp, and found that the call to sub_432A55 returned the sha256_starts stuff. So remaing sub_432A55, and that means that var_7C is a sha256_context structure. This also means that the call to sub_433153 at 00434B37 is calling sha256(char *fileName, char *dataBuffer, DWORD dataLength, unsigned char sha256sum[32]) with sha256(0, fp, passlength, sha256sum[32]). so var_13C in dcryptText is the sha 256 sum. COOL! That was a crazy function to run through. Giant loop, lots of jumping around. So glad that's not something we have to reverse.
4. I've noted that often at the start of a function the compiler fills the space on the stack that was allocated to local variables with 0xCC.... Read up on this, and it seems that the program was compiled in debug mode! (http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new) So hte mov ecx, ## mov eax, 0xCCC...h rep stosd appears. No a big deal - skip it when you see it.
5. Cleaned up some of the comments in ida
6. Starting writing the code for decryptText in Main_Students.cpp. Got to the call to sha256. So far every thing is checking out.
7. function call at 00434BC3 seems to be calling fread (follow the jmps a bit to get there) Making var_114 the fileBuffer. Added cpp code to malloc the fileBuf and read file.
8. 00434BCB is the start of a for loop, using var_16C as a counter.
9. This for loop seems to be changing char by char the values in fileBuf. It runs thru 3 function calls and an xor (one of two xors depending on the counter). I outlined the calls to these functions, and set up the code in cpp. In the xor block - its using two variables that (as far as I can tell, are not initialized). Stopping for now, but need to pick up at break point 00434BE6.

11/06/2016

1. Worked on func1 and func2. No too bad, still need to check if output matches the debugger. func3 is something else. I'll come back to that - or ask JO a question.
2. So... func3 has two modes. We have a hard coded 0. I went ahead and programmed the 0 option (not a problem - still have to figure out what the other one does.).
3. I figured out the xor business as the end, just stepped thru windbg to verify. Got the dcrypt function programmed. Looks good. Sucessfully decrypts the text. Now we have to invert the decryption. Cheers!