# LACTF – A Hacker's Notes

* **Category:** Misc
* **Author:** burturt

## Challenge

> We managed to get ahold of a flash drive which we think contains the decryption keys for the ransomware that a hacker group tried to deploy on our computer network! However, it seems like the hacker encrypted the flash drive. We know that the organization uses passwords in the format hacker### (hacker + 3 digits) for their disks, but a much stronger encryption password once you login. Can you try to get access to their notes?

## Solution

The challenge contains `hackers-drive.dd`, which is the hacker's encrypted flash drive.

$ file hackers-drive.dd 
hackers-drive.dd: LUKS encrypted file, ver 1 [twofish, cbc-plain, sha1] UUID: 456aa573-ab59-4146-a2f3-874a808b9c08

It is encrypted using Linux Unified Key Setup (LUKS). [This blogpost](https://www.forensicfocus.com/articles/bruteforcing-linux-full-disk-encryption-luks-with-hashcat/) explains how to use hashcat to brute-force the password. I wrote a quick python script to generate all possible passwords of the form `hacker###`.

$ hashcat -a 0 -m 14600 hackers-drive.dd wordlist.txt 
hashcat (v6.2.5) starting

[REDACTED]

hackers-drive.dd:hacker765                                
                                                          
[REDACTED]

Now I can decrypt and mount the disk.

$ sudo cryptsetup luksOpen hackers-drive.dd Decrypted 
Enter passphrase for hackers-drive.dd:
$ sudo mkdir /mnt/decrypted                           
$ sudo mount /dev/mapper/Decrypted /mnt/decrypted 
$ tree -a -C 
.
├── .bash_history
├── .config
│   └── joplin
│       ├── cache
│       ├── database.sqlite
│       ├── log.txt
│       ├── resources
│       ├── settings.json
│       └── tmp
│           └── 8c5217bacb8047a284310205ed733738.md~
├── .emacs.d
├── encrypted-notes
│   ├── b692aaeaf3494fa29121524802940dc2.md
│   ├── f6fdd827811741a5b8b796b7778b2f4b.md
│   ├── info.json
│   ├── .lock
│   ├── locks
│   ├── .resource
│   ├── .sync
│   │   ├── readme.txt
│   │   └── version.txt
│   └── temp
├── .local
│   └── share
│       └── nano
├── lost+found
├── note_to_self.txt
└── .sqlite_history

16 directories, 12 files

The drive contains multiple interesting files:

- `note_to_self.txt`

Note to self: delete notes and notes_normalized tables in .config/joplin/database.sqlite when not in use; allow encrypted sync to restore notes after

- `.bash_history`

$ cat .bash_history       
joplin
cd .config/joplin
ls -lah
sqlite3 database.sqlite 
ls
ls -lah
cat database.sqlite | grep lactf
cd ..
cd ..
ls
ls -lah
nano note_to_self.txt
ls -lah
ls
zerofree /dev/mapper/notes
exit

- `.sqlite_history`

$ cat .sqlite_history    
.tables
select * from notes;
select * from *;
select * from notes_fts;
select * from qexit
exit
.exit
;
exit
;
.exit
.tables
select * from notes;
delete from notes;
select * from notes;
VACUUM;

[REDACTED]

From these three files, I start to understand what happened. The hacker uses the open-source app Joplin to take his notes. This app has the possibility to enable end-to-end encrypted sync. The hacker then says in `note_to_self.txt` to always delete all information from `.config/joplin/database.sqlite`. The history files indicate that he succesfully did that.

Now let's recover the notes.

1. Install Joplin
2. Replace your config with the hacker's `.config` directory
3. In `Tools` > `Options` > `Synchronisation`, set the hacker's `encrypted-notes` directory as `Directory to synchronise with`.
4. Synchronise

Once that is done, his notes are accessible and contain the flag!