ACSC 2021 write-up
Ended up in solving only one challenge... I've omitted some small details so feel free to ask me if there is something unclear. There will be more write-ups in a week or so. Many CTF organizers keep their problem servers for a while for players willing to review challenges so you can follow them with the help of other write-ups.
NYONG coin
NyongCoin.E01 is an image file of USB which you can open via FTK Imager. The tool says it consists of a single FAT32 partition with some spreadsheets (.xlsx) at its root. You can safely ignore .FileSlack because they are small so seem to have no useful information. https://gyazo.com/818f2ebf07a030775a6efe0d40b82b0f
Plus, unallocated space 018837 seems to be have some non-zero bytes. There should not be any meaningful data left in unused space, but operating systems are lazy so they don't rewrite all the deleted content but just "mark" it as deleted; and removing that "mark" shows the file in the Explorer.exe... that's how some file recovery softwares work. You see PK... and [Content_Types].xml around 0x1000? PK.. is the signature of ZIP file and that [Content_Types].xml is usually contained in a XLSX, which is a ZIP file.
https://gyazo.com/982e6db3b176252e48acf71cb7125492
Then here comes the assumption: Lee (employee) has removed the original XLSX and put the manipulated XLSX instead? I don't know, it just might be a decoy to trick us. Anyway, let's recover files in the unallocated area by binwalk. It says there are multiple XLSX but I doubt it considering the size of XLSX. 018837 has the size of 100MB but they are full of null bytes so it should not contain a 100MB XLSX. Seems they are double-counting the same XLSX. I didn't know which to use so decided to pack other exported files into ZIP, and rename it as XLSX. Each XLSX at the root has 7, 8MB and this one has 6MB which is close to it.
code:shell
$ binwalk -Me 018837
$ ls _018837.extracted
$ mv recovered.zip recovered.xlsx
The extracted XLSX has the transactions starting 2020/07/15 (Jul 15 2020), ending in 2020/08/16 (Aug 16 2020). Note that this CTF is the qualification for students in Asia where they use YYYY/MM/DD-styled date.
https://gyazo.com/a0d14f68e8b7daaa79ae7d96c1b5773a
Remember we have 20200715132932_20200816181652.xlsx on the root of the filesystem? This might be the manipulated one. You can use WinMerge to compare these spreadsheets (there should be more convenient/Unix-friendly way). We have the recovered one on the left and the manipulated(?) one on the right. Take a look at the very last character of the transaction ID on the highlighted line. "c" and "d".
https://gyazo.com/06067a42679a7cf00451ed942ae21f80
Now we have two inconsistent transaction ID. The one which ends in "d" turned out to be the FLAG.
BitLockerArtifact (could not obtain the FLAG)
The attached files have no or weird extensions such as LOG1. After some googling, they turned out to be Windows registry files (or hive files?). RFV is capable of opening registry files. grep (ripgrep) says ... code:sh
$ rg -lia BitLocker
NTUSER.DAT
SOFTWARE
DEFAULT
SOFTWARE.LOG1
COMPONENTS
SYSTEM.LOG1
SYSTEM.LOG2
SYSTEM
SOFTWARE.LOG2
So take a look at SYSTEM (the one without an extension). ControlSet/Services/bam/State/UserSettings/(user id or something?) takes note of which executable was executed when. It says BitLockerWizardElev.exe was executed on 2021-08-23 10:58:28.
https://gyazo.com/46c4380645fa109ea2c1c5b9e36bc026
And fvenotify.exe on 2021-08-23 11:02:12. FVE means "Full Volume Encryption" so I thought this notified the user of the completion of the encryption. However, the score server didn't give me the points for a flag made of these two timestamps.
https://gyazo.com/4545d3df8a6696d0482591602da24594
Thus I had to be more precise. The challenge says:
End: When encryption was completed by BitLocker (UTC+0, YYYY-MM-DD_HH:MM:SS)
After looking around for another timestamp, I found this at ControlSet001/Controls/FVEStats:
https://gyazo.com/a580e865033838c1c585e361f0c5b992
... though the score server told me it was wrong.
The challenge description tells us to use UTC+0. "Lee" and "Kim" sound like Korean names, so it is likely the machine's timezone is set to KST (Korea Standard Time), which is UTC+9. And it was:
https://gyazo.com/6c216596ef7adaeb1425cd9b7ad514ba
However, those two FLAG candidates were still incorrect after shifting 9 hour considering the timezone.
bitter (could not obtain the FLAG)
Extracting BitLocker Keys from a TPM seems helpful. I tried to figure out a way to remove glitches using given multiple set of signals (I've seen it someone do so on ChipWhisperer for AES side-channel attack) on PulseView, but no luck.