{"id":19938,"date":"2016-09-29T13:15:59","date_gmt":"2016-09-29T20:15:59","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=19938"},"modified":"2016-10-03T07:50:09","modified_gmt":"2016-10-03T14:50:09","slug":"unit42-labyrenth-capture-the-flag-ctf-mobile-track-solutions","status":"publish","type":"post","link":"https:\/\/origin-researchcenter.paloaltonetworks.com\/blog\/2016\/09\/unit42-labyrenth-capture-the-flag-ctf-mobile-track-solutions\/","title":{"rendered":"LabyREnth Capture the Flag (CTF): Mobile Track 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\u00a0to one challenge track per week. Next up, the Mobile track.<\/p>\n

Mobile 1 Challenge: This is your last chance, choose wisely!<\/h3>\n

Challenge Created By: Jeff White <\/em>@noottrak<\/em><\/a><\/p>\n

We are given an iOS app for this challenge. When we run it in the emulator, we have some squares to touch. If we select a correct square it turns green, if we select a wrong one, it turns yellow; if we touch a wrong one again, it turns red and we lose.<\/p>\n

\"labyrenth_mobile-1\"<\/span><\/div><\/a><\/p>\n

The goal is to turn all the squares green to win and get the flag. We could just play the game and get lucky, or we could try and reverse the program to obtain the key. If we open the binary in IDA we can browse through the functions and quickly find an interesting function that stands out. Specifically, one of them is moving a long array of bytes to incrementing offsets of RDX at the beginning of the function. If we push \u2018R\u2019 on each byte in IDA, we can see that the key is being moved.<\/p>\n

\"labyrenth_mobile-2\"<\/span><\/div><\/a><\/p>\n

PAN{EZE_S41d_Th15_w4s_Ea5y}<\/p>\n

Mobile 2 Challenge: Multiple choice, you say?<\/h3>\n

Challenge Created By: Juan Cortes <\/em>@kongo_86<\/em><\/a><\/p>\n

We are given an APK file \u2018EZfill.apk\u2019. To start analyzing this we can either unzip it using a zip tool or use apktool so we can look at the resources, Manifest file, and the smali code. I prefer the apktool.<\/p>\n

\"labyrenth_mobile-3\"<\/span><\/div><\/a><\/p>\n

Examining the AndroidManifest.xml file reveals this is a rather small APK with one main activity.<\/p>\n

\"labyrenth_mobile-4\"<\/span><\/div><\/a><\/p>\n

The next step will be to load our APK into our emulator.<\/p>\n

\"labyrenth_mobile-5\"<\/span><\/div><\/a><\/p>\n

Our app shows up in our app\u2019s list:<\/p>\n

\"labyrenth_mobile-6\"<\/span><\/div><\/a><\/p>\n

Opening the app gives a login screen. Let\u2019s input some fake data and see what we get:<\/p>\n

\"labyrenth_mobile-7\"<\/span><\/div><\/a><\/p>\n

Seems the app is doing some checking for the email and password. At this point we can start analyzing the app\u2019s code. We can go straight into viewing smali code or we can use Bytecodeviewer<\/a>.<\/p>\n

By examining the code, we can see decompiled code in java. We immediately notice a function that takes an array of char as a parameter and returns an array of char. Inside that function we have an array of int\u2019s, which if we were to guess, is the encoded flag. We need to find where this function is being called from and the char array that is passed as an argument. In order to trace it back, we need to look for the onCreate function. This is the first callback when an Android application is started. If you recall from loading the app into the emulator, we saw a button so this leads us to believe a function handles the action of clicking it. Inside the onCreate function we see setOnClickListener. If we follow what is passed to setOnClickListener, it points to a class \u2018b\u2019 which has the function OnClick.<\/p>\n

\"labyrenth_mobile-8\"<\/span><\/div><\/a><\/p>\n

The onClick calls back to a function in CupsLogin. Since the code is slightly obfuscated and a bit hard to trace, we\u2019ll focus on key points in order to trace this. We noticed these two little functions:<\/p>\n

\"labyrenth_mobile-9\"<\/span><\/div><\/a><\/p>\n

\"labyrenth_mobile-10\"<\/span><\/div><\/a><\/p>\n

Assuming the check for the char \u2018@\u2019 and length check of 4, we can conclude that it is checking the email and\/or password. Tracing this back, we can see that is being used in private void m().<\/p>\n

\"labyrenth_mobile-11\"<\/span><\/div><\/a><\/p>\n

Inspecting that code inside that function reveals that the \u2018string\u2019 & \u2018string2\u2019 is being passed to an object.<\/p>\n

\"labyrenth_mobile-12\"<\/span><\/div><\/a><\/p>\n

The object being created extends AsyncTask. According to Android\u2019s documentation on AsyncTask<\/a>, when executed, it goes thru four steps.<\/p>\n

Inside this class were some more checks in regards to chars. Analyzing the code, we see that doInBackground calls function \u2018a\u2019. Inside this function we see a call too:<\/p>\n

\"labyrenth_mobile-13\"<\/span><\/div><\/a><\/p>\n

Analyzing that function, we can see that it is doing checks and building an array of char and then passing it to a function. Let\u2019s see what values it expects.<\/p>\n

After spending time figuring out what char values are expected, we can statically determine a few values for the password:<\/p>\n

key = [\u2018@\u2019, ?, ?, \u2018u\u2019, \u2018I\u2019, \u2018d\u2019, ?]<\/pre>\n
For the remaining chars, we can write a python script to brute force it. Don\u2019t forget to transpose the decoding function we found earlier into python. Below is a sample script to decode this.<\/p>\n
def decode(key):\r\n\r\n   secret = [] #new char[66];\r\n   flag = [453, 431, 409, 342, 318, 293, 460, 273, 383, 369, 374, 466, 261, \r\n   380, 513, 267, 301, 266, 310, 437, 260, 325, 379, 333, 454, 350, 345, \r\n   460, 293, 303, 289, 290, 438, 373, 264, 309, 351]\r\n\r\n   key = bytearray(key)\r\n   kidx = 0\r\n   for f in flag:\r\n       t = f - 2\r\n       t = ((key[kidx] - 19 + 86) ^ t) >> 2\r\n       secret.append(t)\r\n       kidx = kidx + 1\r\n       if kidx == len(key):\r\n           kidx = 0\r\n\r\n   return secret\r\n\r\ndef char2enum():\r\n   x =[]\r\n   for a in range(32,127):\r\n       t = a & 0xf ^ a\r\n       if t == 96:\r\n           x.append(a)\r\n\r\n   return x\r\n\r\ndef char1_6enum():\r\n   chars = []\r\n   for a in range(32,127):\r\n       for b in range(32,127):\r\n           if a ^ b == 21:\r\n               if [chr(a),chr(b)] in chars:\r\n                   continue\r\n               chars.append([chr(a),chr(b)])\r\n\r\n   return chars\r\n\r\n\r\nchar2 = char2enum()\r\nchar16 = char1_6enum()\r\n\r\nkey  = ['@', ' ', ' ', 'u', 'i', 'd', ' ']\r\n\r\nfor c1 in char2:\r\n   for c in char16:\r\n       key[2] = c1\r\n       key[1] = c[0]\r\n       key[6] = c[1]\r\n       test = decode(key)\r\n       k = \"\".join(chr(k) for k in bytearray(key))\r\n       flg = \"\".join(chr(t) for t in test)\r\n       print \"%s:\\t%s\" % (k,flg)\r\n<\/pre>\n
This will generate about 1,500 different variations. We can then grep for lines that have \u2018PAN{\u2018 and that slims it down to 16. Interestingly enough, we get the flag with eight different keys.<\/p>\n
\"labyrenth_mobile-14\"<\/span><\/div><\/a><\/p>\n
If we enter any of the right combos in the app we get:<\/p>\n
\"labyrenth_mobile-15\"<\/span><\/div><\/a><\/p>\n
PAN{da_cups_is_halfEmpty_||_halfFull}<\/p>\n
Mobile 3 Challenge: This executable can be run on any of the 15 BEST phones in circulation!<\/h3>\n
Challenge Created By: Josh Grunzweig <\/em>@jgrunzweig<\/em><\/a>\u00a0<\/em><\/p>\n
For this particular challenge, users are given an application created for the Windows mobile platform. There are a couple of ways to go about solving this challenge; however, approaching it statically is probably the easiest versus setting up the Microsoft Windows mobile emulator or debugging the code on an actual phone. Should the user run the application in an emulated environment, they are presented with the following:<\/p>\n
\"labyrenth_mobile-16_figure-1\"<\/span><\/div><\/a><\/p>\n
Figure 1 Application running in emulated environment<\/em><\/p>\n
Looking at the provided binary, if we unzip the file two times, we\u2019re presented with the following files:<\/p>\n
\"labyrenth_mobile-17_figure-2\"<\/span><\/div><\/a><\/p>\n
Figure 2 Unzipped files from Windows mobile application<\/em><\/p>\n
The executable in question is a .NET binary, which we can decompile using a program such as dnSpy<\/a>. Looking at the underlying code, we can see that obfuscation has been implemented to make it more difficult to read and understand.<\/p>\n
\"labyrenth_mobile-18_figure-3\"<\/span><\/div><\/a><\/p>\n
Figure 3 Decompiled code in Windows mobile application<\/em><\/p>\n
Stepping through the code and renaming functions along the way allows us to get an understanding of what is going on. The code performs the following:<\/p>\n
    \n
  1. The code checks to see if the SystemProductName is \u2018Virtual\u2019, indicating it is running within an emulator.<\/li>\n
  2. A Boolean check is performed against a function that always returns True, which must be manually changed.<\/li>\n
  3. The screen resolution is checked to look for a width greater than 1000 and a height of 5.<\/li>\n<\/ol>\n
    Should all of these conditions be met, the code execution will proceed. Otherwise, the user is presented with a response of \u2018Hounds Released!\u2019.<\/p>\n
    \"labyrenth_mobile-19_figure-4\"<\/span><\/div><\/a><\/p>\n
    Figure 4 One of the many error messages encountered<\/em><\/p>\n
    If the user makes it this far, the code will start looking at the provided user input to determine if the correct key is provided. The length of the key is first inspected. If the key does not have a length of 12, a random error message will be returned. However, should it have a length of 12, code execution proceeds. The code then makes the following checks:<\/p>\n
      \n
    1. Checks to see if the SystemProductName starts with a \u2018V\u2019, which it should since our previous check was looking for \u2018Virtual\u2019. The 6th byte of this string (\u2018a\u2019) is stored to later be used in the key.<\/li>\n
    2. The first byte of the provided key is checked for an ordinal of 66, or the character \u2018B\u2019.<\/li>\n
    3. The embedded MrBurns.jpg file is loaded, and the 7th byte is read and later used in the key (\u2018J\u2019).<\/li>\n
    4. The SystemManufacturer is checked for a length of 5 and the last three characters of \u2018kia\u2019. Based on all possible manufacturers, we can conclude that this code is looking for a string of \u2018Nokia\u2019. The first two characters are stored to a variable and later used in the key (\u2018No\u2019).<\/li>\n
    5. The 2nd <\/sup>through 4th<\/sup> characters of the provided key are XORed against a key and checked for a result of \u2018DIE\u2019. Reversing this process allows us to conclude the application is looking for an inputted string of \u2018AdP\u2019 at bytes 2 through 4 of the provided key.<\/li>\n
    6. The 5th<\/sup> through 8th<\/sup> characters of the provided key are checked against a long embedded string, looking for a value of \u2018uzzl\u2019.<\/li>\n
    7. The same checks are performed against the 9th<\/sup> and 10th<\/sup> characters, looking for \u20183\u2019 and \u2018r\u2019 respectively.<\/li>\n
    8. Finally, further checks are made against the last two bytes of the provided key, looking for \u2018!\u2019 and \u2018?\u2019.<\/li>\n
    9. An embedded Garbage.jpg is read and attempted to be decrypted against the provided key if all of these conditions are met.<\/li>\n<\/ol>\n
      In addition to everything encountered, various red herring code snippets are included to waste the reverser\u2019s time. Also, string obfuscation was used via the l1() and llll() functions, which unhex and XOR strings respectively. To make things slightly more difficult, function overloading is also used to make reversing a bit trickier.<\/p>\n
      Taking everything learned, we can conclude that the application is looking for a key of length 12. The string of \u2018aNoJ\u2019 is then concatenated at the end. Based on the checks encountered, we can conclude that the provided key must be that of \u2018BAdPuzzl3r!?\u2019. Using this key gives us the following result:<\/p>\n
      \"labyrenth_mobile-20_figure-5\"<\/span><\/div><\/a><\/p>\n
      Figure 5 Key after using correct input string<\/em><\/p>\n
      PAN{Th4t's_My_S3cr3t_N0boDy_Def34ts_th3_HOUNDS}<\/p>\n
      Mobile 4 Challenge: (walk or swipe) and (baby and you and cry)<\/h3>\n
      Challenge Created By: Juan Cortes <\/em>@kongo_86<\/em><\/a><\/p>\n
      For this mobile challenge we are given an APK named \u2018Swip3r\u2019. As with the previous APK, we start our analysis by using apktool and load it up into our emulator to get an understanding of the application. We will use Android\u2019s adb tool to install the application. Below are screenshots highlighting these steps.<\/p>\n
      \"labyrenth_mobile-21\"<\/span><\/div><\/a><\/p>\n
      (APK Tool)<\/p>\n
      \"labyrenth_mobile-22\"<\/span><\/div><\/a><\/p>\n
      (adb install)<\/p>\n
      \"labyrenth_mobile-23\"<\/span><\/div><\/a><\/p>\n
      (App icon in the emulator)<\/p>\n
      We continue by doing a basic dynamic analysis of the application. This gives us a better understanding of what the challenge may require in order to be solved. The app launches with a button that says \u201cGive me the child\u201d. Clicking it changes the screen to the character \u2018Jared\u2019 with \u201cYour eyes can se so cruel\u2026\u201d on the bottom of the screen. Clicking on the screen doesn\u2019t appear to do anything. As the name of the APK suggest, if we swipe we see that the screen changes to a baby crying with the text \u201c0oo0oopps!: 1\u201d. If we continue swiping the screen in a different direction, we see the text \u201c\u201c0oo0oopps: 2\u201d. Once again swiping increases that number after the text. So it appears that the app tracks the number of times we swipe and as it suggests we are doing something wrong.<\/p>\n
      \"labyrenth_mobile-24\"<\/span><\/div><\/a><\/p>\n
      (Starting the app)<\/p>\n
      \"labyrenth_mobile-25\"<\/span><\/div><\/a><\/p>\n
      (Jared appears)<\/p>\n
      \"labyrenth_mobile-26\"<\/span><\/div><\/a><\/p>\n
      (Crying baby)<\/p>\n
      At this point, we have some understanding of the app due to our dynamic analysis. Let\u2019s perform a static analysis of the APK structure and see if we find anything interesting.<\/p>\n
      The AndroidManifest.xml, while an important file for APK analysis, reveals nothing interesting in this particular app\u2019s manifest. However, if we go into the lib folder, we see the following two folders and each of them holds a native library: \u201clibswiipiin.so\u201d. My guess is this is not your typical android library and is a custom library.<\/p>\n
      \"labyrenth_mobile-27\"<\/span><\/div><\/a><\/p>\n
      (Libraries)<\/p>\n
      At this point, we can either load the library on IDA or attempt to decompile the APK\u2019s code using Bytecode Viewer. Why not both?<\/p>\n
      Let\u2019s start with looking at the decompiled Java code. The application only has two classes: MainActivity.class & Swip3r.class. The Swip3r class is rather small and we see that it sets the title and starts the activity \u2018MainActivity\u201d.<\/p>\n
      \"labyrenth_mobile-28\"<\/span><\/div><\/a><\/p>\n
      (Swip3r.class)<\/p>\n
      Now we\u2019ll examine the code in the MainActivity.class. We can quickly see the interesting strings we observed from our basic dynamic analysis. We see the app attempts to load the library: \u2018swiipiin\u2019. Lastly, at the end of the class file, we see two native methods being called: \u2018wel()\u2019 and \u2018well()\u2019. One which takes no parameters and the other takes eight parameters.<\/p>\n
      \"labyrenth_mobile-29\"<\/span><\/div><\/a><\/p>\n
      (oops strings)<\/p>\n
      \"labyrenth_mobile-30\"<\/span><\/div><\/a><\/p>\n
      (library loading)<\/p>\n
      \"labyrenth_mobile-31\"<\/span><\/div><\/a><\/p>\n
      (Native Methods)<\/p>\n
      At this point we know that app uses the native library with the two native methods. We focus on finding where these two methods are being used and then moving to analyze the native library methods. The easy crude way is to just copy the decompiled code into Notepad++ and search for these native methods. We find that \u2018wel()\u2019 is used once in the OnCreate() method and \u2018well()\u2019 is used three times inside the onFling() method. Lastly, we can see that both methods after being called, returns a value that is being used to display text.<\/p>\n
      \"labyrenth_mobile-32\"<\/span><\/div><\/a><\/p>\n
      (wel())<\/p>\n
      \"labyrenth_mobile-33\"<\/span><\/div><\/a><\/p>\n
      (well())<\/p>\n
      Let\u2019s switch over to IDA for a bit and examine the native library. Under exports we see the native methods we previously found in our decompiled Java code. Examining ARM assembly hurts my eyes more than looking at x86 assembly, but we will attempt to analyze these methods a bit. By looking at the code, we can tell that its loading a string \u201cYour eyes can se so cruel\u201d and then returns. If you remember, we saw this text when we loaded the app in our emulator. It coincides with the fact that this method, after being called, returns a value that is used as a string in displaying text. Looking at the other method \u2018well()\u2019 we can see it calls a function (Note: I have renamed this function) \u2018well_func1_F8C\u2019. Looking at that function and using IDA\u2019s \u2018Xrefs from\u2019 we see it calls ten other functions. If you look at those ten functions, most of them have a loop with some sort of bitwise operation, which tells me there is some decoding going on. As I mentioned previously, looking at ARM assembly is not as pleasant as x86. We take another approach and examine the decompiled Java code.<\/p>\n
      \"labyrenth_mobile-34\"<\/span><\/div><\/a><\/p>\n
      (IDA Exports)<\/p>\n
      \"labyrenth_mobile-35\"<\/span><\/div><\/a><\/p>\n
      (Xrefs)<\/p>\n
      \"labyrenth_mobile-36\"<\/span><\/div><\/a><\/p>\n
      (Example Func Loop)<\/p>\n
      \"labyrenth_mobile-37\"<\/span><\/div><\/a><\/p>\n
      (Example2 Func Loop)<\/p>\n
      The nice thing about ByteCode Viewer is that you get options from different Java decompilers. For example, if we focus on the \u2018OnFling()\u2019 method using JD-GUI decompiler, we get nasty nested while loops. If we choose Procyon decompiler, we get a nice set of nested IF...ELSE statements which is far better for reading the code. If you copy over the decompiled code to Notepad++, it makes it easier to collapse code and see a \u2018big picture\u2019 of what\u2019s going on.<\/p>\n
      \"labyrenth_mobile-38\"<\/span><\/div><\/a><\/p>\n
      (Big picture)<\/p>\n
      A quick Google search<\/a> will help you understand what is the point of the OnFling() <\/a>method as well as its parameters. This will help us understand what we need to do in order to simplify the completion of this challenge. At this point, we can break down the code looking at each IF and ELSE IF and determine what values are needed. Starting with the first set of conditional statements we see that the code is checking the values from motionEvent.getY(), motionEvent.getX(), motionEvent2.getY(), motionEvent2.getX(). These values are used to detect a motion on a screen on using the X and Y axis, which in turn detect when the user moves UP, DOWN, LEFT, RIGHT. Inside each conditional statement we see that the app sets several int\u2019s with values that are checked throughout this OnFling() method. Knowing that we want the application to call the native method \u2018well()\u2019 we can begin analyzing what values should be set with the right swipe motions as well as stay away from the motions that set the values which calls the \u201c0oo0oopps!\u201d message. After studying the code, we can conclude that the right combination is: UP, LEFT, DOWN, RIGHT, UP. Enjoying a handful of Jared pictures the last image holds the key: PAN{jAr3d_sayz_'swwip3r_!NO!_swipp11nn'}<\/p>\n
      \"labyrenth_mobile-39\"<\/span><\/div><\/a><\/p>\n
      (Begin)<\/p>\n
      \"labyrenth_mobile-40\"<\/span><\/div><\/a><\/p>\n
      (UP)<\/p>\n
      \"labyrenth_mobile-41\"<\/span><\/div><\/a><\/p>\n
      (LEFT)<\/p>\n
      \"labyrenth_mobile-42\"<\/span><\/div><\/a><\/p>\n
      (DOWN)<\/p>\n
      \"labyrenth_mobile-43\"<\/span><\/div><\/a><\/p>\n
      (RIGHT)<\/p>\n
      \"labyrenth_mobile-44\"<\/span><\/div><\/a><\/p>\n
      (UP)<\/p>\n
      Quick little easter-egg, if you notice the app has detection for a method \u2018onLongPress()\u2019. Hence if you hold down on the screen\u2019s emulator a nice little string comes on top of the screen. This appears to be base64, however is three different base64 strings, each of which decode to: https:\/\/goo.gl\/VgmUUy. This is a Google shortened URL which leads to a YouTube video of the Labyrinth song \u201cWithin you \u2013 David Bowie 1986.\u201d Unfortunately the Internet gods have since removed this video. Interestingly there were 26 clicks made to this URL all from different countries. Note: the real number is 27, since one click was done during testing. Get more information about the URL.<\/a><\/p>\n
      \"labyrenth_mobile-45\"<\/span><\/div><\/a><\/p>\n
      (easter-egg)<\/p>\n
      \"labyrenth_mobile-46\"<\/span><\/div><\/a><\/p>\n
      (url decoded)<\/p>\n
      PAN{jAr3d_sayz_'swwip3r_!NO!_swipp11nn'}<\/p>\n
      Mobile 5 Challenge: Can you escape the labyrinth with your life?<\/h3>\n
      Challenge Created By: Jeff White <\/em>@noottrak<\/em><\/a><\/p>\n
      Similar to the first iOS challenge, we\u2019re provided with the ARM compiled binary and a simulator version.<\/p>\n
      Looking through the simulator folders we can see a lot of images with ominous names such as \u201cdeath_01.jpg\u201d, \u201ctunnel_01.jpg\u201d, and \u201cwin_01.jpg\u201d. If we load the binary into IDA and look at the strings, we see some interesting messages with \u201cLOSE\u201d, \u201cWIN\u201d, and the start of a URL.<\/p>\n
      \"labyrenth_mobile-47\"<\/span><\/div><\/a><\/p>\n
      We can also see multiple base64-encoded strings.<\/p>\n
      \"labyrenth_mobile-47-2\"<\/span><\/div><\/a><\/p>\n
      Pulling the base64-encoded strings out and decoding them shows they are reversed words and sentences.<\/p>\n
      The outside air washes over you.\r\nSunlight beams down and warms you.\r\nYou let out a sigh of relief.\r\nYou look back and the maze vanishes.\r\nStepping out of the maze, you live another day.\r\nA tear of joy streams down your face.\r\nThere was never any doubt of winning.\r\nYou chose...poorly.\r\nYour stomach feels like a pit, the last feeling you'll ever have.\r\nChills run down your spine as all of the air seeps out of the room.\r\nMommy?\r\nYou knew this was the wrong way...\r\nGulp..this is the end.\r\nDeath awaits you.\r\nYou pray for a quick death.\r\nYou peek around the right corner, the coast looks clear.\r\nYou quickly dive into the right tunnel.\r\nNoises of children echo from the right.\r\nA green mist rises from the tunnel.\r\nThis tunnel looks familiar, have you gone this way?\r\nYou feel a cold breath on your neck.\r\nThis tunnel looks promising...for the dead.\r\nYou scurry backwards, only to find a new room.\r\nThe sights of this room frieghten you.\r\nDoors begin to shut, but you quickly jump back.\r\nThe room fills with fog you think you went back.\r\nYou think best before moving forward, best to stay put.\r\nClaustrophobia is setting in.\r\nYou have a yearn for your mommy, but her ghost is all that's here.\r\nA light seems to beacon in the left tunnel.\r\nYou sprint to the door along the left.\r\nDid a shadow just cross the far door?\r\nEenie-meenie-minie-moe... giant trolls with no toes.\r\nIt feels warm in this direction.\r\nRunes begin to glow as you walk by.\r\nSmells of rotten flesh and fungus greet you.\r\nYou move forward to the next tunnel.\r\nA scream bellows from ahead, you run towards it.\r\nWhispers call you near.\r\nScratched arrows on the wall point forward.\r\nIs this the right way?\r\nYou step over corpses on your way.\r\nYou step silently ahead, listening to screams in the distance.\r\ndungeon\r\nlabyrinth\r\nevil\r\ncrystal\r\nhades\r\nbowie\r\nspace\r\ntreasure\r\nloot\r\nlost\r\nmaze\r\nsecret\r\n<\/pre>\n
      Based on the strings, it looks like the app is some kind of game so let\u2019s go ahead and boot it up in a simulator and see what it does before we dive in. For a quick and simple simulation, you can use the website appetize.io for iOS or APK simulation.<\/p>\n
      \"labyrenth_mobile-48\"<\/span><\/div><\/a><\/p>\n
       <\/p>\n
      Using the arrow keys, we can navigate around the \u201cLabyrinth\u201d and see some of the base64-decoded strings on each screen.<\/p>\n
      \"labyrenth_mobile-49\"<\/span><\/div><\/a><\/p>\n
      Eventually we fail and get our \u201c***LOSE***\u201d message.<\/p>\n
      \"labyrenth_mobile-50\"<\/span><\/div><\/a><\/p>\n
      Resetting a few times, we eventually make our way out of the maze, which appears random since repeating the same steps would cause us to lose at different points.<\/p>\n
      \"labyrenth_mobile-51\"<\/span><\/div><\/a><\/p>\n
      When you win, it says you have the \u201cHigh Score!\u201d and that you can submit your score to http:\/\/pansecretloot.com<\/a>. After clicking submit though, we\u2019re presented with the below message.<\/p>\n
      \"labyrenth_mobile-52\"<\/span><\/div><\/a><\/p>\n
      The error message states that it was unable to resolve and \u201cno flag for you\u201d. Checking the domain pansecretloot.com, it indeed does not resolve so presumably this is what the message referred to. When I play the game again, we see it\u2019s using a different domain this time, http:\/\/panlostspace.com<\/a>, which it states also cannot be resolved.<\/p>\n
      \"labyrenth_mobile-53\"<\/span><\/div><\/a><\/p>\n
      Playing through a couple of times, this pattern just continues to repeat.<\/p>\n
      http:\/\/pansecretloot.com\r\nhttp:\/\/panlostspace.com\r\nhttp:\/\/panlootdungeon.com\r\nhttp:\/\/panlostlost.com\r\nhttp:\/\/pansecretdungeon.com\r\nhttp:\/\/pandungeonbowie.com\r\n<\/pre>\n
      If you recall from our base64 encoded strings, after all of the messages being displayed in the game is a short list of single words.<\/p>\n
      dungeon\r\nlabyrinth\r\nevil\r\ncrystal\r\nhades\r\nbowie\r\nspace\r\ntreasure\r\nloot\r\nlost\r\nmaze\r\nsecret\r\n<\/pre>\n
      You can easily see the correlation. It appears that two of the words are being appended to \u201chttp:\/\/pan\u201d to build a domain. Smells DGAish to me! If this is the final list of 12 words, and we know they can be next to each other (lostlost), then it\u2019s just 12^2 for the combinations, which is easily generated and checked.<\/p>\n
      words = [\"dungeon\", \"labyrinth\", \"evil\", \"crystal\", \"hades\", \"bowie\", \"space\", \"treasure\", \"loot\", \"lost\", \"maze\", \"secret\"]\r\n\r\nfor i in words:\r\n\tcount = 0\r\n\twhile count < len(words):\r\n\t\tprint \"pan\" + i + words[count] + \".com\"\r\n\t\tcount += 1\r\n<\/pre>\n
      Iterating through the generated list and performing DNS lookups, we come across this gem.<\/p>\n
      Host panbowietreasure.com not found: 3(NXDOMAIN)\r\nHost panbowieloot.com not found: 3(NXDOMAIN)\r\nHost panbowielost.com not found: 3(NXDOMAIN)\r\nHost panbowiemaze.com not found: 3(NXDOMAIN)\r\nHost panbowiesecret.com not found: 3(NXDOMAIN)\r\npanspacedungeon.com has address 52.43.46.197\r\nHost panspacelabyrinth.com not found: 3(NXDOMAIN)\r\nHost panspaceevil.com not found: 3(NXDOMAIN)\r\nHost panspacecrystal.com not found: 3(NXDOMAIN)\r\nHost panspacehades.com not found: 3(NXDOMAIN)\r\nHost panspacebowie.com not found: 3(NXDOMAIN)\r\nHost panspacespace.com not found: 3(NXDOMAIN)\r\n<\/pre>\n
      Browsing to this domain, it just returns the string \u201cM4z3Cub3\".<\/p>\n
      \"labyrenth_mobile-54\"<\/span><\/div><\/a><\/p>\n
      So it seems the app is building domains from this wordlist but fails to progress because of resolution errors. What if we simply change our host lookup so that all of these domains resolve to the known live site?<\/p>\n
      Appetize.io is great for quickly looking at an app, but it doesn\u2019t offer us anything in the way of debugging. Since I\u2019m not cool enough to have a physical iOS device that I can load this on, I\u2019ll need to figure out how to load this into a local simulator so that I can affect the domain resolution.<\/p>\n
      The next part was slightly confusing so I\u2019ll explain it here to hopefully make someone\u2019s life easier. Basically, if you create an Xcode project and run it on a simulator, it generates an .app file for that simulated device. If you right click on the .app file under Products in Xcode, you can open the folder that contains your file, then simply move over the .app included with this challenge. The directory path looks like this:<\/p>\n
      \"labyrenth_mobile-55\"<\/span><\/div><\/a><\/p>\n
      The directory \u201clabyREnth_mobile5-XXX\u201d is the project name and then the generated device ID that was created in Xcode for our simulated device. Loading our simulator, we see the app we copied over, along with our empty project app.<\/p>\n
      \"labyrenth_mobile-56\"<\/span><\/div><\/a><\/p>\n
      Now that we have the app running locally, we\u2019ll modify our \/etc\/hosts file with all of the domains we enumerated and point them all to the IP we resolved for panspacedungeon.com.<\/p>\n
      \"labyrenth_mobile-58\"<\/span><\/div><\/a><\/p>\n
      Next, we\u2019ll run our app and navigate the game until we trigger the win condition.<\/p>\n
      \"labyrenth_mobile-59\"<\/span><\/div><\/a><\/p>\n
      Success!<\/p>\n
      \"labyrenth_mobile-60\"<\/span><\/div><\/a><\/p>\n
      PAN{G3t_Sch1f7y}<\/p>\n
      Mobile 6 Challenge: This handheld is best handheld<\/h3>\n
      Challenge Created By: Richard Wartell <\/em>@wartortell<\/em><\/a>\u00a0<\/em><\/p>\n
      For this challenge we\u2019re handed a file with an extension of .86p. Not exactly a common extension and the file is only 2kb, so let\u2019s open it in a hex editor:<\/p>\n
      \"labyrenth_mobile-61\"<\/span><\/div><\/a><\/p>\n
      Immediately we can see some strings that look interesting, but the first and most important is \u201c**TI86**\u201d. So maybe we\u2019re dealing with a TI86 assembly program? Let\u2019s try to find an emulator where we can run this.<\/p>\n
      Wabbitemu<\/a> comes to the rescue here. Wabbitemu will allow us to run TI calculator assembly programs. Since this program is for a TI86 calculator, we install the TI86 ROM for the calculator. We can then load the program by opening OGMob.86p and running the following series of keys:<\/p>\n
      2nd -> CUSTOM -> Asm( -> ENTER -> PRGM -> NAMES -> OGMob -> )<\/pre>\n
      This creates the line, Asm(OGMob), which is how you execute assembly programs on a TI86 calculator. When we execute the program, we get the following info:<\/p>\n
      \"labyrenth_mobile-62\"<\/span><\/div><\/a><\/p>\n
      Playing around with this by hitting some keys, it looks like the display changes based on key presses, but no matter what we keep getting back to a screen that says \u201cFAILURE\u201d. At this point, we need to start looking at this in a disassembler. Looking around for resources on reversing a TI86 binary, we find a decent blog post<\/a>.<\/p>\n
      However, loading at the suggested addresses here doesn\u2019t work, but playing around in the Wabbitemu debugger shows us that the binary needs to be loaded at 0xD6FD. We can figure this out simply from trial and error, getting the bytes to match up with what is showing up in our debugger.<\/p>\n
      Once this is loaded correctly, we can finally take a look at things in graph mode. The main graph of the program looks like this:<\/p>\n
      \"labyrenth_mobile-63\"<\/span><\/div><\/a><\/p>\n
      However, we have a lot of function calls that don\u2019t seem to go anywhere in IDA, though they point to places in the debugger. So if we Google the addresses with TI86, we find this link about the constants<\/a>. So it turns out that all of these are internal functions in calculator. By creating a new segment and storing our constants there, we can nicely label our IDB so that we can see what it\u2019s doing:<\/p>\n
      \"labyrenth_mobile-64\"<\/span><\/div><\/a><\/p>\n
      Now we can finally put the pieces together and we see a lot of sequences that look like _getkey, compare, conditional branch. Finally, we\u2019re seeing the logic of what we saw before with entering keys and then seeing \u201cFAILURE\u201d. Presumably, if we enter the right key combination, we\u2019ll get the key for the challenge.<\/p>\n
      If we walk through the logic for the _getKey calls, and use the site we referenced earlier for our key constants, we get the following sequence:<\/p>\n
      ENTER CLEAR ( 8 6 7 - 5 3 0 9 )<\/p>\n
      When we enter these in the right order, this is what our screen shows:<\/p>\n
      \"labyrenth_mobile-65\"<\/span><\/div><\/a><\/p>\n
      Which is the key:<\/p>\n
      PAN{dis_C@1c's_Ju51_4_YOUZ?!?}<\/p>\n
      Bonus round:<\/h3>\n
      As we were walking through those key presses, there is a large body of code that executes, and the screen changes every other key press. If we look at the data that code is referencing, we find it all pointing to constants and then using those constants to draw onto the screen. Each constant seems to be made up of 8 bytes based on the gaps:<\/p>\n
      \"labyrenth_mobile-66\"<\/span><\/div><\/a><\/p>\n
      Nothing really comes up if we look at these as just letters or numbers, for example, here are the first two of the 8 byte constants:<\/p>\n
      \"labyrenth_mobile-67\"<\/span><\/div><\/a><\/p>\n
      But, if we look at these in binary, something much more interesting pops up:<\/p>\n
      01110111\u00a0 00100100<\/strong><\/p>\n
      01010101\u00a0 00100101<\/strong><\/p>\n
      01010101\u00a0 00110100<\/strong><\/p>\n
      01010101\u00a0 00110101<\/strong><\/p>\n
      01101111\u00a0 10101101<\/strong><\/p>\n
      01001000\u00a0 10101100<\/strong><\/p>\n
      01001000\u00a0 10100101<\/strong><\/p>\n
      01001000\u00a0 10100100<\/strong><\/p>\n
      Though not immediately obvious, if you step back from this, or convert it to white\/black space, this does in fact have the key for the challenge in it. The first two constants above contain the binary representation of an 8bit by 8bit sprite of the letters PAN. If we do this with all the constants, we\u2019ll get the full key from there.<\/p>\n
      \"ctf_mobile\"<\/span><\/div><\/a><\/p>\n
      Leave a comment below to share your thoughts about these challenges. Be sure to also check out how other threat researchers solved these challenges:<\/p>\n
      Mobile 1<\/h3>\n