We are given an iPhone application and a debug log with 185k lines.

My team originally solved this challenge by running the application on a jailbroken iPhone and observing the debug log from that session, but the prompt said that no device was needed, so I set out to find an alternative but reasonable solution method based on information I already had.

I spent a lot of time searching for certain strings, but I instead could have searched simply for an uncommon logging format. There was an hint released later that I didn't see but definitely would have helped. However, this method works without that hint.

I first wanted to take a look inside the application, so I extracted it and looked at the extracted files.

dpkg-deb -x com.yourcompany.whyos_4.2.0-28debug_iphoneos-arm.deb app

root@kali:~/csaw/app# ls */*/*
Library/MobileSubstrate/DynamicLibraries:
whyOS.dylib  whyOS.plist

Library/PreferenceBundles/whyOSsettings.bundle:
Info.plist  Root.plist  whyOSsettings

Library/PreferenceLoader/Preferences:
whyOSsettings.plist

There appeared to be two binary files and four property list files. Two strings from those files that appeared interesting were com.yourcompany.whyossettings and CSAWRootListController along with those in Root.plist more generally.

However, when I searched for whyOS in the debug log, I was very surprised to only find two lines that contained that term, considering how important and broad it seemed.

I searched for CSAWRootListController along with other interesting terms in Root.plist, but I had no results. There were too many instances of flag for me to browse.

I looked for several hundred lines above and below the whyOS matches because I thought that's where the activity happened, but I did not find anything useful.

I ran strings on the binaries, but didn't find anything that would lead to the flag, so I decided to take a look closer look in IDA, even though this wasn't a reversing challenge, which made me unsure if I was on the right track.

I looked at whyOS.dylib, but it basically didn't contain anything, so I moved on to the other file.

There are two functions, specifiers and setflag. I decompiled them with IDA to get a better look at what they do.

id __cdecl -[CSAWRootListController specifiers](struct CSAWRootListController *self, SEL a2)
{
  void *v2; // r0@2
  struct CSAWRootListController *v4; // [sp+10h] [bp-Ch]@1

  v4 = self;
  if ( !*(_DWORD *)&self->PSListController_opaque[OBJC_IVAR___PSListController__specifiers] )
  {
    v2 = objc_msgSend(self, "loadSpecifiersFromPlistName:target:", CFSTR("Root"), self);
    *(_DWORD *)&v4->PSListController_opaque[OBJC_IVAR___PSListController__specifiers] = objc_msgSend(v2, "retain");
  }
  return *(id *)&v4->PSListController_opaque[OBJC_IVAR___PSListController__specifiers];
}

This method just looks like it loads specifiers from Root.plist, which may be useful for the program but isn't that interesting for us since that's all it does.

The setflag method obviously sounds more interesting for us.

void __cdecl -[CSAWRootListController setflag](struct CSAWRootListController *self, SEL a2)
{
  void *v2; // r0@1
  __CFString *v3; // [sp+4h] [bp-34h]@2
  void *v4; // [sp+20h] [bp-18h]@1

  v2 = objc_msgSend(&OBJC_CLASS___NSMutableDictionary, "alloc");
  v4 = objc_msgSend(v2, "initWithContentsOfFile:", CFSTR("/var/mobile/Library/Preferences/com.yourcompany.whyos.plist"));
  if ( objc_msgSend(v4, "objectForKey:", CFSTR("flag")) )
    v3 = (__CFString *)objc_msgSend(v4, "objectForKey:", CFSTR("flag"));
  else
    v3 = &stru_8044;
  NSLog(CFSTR("%@"), v3);
}

It looks like the function creates a dictionary from the whyos.plist file and looks for the value for the key flag. If it exists, it sets a string variable to that value. Otherwise, that string is set to what is actually an empty string.

Finally, and most importantly, it logs the string to the console.

I looked online for the default NSLog output format and discovered the format.

Date Time OurApp[<process­id>] output

Since the NSLog call is just printing out the string, which is the flag, with no extra parameters, we can expect our output to be in a known format.

X Y Z flag

Looking through the debug log, the lines are incredibly verbose, so having just one word might stand out. Additionally, we know the flag is not in the standard flag{} format from the description.

I would say flags are generally at least 10 characters long, and since there are no curly brackets, may just contain alphanumeric characters, although there could still be underscores.

We can take a look at some example lines from console log.

