Magnet Weekly CTF Challenge Week 12 Writeup - Last But Not Least

Time flies and finally we have made it into the last week of Magnet Weekly CTF. This week was still a two-parter. The 1st part of the challenge asked of a PID:
Using HxD to search the key phrase "how hackers hack, and how to stop them" inside the memory dump, a hit could be found quickly: 


After that, the Volatility yarascan plugin was used to find the PID that related to "how hackers hack, and how to stop them". 
The Hex value corresponding to the "How Hackers Hack, and How To Stop Them" string value discovered from HxD could be reused as the search criterion for yarascan, the  "python vol.py -f ../memdump.mem --profile=Win7SP0x64 yarascan -Y "{48 6F 77 20 48 61 63 6B 65 72 73 20 48 61 63 6B 2C 20 61 6E 64 20 48 6F 77 20 54 6F 20 53 74 6F 70 20 54 68 65 6D}" command was issued in terminal:

From the yarascan output, all hits came from the "iexplore.exe" process with PID 4480.
Therefore, the answer for the part 1 challenge should be 4480.

Following completion of the part 1 challenge, part 2 challenge was revealed:

Since the application was identified as "iexplore.exe" with PID 4480, the Volatility procdump plugin was used to dump the process executable, in order to determine the product version of the application. The "python vol.py -f ../memdump.mem --profile=Win7SP0x64 procdump -D . -p 4480" command was issued in terminal:

Upon the successful process executable dump, Properties from Microsoft Windows could quickly tell the product version of the "iexplore.exe":

The answer for the part 2 challenge was "11.00.9600.18858".

Conclusion

I had a great time participating in the Magnet Weekly CTF. Apart from solving the challenges on my own, I also learnt a lot from reading other participants' write-ups. 





Comments

Post a Comment

Popular posts from this blog

Dumpster Diving in Google Photos Android App: "local_trash.db"

Image
  This article will explore the Trash within the Google Photos Android App. If you delete any media file from Google Photos on your mobile device, the deleted media file would then be relocated to the Trash within Google Photos. All items inside Trash will be permanently deleted after 60 days in Trash. In fact, the information of the Google Photos Trash items will be stored inside the " local_trash.db " under " /data/com.google.android.apps.photos/databases/ ": The " local " table of  " local_trash.db " contains most of the useful information, including " local_path " ( the original path of the deleted media file ), " trash_file_name " ( a UUID value that becomes the new name of the deleted media file ), " deleted_time " ( a Unix timestamp in milliseconds that recorded the delete time ), " is_video " ( where "0" = "no", "1" = "yes" ), etc. As soon as a media file was
Read more

An Android Casting (Device) Story: "cast.db"

Image
  This article will briefly document a SQLite database (" cast.db ") found from Android devices, which would store the information of detected casting devices on the Wi-Fi network. The said " cast.db " can be recovered at " /data/com.google.android.gms/databases/cast.db ".  Using Joshua Hickman's Android 10 image as an example, " DeviceInfo " table from  " cast.db "  would store the casting device ID (SSDP UDN), device friendly name, device model name, device IP address and port number, hotspot BSSID , etc. Apart from the basic information of the casting devices, some interesting Epoch timestamps in milliseconds like " last_published_timestamp_millis ", " last_discovered_timestamp_millis " and " last_discovered_by_ble_timestamp_millis " could be discovered as well.  There were some other intriguing tables such as " NetworkInfo ", which probably records the last connected time to a Wi-Fi networ
Read more