{"id":19156,"date":"2016-09-15T16:53:15","date_gmt":"2016-09-15T23:53:15","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=19156"},"modified":"2016-09-29T09:43:56","modified_gmt":"2016-09-29T16:43:56","slug":"labyrenth-capture-the-flag-ctf-windows-track-1-6-solutions","status":"publish","type":"post","link":"https:\/\/origin-researchcenter.paloaltonetworks.com\/blog\/2016\/09\/labyrenth-capture-the-flag-ctf-windows-track-1-6-solutions\/","title":{"rendered":"LabyREnth Capture the Flag (CTF): Windows Track 1-6 Solutions"},"content":{"rendered":"

Welcome back to our blog series where we reveal the\u00a0solutions\u00a0to\u00a0LabyREnth, the Unit 42 Capture the Flag (CTF)<\/a>\u00a0challenge. We\u2019ll be revealing the\u00a0solutions<\/a>\u00a0to one challenge track per week. Next up, the Windows track challenges 1 through 6, followed by 7 through 9 next week.\u00a0<\/p>\n

Windows 1 Challenge: Deez bugs are bad bugs.<\/strong><\/h3>\n

Challenge Created By: Richard Wartell @wartortell<\/a><\/em><\/p>\n

We are given a PE file that we open in DetectItEasy and see that it is packed with UPX.<\/p>\n

\"ctf_windows_1\"<\/span><\/div><\/a><\/p>\n

We can try and unpack it with upx \u2013d, but it couldn\u2019t be that easy.<\/p>\n

upx -d AntiD.exe\r\n                       Ultimate Packer for eXecutables\r\n                          Copyright (C) 1996 - 2013\r\nUPX 3.91        Markus Oberhumer, Laszlo Molnar & John Reiser   Sep 30th 2013\r\n\r\n        File size         Ratio      Format      Name\r\n   --------------------   ------   -----------   -----------\r\nupx: AntiD.exe: CantUnpackException: file is modified\/hacked\/protected; take care!!!\r\n\r\nUnpacked 0 files.\r\n<\/pre>\n
It looks like we will have to unpack this ourselves before we can solve it.\u00a0 UPX uses the pushad instruction at the beginning to push the registers on to the stack so that it can retrieve them after unpacking and jumping to the original entry point.\u00a0 We can script IDA\u2019s debugger to set a hardware read breakpoint at the location of the pushed registers on the stack to get us close to the OEP.<\/p>\n
import idc\r\nimport idaapi\r\nimport idautils\r\n\r\nidc.AddBpt(ScreenEA())\r\n\r\nidc.LoadDebugger(\"win32\", 0)\r\nidc.StartDebugger(\"\", \"\", \"\")\r\n\r\nidc.ResumeProcess()\r\nidc.GetDebuggerEvent(WFNE_SUSP, -1);\r\n\r\naddress = idc.GetRegValue('ESP') - 1\r\nidc.AddBptEx(address, 1, BPT_RDWR)\r\n\r\nidc.ResumeProcess()\r\n<\/pre>\n
After we hit our breakpoint, we can remove the breakpoint and run until the tail jump that gets us to the original entry point.<\/p>\n
\"ctf_windows_2\"<\/span><\/div><\/a><\/p>\n
popa Instruction Followed by the Tail Jump<\/em><\/p>\n
We can take the jump to the unpacked code and then use Scylla with our new found OEP to dump the process.<\/p>\n
\"ctf_windows_3\"<\/span><\/div><\/a><\/p>\n
We can open our unpacked executable in Binary Ninja<\/a> and can see there is a path that prints the good boy message and one that prints the bad boy message.\u00a0 There is a function called right before the branch that checks the key and determines what path we will take.<\/p>\n
\"ctf_windows_4\"<\/span><\/div><\/a><\/p>\n
Main Showing the Good Boy and Bad Boy paths<\/em><\/p>\n
If we look at the function we renamed to check_key, we can see that it moves bytes on to the stack and then checks to see if the input is 16 bytes long.<\/p>\n
\"ctf_windows_5\"<\/span><\/div><\/a><\/p>\n
The program then enters a series of anti-debugging checks that will cause the function to return 0 (FALSE) if they are triggered.\u00a0 Before each check, there is also a string encoding operation performed against our string.<\/p>\n
\"ctf_windows_6\"<\/span><\/div><\/a><\/p>\n
The first anti-debugging check is a call to CheckRemoteDebuggerPresent, which checks to see if the process is being debugged.<\/p>\n
\"ctf_windows_7\"<\/span><\/div><\/a><\/p>\n
The second anti-debugging check is a call to FindWindowW checking for a Window named OLLYDBG, which is a popular debugger used by analysts.<\/p>\n
\"ctf_windows_8\"<\/span><\/div><\/a><\/p>\n
The third anti-debugging check is a call to IsDebuggerPresent, which checks to see if the process is being debugged.<\/p>\n
\"ctf_windows_9\"<\/span><\/div><\/a><\/p>\n
The fourth and final anti-debugging check uses the assembly instruction rdtsc twice as a timing check to see if the process is executing slowly and probably being debugged.<\/p>\n
\"ctf_windows_10\"<\/span><\/div><\/a><\/p>\n
If we pass all the anti-debugging checks, we end up getting the final string operation, which checks the result of all the operations against an offset in the initial buffer of bytes. If they are not equal, the function returns 0 (FALSE). But if they are equal, the result is added, which is used as the XOR key in the final operation.<\/p>\n
\"ctf_windows_11\"<\/span><\/div><\/a><\/p>\n
We can copy off the initial buffer and rewrite the operations in python, so that we can obtain the key.<\/p>\n
buffer = [0x8C, 0xF1, 0x53, 0xA3, 0x08, 0xD7, 0xDC, 0x48, 0xDB, 0x0C, 0x3A, 0xEE, 0x15, 0x22, \r\n0xC4, 0xE5, 0xC9, 0xA0, 0xA5, 0x0C, 0xD3, 0xDC, 0x51, 0xC7, 0x39, 0xFD, 0xD0, 0xF8, 0x3B, \r\n0xE8, 0xCC, 0x03, 0x06, 0x43, 0xF7, 0xDA, 0x7E, 0x65, 0xAE, 0x80 ]\r\n\r\nanswer = []\r\nc = 0\r\n\r\nfor i in buffer:\r\n    for x in range(31, 127):\r\n        a = (x ^ 0x33) & 0xFF\r\n        a = (a + 68) & 0xFF\r\n        a = (a ^ 0x55) & 0xFF\r\n        a = (a - 102) & 0xFF\r\n        a = (a ^ (c & 0xFF) & 0xFF)\r\n        if a == i:\r\n            answer.append(chr(abs(x)))\r\n            break\r\n    c += a\r\n\r\nprint(\"\".join(answer))\r\n<\/pre>\n
When we run the script we get the key.<\/p>\n
python solve.py<\/p>\n
PAN{C0nf1agul4ti0ns_0n_4_J08_W3LL_D0N3!}<\/p>\n
Windows 2 Challenge: What does the goat say?<\/strong><\/h3>\n
Challenge Created By: Richard Wartell @wartortell<\/a><\/em><\/p>\n
\"ctf_windows_12\"<\/span><\/div><\/a><\/p>\n
We can open it in dnSpy to decompile and debug.\u00a0 We can see the key_click function looks interesting because it is tracking a state if keys are pressed in a certain order.<\/p>\n
\"ctf_windows_13\"<\/span><\/div><\/a><\/p>\n
The keys are numbered from left to right starting at 0 for the white keys and the same for the black keys.\u00a0 If we press the keys in the correct order do_a_thing() is called.<\/p>\n
\"ctf_windows_14\"<\/span><\/div><\/a><\/p>\n
This function plays a funny David Bowie video while the key scrolls in ascii art behind.<\/p>\n
\"ctf_windows_15\"<\/span><\/div><\/a><\/p>\n
\"ctf_windows_16\"<\/span><\/div><\/a><\/p>\n
PAN{B4BY_Y3LL5_5O_LOUD!}<\/p>\n
Windows 3 Challenge: Gotta keep your Squirtle happy <\/strong><\/h3>\n
Challenge Created By: Tyler Halfpop @0xtyh<\/a><\/em><\/p>\n
We are given an executable for the Squirtle challenge.\u00a0 When we run the binary we see some ascii art of Squirtle and a check for a password.\u00a0 If we get the password wrong, we sadly find out that we just killed a Squirtle and the program exits.<\/p>\n
\"ctf_windows_17\"<\/span><\/div><\/a><\/p>\n
Dead Squirtle from an Incorrect Password<\/em><\/p>\n
We can open the binary in Binary Ninja<\/a> and take a look at the main function. If we look at the first branch instruction, there is a function call right before at 401070 that checks the password. We can see that it is just a string compare with the string \u201cincorrect\u201d.<\/p>\n
\"ctf_windows_18\"<\/span><\/div><\/a><\/p>\n
Password Check Function<\/em><\/p>\n
If we type the password correctly we happily find out that we didn\u2019t kill a Squirtle and we get some more output. We have to pass some anti-debugging and anti-vm checks and then we are told that the answer is written in an answer.jpg file.<\/p>\n
\"ctf_windows_19\"<\/span><\/div><\/a><\/p>\n
Correct Password Output<\/em><\/p>\n
There is an answer.jpg file written after we ran the program, but it is corrupted so we need to figure out how to make the program write it correctly to disk. We can see at the end of the main function there is a loop with a multi-byte XOR key.<\/p>\n
\"ctf_windows_20\"<\/span><\/div><\/a><\/p>\n
XOR Loop Writing the answer.jpg file<\/em><\/p>\n
We can assume that if we pass each step we will get the correct key that will output the correct image. At each stage there is a check and then some fake rand() == rand() checks with some funny messages to obfuscate the code.\u00a0 Thankfully there are also helpful hints at each stage if we get stuck or are unsure of the correct path.<\/p>\n
\"ctf_windows_21\"<\/span><\/div><\/a><\/p>\n
Sleep\/GetTickCount Check along with fake rand checks<\/em><\/p>\n
The first check is to see if there is a common debugger window class found.<\/p>\n
BOOL wdw_class()\r\n{\r\n\tHWND hOlly = FindWindow(_T(\"OLLYDBG\"), NULL);\r\n\tHWND hIDA = FindWindow(_T(\"QWidget\"), NULL);\r\n\tHWND hWdbg = FindWindow(_T(\"WinDbgFrameClass\"), NULL);\r\n\tHWND hImm = FindWindow(_T(\"ID\"), NULL);\r\n\r\n\tif ((hOlly) || (hIDA) || (hWdbg) || (hImm))\r\n\t{\r\n\t\treturn TRUE;\r\n\t}\r\n\r\n\treturn FALSE;\r\n}\r\n<\/pre>\n
The second check is to look at the Process Environment Block at offset fs: [30h+2] to see if the process is being debugged.<\/p>\n
BOOL fs_chk(VOID)\r\n{\r\n\tchar IsDbgPresent = 0;\r\n\r\n\t__asm {\r\n\t\tmov eax, fs:[30h]\r\n\t\t\tmov al, [eax + 2h]\r\n\t\t\tmov IsDbgPresent, al\r\n\t}\r\n\tif (IsDbgPresent)\r\n\t{\r\n\t\treturn TRUE;\r\n\t}\r\n\treturn FALSE;\r\n}\r\n<\/pre>\n
The third check uses the Windows API GetTickCount() to make sure the system hasn\u2019t been freshly booted.<\/p>\n
DWORD Counter = GetTickCount();\r\nif (Counter < 0xFFFFF) {\r\n<\/pre>\n
The fourth check used Sleep along with GetTickCount() and wanted you to bypass the sleep call.<\/p>\n
Sleep(1000);\r\nDWORD Counter2 = GetTickCount();\r\nCounter2 -= Counter;\r\nif (Counter2 > 0xFF)\r\n<\/pre>\n
The fifth check just used the Windows API IsDebuggerPresent to find out if the process is being debugged. The sixth check similarly called the Windows API CheckRemoteDebuggerPresent to find out if the process was being debugged.<\/p>\n
The seventh stage checked to see if there are greater than 2 CPUs.<\/p>\n
BOOL cpu_num()\r\n{\r\n\tSYSTEM_INFO siSysInfo;\r\n\tGetSystemInfo(&siSysInfo);\r\n\tif (siSysInfo.dwNumberOfProcessors < 2)\r\n\t{\r\n\t\treturn TRUE;\r\n\t}\r\n\treturn FALSE;\r\n}\r\n<\/pre>\n
The eighth stage checked to see if there were more than 1024 GB of RAM.<\/p>\n
MEMORYSTATUSEX statex;\r\n\tstatex.dwLength = sizeof(statex);\r\n\r\n\tGlobalMemoryStatusEx(&statex);\r\n\tif ((statex.ullTotalPhys \/ 1024) < 1048576)\r\n<\/pre>\n
The final check looked to see if the CPU hypervisor bit was set.<\/p>\n
BOOL hv_bit(VOID)\r\n{\r\n\tint CPUInfo[4] = { -1 };\r\n\r\n\t__cpuid(CPUInfo, 1);\r\n\tif ((CPUInfo[2] >> 31) & 1)\r\n\t{\r\n\t\treturn TRUE;\r\n\t}\r\n\r\n\treturn FALSE;\r\n}\r\n<\/pre>\n
We can step through the program in a binary and make sure the correct path is taken. Then we will get the correct image.<\/p>\n
\"ctf_windows_22\"<\/span><\/div><\/a><\/p>\n
Graph Trace of the Correct Path<\/em><\/p>\n
We could also get the correct key at each stage and grab the buffer of the XOR\u2019d image and decrypt it with python.<\/p>\n
def xor(data, key):\r\n    l = len(key)\r\n    return bytearray((\r\n        (data[i] ^ key[i % l]) for i in range(0,len(data))\r\n    ))\r\n\r\ndata = bytearray(open('xor.jpg', 'rb').read())\r\n\r\nkey = \r\nbytearray([0xAA,0xBB,0xCC,0x11,0x22,0x33,0xEE,0xCC,0x33,0x80,0x2e,0xeb,0xfe,0xff,0xcc])\r\n\r\nwith open('unxor.jpg', \"w\") as f:\r\nf.write(xor(data, key))\r\n<\/pre>\n
\"ctf_windows_23\"<\/span><\/div><\/a><\/p>\n
Correct Image<\/em><\/p>\n
We can finally decode the binary and obtain the key (Sorry :)).<\/p>\n
PAN{Th3_$quirtL3_$qu@d_w@z_bLuffiNg}<\/p>\n
Windows 4 Challenge: 99 bottles of beer on the wall, 99 bottles of beer. Take one down and pass it around, 98 bottles of beer on the wall.\u00a0 Nah, you need to just pass the jugs of beer around.<\/strong><\/h3>\n
Challenge Created By: Jacob Soo @_jsoo_<\/a><\/em><\/p>\n
For this particular challenge<\/a>, participants were given an x64 binary asking for a valid serial number.<\/p>\n
If the serial number is wrong, they should see the image below.<\/p>\n
\"ctf_windows_24\"<\/span><\/div><\/a>This seems like those traditional crackmes. Let\u2019s try to find the function that is checking users\u2019 input. In order to find it, we should always look for suspicious strings\u00a0if applicable.<\/p>\n
Using Hopper, we found the following strings as indicated in the image below.<\/p>\n
\"ctf_windows_25\"<\/span><\/div><\/a><\/p>\n
So let\u2019s pick one of the \u201cstrings\u201d and see where it was referenced.<\/p>\n
\"ctf_windows_26\"<\/span><\/div><\/a><\/p>\n
Ok, let\u2019s try and see whether we can find any GetDlgItemText\/GetDlgItemTextW<\/strong> API calls. Ok, it seems like we got one at 140001464<\/strong>.<\/p>\n
\"ctf_windows_27\"<\/span><\/div><\/a><\/p>\n
If we step debug it and follow the flow, we will come across a string length check at 1400014b3<\/strong>. Now we know that the input string must be 32 characters in length.<\/p>\n
Stepping through again, at 140001500<\/strong> we will encounter a check to ensure that the input characters must be 1, 2 or 3.\u00a0 This makes sure that the serial for this challenge is only comprised of 1, 2 and 3.<\/p>\n
If we were to analyze the application at 140001750<\/strong>, we can see that there is an array with an initial capacity of [0, 13, 7].\u00a0 However the maximum capacity of the \u201cjugs\u201d is [19, 13, 7] and the expected end state is having the array be [10, 10, 0].\u00a0 You basically have three \u201cjugs\u201d with a size of 7, 13 and 19.\u00a0 The 7 and 13 size \u201cjugs\u201d are filled and the container with size 19 is empty. What you need is 10 in two of the containers (13 and 19).<\/p>\n
Let\u2019s re-write it in pseudo codes.\u00a0 Let\u2019s assume that 3 \u201cjugs\u201d are under the array, M and the 3 jugs are a,b and c.<\/p>\n
for (int i = 0; i < szSerial.Length; i += 2){\r\n    a = convert_it_to_int(Substring_of_szSerial(i, 1));\r\n    b = convert_it_to_int (Substring_of_szSerial (i + 1, 1));\r\n    if (a != b){\r\n        switch (b){\r\n            case 1:\r\n                c = 19;\r\n                break;\r\n            case 2:\r\n                c = 13;\r\n                break;\r\n            case 3:\r\n                c = 7;\r\n                break;\r\n        }\r\n        if ((M[b] + M[a]) > c){\r\n            M[a] += M[b] - c;\r\n            L[b] = c;\r\n        }else{\r\n            M[b] += L[a];\r\n            M[a] = 0;\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
At first it may seem to be very confusing what is actually going on here. But let\u2019s take a closer look.<\/p>\n
This is the limit of the jugs.<\/p>\n
Limit: 19    13    7\r\n-----------------------\r\n             A     B     C\r\nJug:\t1  | 2   | 3\r\nWater:\t0  | 13 | 7\r\n\r\nIf [B] +[A] > Limit-of-[A]\r\n    Fill [B] and put the remaining in [A]\r\nElse\r\n    Fill [B] and clear [A]\r\n<\/pre>\n
Now in the serial, if we were to start with 31, it simply means to fill up jug C to jug A.
\nSo the aim of this is to move around the \u201cbeer\u201d so jug A == 10 and jug B == 10.<\/p>\n
We would have realized that this is the classic \u201cLiquid Pouring Puzzle<\/a>\u201d that some, if not most of us, have seen while we were in school.<\/p>\n
You can write your tool based on the findings. But if we were to do it with pen and paper. We should get something like the one below.<\/p>\n
0-13-7
\n7-13-0
\n19-1-0
\n12-1-7
\n12-8-0
\n5-8-7
\n5-13-2
\n18-0-2
\n18-2-0
\n11-2-7
\n11-9-0
\n4-9-7
\n4-13-3
\n17-0-3
\n17-3-0
\n10-3-7
\n10-10-0<\/p>\n
Rewriting this to serial code: 31211332133221321332133221321332<\/p>\n
Using that as the serial, we will solve it and get this message back.<\/p>\n
\"ctf_windows_28\"<\/span><\/div><\/a><\/p>\n
PAN{C0ngr47ulaT1onsbuddy<\/i>y0Uv3solved<\/i>there4l<\/i>_prObL3M}<\/span><\/p>\n
Windows 5 Challenge: Pick your favorite decimal code. <\/strong><\/h3>\n
Challenge Created By: Jacob Soo @_jsoo_<\/a><\/em><\/p>\n
Upon running RGB.exe, we\u2019re presented with three sliders, presumably corresponding to the RBG colors, and once you\u2019ve set their values you can check them. This indicates that we\u2019ll need to figure out the correct three values to access the key.<\/p>\n
\"ctf_windows_29\"<\/span><\/div><\/a><\/p>\n
Wrong values<\/em><\/p>\n
A quick look at the PE file with Exeinfo shows that it\u2019s a .NET program, which can be unpacked with de4dot.<\/p>\n
\"ctf_windows_30\"<\/span><\/div><\/a><\/p>\n
Checking binary type<\/em><\/p>\n
Running de4dot against the executable creates a new file, \u201cRGB-cleaned.exe\u201d that we can then decompile with dnSpy to look at the underlying source code.<\/p>\n
\"ctf_windows_31\"<\/span><\/div><\/a><\/p>\n
Deobfuscating binary<\/em><\/p>\n
When looking at the source code, we come to the challenge that we\u2019ll need to solve.<\/p>\n
\"ctf_windows_32\"<\/span><\/div><\/a><\/p>\n
Algorithm<\/em><\/p>\n
Simply put, three conditions need to be met to get the MessageBox we want to display. At this point, I started poking around to see if I can just modify the code so it always prints the answer, but when you start diving into the functions being called, you can see there is a bit more going on and requires the actual numbers.<\/p>\n
\"ctf_windows_33\"<\/span><\/div><\/a><\/p>\n
XORing numbers against array of numbers<\/em><\/p>\n
So I decided to tackle the math aspect instead.<\/p>\n
The three conditions that need to be met are that one equation result must equal another equation result and one of the specific values needs to be over 60. I opt to brute force it by iterating through every possible combination of numbers, knowing that each slider will be in a range of 1-255, with one being in the range of 60-255. This gives us roughly 12.5 million possibilities, 255*255*(255-60), which shouldn\u2019t take long at all.<\/p>\n
After a few minutes of thinking through the logic, I use the below script to find the value.<\/p>\n
-----rgb.py\r\nimport sys\r\n\u00a0\r\ndef func1(value, value2, value3, num, num2):\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 result = value + num - value2 + value * value * value2 - value3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return result\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\ndef func2(value, value2, value3, num, num2):\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 result = value2 * (value3 * 34 + (num2 - value)) + 3744\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return result\r\n\u00a0\r\ndef check(value, value2, value3, num, num2):\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 a = func1(value, value2, value3, num, num2)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 b = func2(value, value2, value3, num, num2)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 if a == b:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 print \"\\nwinner winner, chicken dinner!\\n\\n\", value, value2, value3, \" [\" + str(a), \r\nstr(b) + \"]\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sys.exit(1)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\r\nvalue = 60\r\nvalue2 = 0\r\nvalue3 = 0\r\nnum = value2 * value3\r\nnum2 = value * 3\r\n\u00a0\r\nwhile value < 256:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value2 = 0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value3 = 0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num = value2 * value3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num2 = value * 3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 check(value, value2, value3, num, num2)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 while value2 < 256:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value3 = 0\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num = value2 * value3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num2 = value * 3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 check(value, value2, value3, num, num2)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 while value3 < 256:\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num = value2 * value3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 num2 = value * 3\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 check(value, value2, value3, num, num2)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value3 += 1\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value2 += 1\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 value += 1\r\n-----\r\n<\/pre>\n
Within a few seconds, we have the answer and can validate it within RGB.exe to get the key.<\/p>\n
\"ctf_windows_34\"<\/span><\/div><\/a><\/p>\n
83 168 203<\/em><\/p>\n
PAN{l4byr1n7h_s4yz_x0r1s_4m4z1ng}<\/p>\n
Windows 6 Challenge: Discover the key in the shellC0DE to rescue the Princess!<\/strong><\/h3>\n
Created By: Josh Grunzweig @jgrunzweig<\/a><\/em><\/p>\n
Opening up this Windows executable quickly reveals that we\u2019re working with some shellcode. If this wasn\u2019t apparent, the clue provided gave some hints as to what you\u2019d be dealing with.<\/p>\n
Discover the key in the sh>E11C0DE to rescue the Princess!
\n@jgrunzweig<\/p>\n
To make things easier for challengers, I went ahead and compiled the shellcode into a working executable, versus simply giving you the raw shellcode bytes. Once opened we see that there are no imports and only seven functions.<\/p>\n
\"ctf_windows_35\"<\/span><\/div><\/a><\/p>\n
Figure 1 Functions in shellcode and import table<\/em><\/p>\n
Without even debugging this shellcode we can quickly scan the seven functions provided to see if anything jumps out. Sure enough, we quickly identify a function that is almost certainly RC4 at 0x40106C. The two loops iterating 256 times gives us a big hint. Working through this function, we can confirm it is in fact RC4.<\/p>\n
\"ctf_windows_36\"<\/span><\/div><\/a><\/p>\n
Figure 2 RC4 function<\/em><\/p>\n
We also identify a very small function which starts by loading fs:0x30, which should get a reverser\u2019s attention fairly quickly. For those unaware, fs:0x30 points to the Process Environment Block<\/a> (PEB), which holds a wealth of information. This function in question is specifically looking at the PEB\u2019s LoaderData offset, which holds information about the loaded modules in the process. We then get the third loaded module, which is kernel32.dll, and grab this DLL\u2019s base address (offset 0x10). This function is essentially grabbing the base address of kernel32.dll, which is most likely going to be used to load further functions.<\/p>\n
\"ctf_windows_37\"<\/span><\/div><\/a><\/p>\n
Figure 3 Function getting kernel32 base address<\/em><\/p>\n
We continue to identify yet another function that appears to be hashing data, as evident by the ROR13 call.<\/p>\n
\"ctf_windows_38\"<\/span><\/div><\/a><\/p>\n
Figure 4 Possibly hashing function<\/em><\/p>\n
At this point, let\u2019s start stepping through our shellcode in a debugger. We quickly see multiple calls to our function that got kernel32\u2019s base address, followed by another function that takes this base address and a DWORD as arguments. Looking through this function we see it walking through all of kernel32\u2019s exported functions, hashing the name, and comparing it against the provided DWORD. This is a simple shellcode trick that will allow attackers to obfuscate what functions are being loaded by the malware when viewed statically. There are a few ways we can approach this. We can debug the code and rename as we encounter them. Alternatively, we can simply search for the hashes on Google. Since the ROR13 technique is so common, there are many places online that have documented these hashes, like this one<\/a>.<\/p>\n
After getting over this minor hurdle we can start to see what the code is doing to understand what it\u2019s looking for. Looking at the code in detail, we can see that it\u2019s building a buffer of 54 bytes and attempting to decode it against a key that is generated using RC4. In the event the key starts with \u2018PAN{\u2018, it will display it in a messagebox dialog window.<\/p>\n
The key is generated using a number of variables that are pulled from the machine it is running on. The first four bytes of the key are a static value of \u2018b00!\u2019. Following this, the code looks for the following data:<\/p>\n