default 18:59:15.308337 -0400   nsurlsessiond   [5757 <private> stream, bundle id: mobileassetd, pid: 386, url...
default 18:59:15.308698 -0400   nsurlsessiond   0.000s [5757 E6368DF7-4A60-45CF-A579-4C1AF76AE40E <private> ...
error   18:59:15.308772 -0400   nsurlsessiond   Task <A4B92146-9429-451D-B0FC-88C778AE5177>.<29> finish...
default 18:59:15.308823 -0400   nsurlsessiond   0.000s [5757 E6368DF7-4A60-45CF-A579-4C1AF76AE40E <private> p...
default 18:59:15.309335 -0400   nsurlsessiond   0.000s [5757 E6368DF7-4A60-45CF-A579-4C1AF76AE40E <private> p...
default 18:59:15.309412 -0400   nsurlsessiond   0.000s [5757 E6368DF7-4A60-45CF-A579-4C1AF76AE40E <private> ...
default 18:59:15.309464 -0400   nsurlsessiond   10.801s [5757] path:cancel

We want to get the part that the application actually logs, not the metadata at the start. We can use cut to get that part, but first we need to remove the extra spaces using tr before the application logging so we can easily make a single space as a delimiter for cut.

tr -s '[:space:]' < console.log | cut -d" " -f5-

Now that we have the application part, we are only interested in what might be our flag. Based on our previous criteria, we search for 10 or more alphanumeric characters at the start of a line followed by the end of a line.

tr -s '[:space:]' < console.log | cut -d" " -f5- | grep -E '^[[:alnum:]]{10,}$'

We see that there are only 296 lines of one word as output, which we can easily look at quickly for anything interesting.

root@kali:~/csaw# tr -s '[:space:]' < console.log | cut -d" " -f5- | grep -E '^[[:alnum:]]{10,}$' | wc -l
296

There are a lot of technical and repeated terms, but in the noise we see a clear outlier.

postPearlInterlockFollowUpItem
DeviceDiscoveryActivate
DeviceDiscoveryActivate
DeviceDiscoveryUpdate
postPearlInterlockFollowUpItem
postPearlInterlockFollowUpItem
keybagDidUnlock
ca3412b55940568c5b10a616fa7b855e
postPearlInterlockFollowUpItem
Invalidating
Invalidated

There appears to be a hash!

If we search for this in the debug log, we find the line.

root@kali:~/csaw# grep -n 'ca3412b55940568c5b10a616fa7b855e' console.log 
97190:default 19:12:18.884704 -0400   Preferences ca3412b55940568c5b10a616fa7b855e

The application is Preferences, which makes sense since this appears to be a settings or preferences related application.

The flag is ca3412b55940568c5b10a616fa7b855e.

Overall, I did not really enjoy this challenge. The moderator of the challenge on chat noted that the application was "littered with hints" about where to look, but I disagree.

The hint that it was a hex string made it more reasonable, but that hint came late and the challenge still remained a "grepping" challenge. We had to use a jailbroken iPhone before the hint to find the flag, which should not have felt like it was important when the challenge explicitly said a device was not needed.

Anyway, I'm glad I came up with an alternative way, but I think I was too focused looking for a keyword or something else in the debug log that would hint at the location to think of a method of filtering by format.

We are given a tar archive for the challenge that we can extract.

root@kali:~/csaw/rewind# tar -xvf rewind.tar.gz 
rewind.zip

We can now extract this zip archive.

root@kali:~/csaw/rewind# unzip rewind.zip 
Archive:  rewind.zip
  inflating: rewind-rr-nodent.log    
  inflating: rewind-rr-snp

We can take a look at what these files are with the file utility.

root@kali:~/csaw/rewind# file *
rewind-rr-nodent.log: data
rewind-rr-snp:        QEMU suspend to disk image

We can first try to search for the flag within the image with a regular expression.

root@kali:~/csaw/rewind# grep -a "flag{.*}" rewind-rr-snp
...
flag{RUN_R3C0RD_ANA1YZ3_R3P3AT}
...

Success! That was all that was required to complete this challenge.

Overall, this was an extremely simple challenge that only required extracting two archives and performing a simple search for the flag in the image.

This is a forensics challenge worth 150 points.

We are given a pcap file to analyze. After opening it up in Wireshark, we can follow the TCP streams to get a feel of what's going on.

Browsing through the streams, we notice there is a lot of HTTP traffic for school registration. The requests are mostly the same with random fields for names, schools, and courses. The responses all appear to be the same.

Briefly looking at the other traffic in the pcap suggests there is not anything else too interesting for this challenge. The challenge description mentions registration and these forms, so it's very likely the answer is in this HTTP traffic somewhere.

Since the responses all appear the same, let's focus on the requests. The headers change slightly for some of the requests. Most of the requests have these headers:

POST / HTTP/1.1
Host: 192.168.0.21:8080
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.11.1
Content-Length: 506
Content-Type: application/x-www-form-urlencoded

While some of the requests have these headers.

POST / HTTP/1.1
Host: 192.168.0.21:8080
Accept-Encoding: identity
Content-Length: 493
Content-Type: application/x-www-form-urlencoded

Basically, one request is asking for compression and one isn't. This could be something of note, but these headers don't contain the flag, so we can go back to it later.

Switching over to the values in the request, we see "n" and "s". The former is a long string of hex values and the latter is a single letter from A-F. I think the latter could be for grades. At this point I thought the flag must be in "n", but then I noticed that there was an "x" value in certain requests, those with the "Accept-Encoding" header of "identity."

The hex values for "n" and "x" did not decode into ASCII. What else could they be? Well, there are enough values for a small file, so we can try looking for that.

I need to extract these values together into a file, turn them into a binary, and then use a tool like foremost to identify any potential files.

I used the following command to extract the values cleanly:

strings cap.pcap | grep -o -f expression | sed 's/&x=//g' | tr -d '\n' | sed 's/[^A-Fa-f0-9]//g' > output.txt

where "expression" is a file with contents (here, it's "x", but it could be "n" as well):

&x=.*

Broken down, strings is grabbing the text of the pcap, grep is only extracting content that matches the regular expression in the file "expression," which is just the value syntax "&x=" followed by a regular expression, ".*", to match whatever comes after that syntax. Next, sed is removing the value syntax, "&x=", tr is removing new lines, and sed is removing any non-hex values.

To convert these hex values from a string to values in a binary, we can use a short Python script.

string_hex_file = open("output.txt", "r")
hex_as_string = string_hex_file.read()

hex_as_binary = hex_as_string.decode("hex")
binary_hex_file = open("binary", "w+")
binary_hex_file.write(hex_as_binary)

string_hex_file.close()
binary_hex_file.close()

We simply open our output file, read the bytes as hex, and write them to a new file.

Now, we can use a tool like foremost to extract any files that might be in there.

root@kali:/opt/ctf/csaw17# foremost -i binary
Processing: binary
|*|

It looks like it found a bmp file, which could be an image with the flag. Let's check it out!

root@kali:/opt/ctf/csaw17/output# ls
audit.txt  bmp
root@kali:/opt/ctf/csaw17/output# ls bmp
00000000.bmp
root@kali:/opt/ctf/csaw17/output# eog bmp/00000000.bmp 

Success!

It was pretty apparent quickly that the flag was likely somewhere in the HTTP requests, but it took time to spot the "x" value (since it was only in some requests and somewhat hidden after the "n value") and then to realize there could be a file header inside. Overall, this was a fun and interesting challenge.

This was a simple forensics challenge worth 200 points.

We are given an archive which we can easily extract.

root@kali:/opt/ctf/csaw17/best_router# tar -xvf best_router.tar.gz 
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime'
tar: Ignoring unknown extended header keyword 'SCHILY.dev'
tar: Ignoring unknown extended header keyword 'SCHILY.ino'
tar: Ignoring unknown extended header keyword 'SCHILY.nlink'
best_router.img

We can now run binwalk on it to analyze the firmware.

root@kali:/opt/ctf/csaw17/best_router# binwalk best_router.img

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
4886543       0x4A900F        Copyright string: "copyright does *not* cover user programs that use kernel"
...
4905514       0x4ADA2A        Copyright string: "Copyright (c) 2015, Raspberry Pi (Trading) Ltd"

Looking at this output, we can see that it's a Raspberry Pi device, which we can mount by following this guide.

root@kali:/opt/ctf/csaw17/best_router# fdisk -l best_router.img
Disk best_router.img: 14.6 GiB, 15640559616 bytes, 30547968 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7f39f284

Device           Boot Start      End  Sectors  Size Id Type
best_router.img1       8192    93813    85622 41.8M  c W95 FAT32 (LBA)
best_router.img2      94208 30547967 30453760 14.5G 83 Linux

We can now mount the device after calculating the offset.

root@kali:/opt/ctf/csaw17/best_router# mount -v -o offset=48234496 -t ext4 best_router.img /mnt/img/router
mount: /dev/loop0 mounted on /mnt/img/router.

After we have mounted it, we can go exploring. I first looked at the /home/ directory and found the "pi" user. We can take a look at the bash history.

root@kali:/mnt/img/router/home/pi# cat .bash_history 
ls
sudo su

It looks like they switched to root, so let's check there.

root@kali:/mnt/img/router/root# cat install.sh 
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2enmod cgid

sudo cp 000-default.conf /etc/apache2/sites-available/000-default.conf
sudo service apache2 restart

sudo rm -rf /var/www/*
sudo mv www/* /var/www
chmod 755 /var/www/*.pl

It looks like there is an installation script to install a website. Let's check what's in that directory.

root@kali:/mnt/img/router/var/www# ls -l
total 16
-rw-r--r-- 1 root root    0 Sep 10 00:43 flag.txt
-rwxr-xr-x 1 root root  472 Sep 10 00:51 index.pl
-rwxr-xr-x 1 root root 1238 Sep 10 00:50 login.pl
-rw-r--r-- 1 1000 1000   23 Sep 10 00:49 password.txt
-rw-r--r-- 1 1000 1000    5 Sep 10 00:49 username.txt

There is an empty flag file, but there are username and password files.

root@kali:/mnt/img/router/var/www# cat username.txt
admin
root@kali:/mnt/img/router/var/www# cat password.txt 
iforgotaboutthemathtest

These look useful. Let's try them on the website they gave us in the challenge prompt.

Authenticated

flag{but_I_f0rgot_my_my_math_test_and_pants}

Success!

Overall, this was a pretty simple forensics problem that required mounting the image and exploring the file system for the value content.