evilsocket / evilsocket/pwnagotchi
[BUG] The 3rd encrypted container is not automatically decrypted despite the right password being entered
- Dominant language
- Python
- Stars
- 9.2k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I've created 3 separated encrypted container with the steps mentioned [here](https://pwnagotchi.ai/configuration/#example-encrypt-the-configuration-directory) to encrypt respectively the configuration folder of pwnagotchi (named box), the folder containing the caplets of bettercap (named box1) and the handshakes folder (named box2).
Here is my entire configuration file to setup (properly ?) the 3 containers :
> sudo dd if=/dev/zero of=/box bs=1M count=100
> sudo dd if=/dev/zero of=/box1 bs=1M count=100
> sudo dd if=/dev/zero of=/box2 bs=1M count=4000
> sudo cryptsetup luksFormat /box
> sudo cryptsetup luksFormat /box1
> sudo cryptsetup luksFormat /box2
> sudo cryptsetup luksOpen /box box
> sudo mkfs.ext4 /dev/mapper/box
> sudo mount /dev/mapper/box /mnt
> sudo cp -r /etc/pwnagotchi/* /mnt/
> sudo rm -r /etc/pwnagotchi/*
> sudo umount /dev/mapper/box
> sudo cryptsetup luksOpen /box1 box1
> sudo mkfs.ext4 /dev/mapper/box1
> sudo mount /dev/mapper/box1 /mnt
> sudo cp -r /usr/local/share/bettercap/caplets/* /mnt/
> sudo rm -r /usr/local/share/bettercap/caplets/*
> sudo umount /dev/mapper/box1
> sudo cryptsetup luksOpen /box2 box2
> sudo mkfs.ext4 /dev/mapper/box2
> sudo mount /dev/mapper/box2 /mnt
> sudo cp -r /root/handshakes/ /mnt/
> sudo mv /mnt/handshakes/* /mnt/
> sudo rmdir /mnt/handshakes
> sudo rm -r /root/handshakes/
> sudo mkdir /root/handshakes/
> sudo umount /dev/mapper/box2
> sudo chown root:root /home/pi/.pwnagotchi-crypted
> sudo mv /home/pi/.pwnagotchi-crypted /root/.pwnagotchi-crypted
> sudo chmod u+x /usr/bin/decryption-webserver (Added this because I've had issues to access the decryption web portal, issue #879)
> sudo reboot
And with the file _.pwnagotchi-crypted_ containing this :
> config /box /etc/pwnagotchi
> caplets /box1 /usr/local/share/bettercap/caplets
> handshakes /box2 /root/handshakes
**Expected behavior**
The 3 containers are correctly detected when asking for the password :

All the 3 containers should be mounted to their respective folders if the password is correct, but it is only the case with the config and caplets containers. See the screenshots below.
Could it be because of the size of the handshakes container (4 GB) ?
**Screenshots**
Theses first 3 screenshots were just taken after typing the right password on the web page and as you can see on the third screenshot, there are no handshakes despite the other 2 containers mounted properly. I've also checked that the 3 folders were empty before typing the passwords and that's the case.



**Workaround**
However, I've found a way to decrypt and mount the container to /root/handshakes without any issues :
I've created an alias to mount the container to /root/handshakes. So I need to connect to my unit via ssh to mount it and then, everything is ready as you can see on the screenshot below.
Here is the content of the alias inside _.bashrc_ :
> alias pwnmount='sudo cryptsetup luksOpen /box2 handshakes;sudo mount /dev/mapper/handshakes /root/handshakes'

**Environment**
- Pwnagotchi version : 1.5.3 (.img file from [the official repo](https://github.com/evilsocket/pwnagotchi/releases/tag/v1.5.3))
- OS version : Linux pwnagotchi 4.19.93-Re4son+ #1 Wed Jan 8 14:55:22 AEDT 2020 armv6l GNU/Linux
- Type of hardware : RPI0w
- Any additional hardware used : Waveshare v2 display
PS : Sorry for my english, I may have made mistakes...
Contributor guide
Research direction
Start with the _.pwnagotchi-crypted entries and the /usr/bin/decryption-webserver entry point, using the three-container setup in the report to reproduce the missing /root/handshakes mount. Compare this behavior with the manual cryptsetup and mount workaround in .bashrc. Done means the handshakes container mounts automatically alongside the configuration and caplets containers after the correct password is entered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, python
- Domain
- operating-systems, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100