Ohh no! I can’t remember anything, where have I been?

Solution 1:

The file signature (aka ‘Magic Bytes’) for image.bin didn’t help with determining which file format I was dealing with:

$ file image.bin
image.bin: data

Manually grabbing the first few bytes of the file and doing a Google search for "53ff 00f0" resulted in an article titled “Experiments with Memory”.

$ xxd image.bin | head -n1
00000000: 53ff 00f0 53ff 00f0 53ff 00f0 53ff 00f0  S...S...S...S...

The article itself wasn’t of further use, but its title, along with the challenge name, “Amnesia” and description “I can’t remember anything”, led me to believe the file was a memory dump. A quick check with Volatility confirmed that theory:

$ -f image.bin imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86_24000, Win7SP1x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/Users/dave/Documents/CTF-Solutions/BSidesBOS/image.bin)
                      PAE type : PAE
                           DTB : 0x185000L
                          KDBG : 0x82982de8L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0x80b96000L
             KUSER_SHARED_DATA : 0xffdf0000L
           Image date and time : 2020-09-19 02:07:20 UTC+0000
     Image local date and time : 2020-09-18 19:07:20 -0700

Before spending cycles analyzing the memory dump with Volatility I tried a quick trick that one should always try early during a CTF challenge:

$ strings image.bin | grep -F 'flag{'{forensic_cookie_hunter}

Well alrighty then…

Solution 2 (aka the intended solution):

The author of the challenge mentioned on Discord that the strings | grep solution was not his intended solution:

In the spirit of the challenge, here is the approach I would have taken had my first solution failed. First, I would dump the process list from the memory image using the profile from the output of the imageinfo I ran earlier. This results in 47 processes that are mostly OS related, except for Chrome Web Browser:

$ -f image.bin --profile=Win7SP1x86_23418 pslist
0x852ce030 chrome.exe             3324   2244     27      721      1      0 2020-09-19 02:02:09 UTC+0000
0x85380030 chrome.exe             3212   3324      8       76      1      0 2020-09-19 02:02:09 UTC+0000
0x859ee030 chrome.exe             2532   3324     15      322      1      0 2020-09-19 02:02:09 UTC+0000
0x85d26338 chrome.exe             3264   3324      8      175      1      0 2020-09-19 02:02:11 UTC+0000
0x842b3030 chrome.exe             1492   3324     14      215      1      0 2020-09-19 02:05:02 UTC+0000
0x955c9380 chrome.exe             1256   3324     11      172      1      0 2020-09-19 02:05:02 UTC+0000
0x85257030 chrome.exe             2188   3324     14      209      1      0 2020-09-19 02:06:04 UTC+0000

At this point the challenge description, where have I been, is a solid clue that the Chrome browsing history is of importance. Chrome stores browsing history in a sqlite database file aptly named History.dat so a search of file handles in memory for “History” is the next step.

$ -f image.bin --profile=Win7SP1x86_23418 filescan | grep History
0x000000003e5a0c30      2      1 RW-rw- \Device\HarddiskVolume1\Users\IEUser\AppData\Local\Google\Chrome\User Data\Default\History
0x000000003e5cf108     17      1 RW-rw- \Device\HarddiskVolume1\Users\IEUser\AppData\Local\Google\Chrome\User Data\Default\History-journal
0x000000003ee6fb90      3      0 -W-r-- \Device\HarddiskVolume1\ProgramData\Microsoft\Windows Defender\Scans\History\Service\Unknown.Log
0x000000003ef89f80      2      1 RW-rw- \Device\HarddiskVolume1\Users\IEUser\AppData\Local\Google\Chrome\User Data\Default\Media History

Next, I carve the file from the memory image using its physical offset, 0x000000003e5a0c30, that I obtained in the previous step:

$ -f image.bin --profile=Win7SP1x86_23418 dumpfiles -Q 0x000000003e5a0c30 -n --dump-dir=./
DataSectionObject 0x3e5a0c30   None   \Device\HarddiskVolume1\Users\IEUser\AppData\Local\Google\Chrome\User Data\Default\History
SharedCacheMap 0x3e5a0c30   None   \Device\HarddiskVolume1\Users\IEUser\AppData\Local\Google\Chrome\User Data\Default\History

Quick validation that the file is a SQLite database:

$ file file.None.0x84f78ee8.History.dat
file.None.0x84f78ee8.History.dat: SQLite 3.x database, last written using SQLite version 3032001

The entire structure of the database can be viewed with .schema command, but the urls table is the obvious choice for viewing visited URLs:

$ sqlite3 file.None.0x84f78ee8.History.dat

sqlite> select * from urls;
12||BSidesBOS CTF|1|0|13244954769028977|0
13||BSidesBOS CTF|1|1|13244954800270085|0

And there’s the URL Encoded flag, flag%7Bforensic_cookie_hunter%7D.



Leave a comment