BACKUPMON BACKUPMON v1.9.1 [2025-Oct-28] - Backup/Restore your Router: JFFS + NVRAM + External USB Drive! CIFS/SMB/NFS! (Available in AMTM!)

[salvo]

By the way, it is worth noting that nation-states have been intercepting and storing vast amounts of encrypted internet traffic for years in covert data centers, with the long-term goal of decrypting it once quantum computing capabilities become sufficiently advanced. Not sure if that affects you or not.

Not much to hide anyway!

Overall, backupmon's encryption is working well. One thing worth considering, currently the encryption password remains visible within backupmon after it's been entered, which ideally shouldn't be the case. Once the password is set and validated, it should never be retrievable or displayable again but not sure how the most password or backup managers handle such a cases. Alternatively, could the encryption settings include an option to store backupmon.cfg in a separate UNC path? In my case, the backup covers the entire UNC folder, which also contains backupmon.cfg itself.

 

[Viktor Jaep]

Not much to hide anyway!

Overall, backupmon's encryption is working well. One thing worth considering, currently the encryption password remains visible within backupmon after it's been entered, which ideally shouldn't be the case. Once the password is set and validated, it should never be retrievable or displayable again but not sure how the most password or backup managers handle such a cases. Alternatively, could the encryption settings include an option to store backupmon.cfg in a separate UNC path? In my case, the backup covers the entire UNC folder, which also contains backupmon.cfg itself.

I've been thinking about the same thing, @salvo. I know the .cfg is the Achilles heel in this whole process. I'm going to start working on a second iteration of this that uses a salt derived from your master password to do the encryption/decryption. To decrypt, you would need to provide your master password. I should be able to make some progress this weekend.

 

[salvo]

I've been thinking about the same thing, @salvo. I know the .cfg is the Achilles heel in this whole process. I'm going to start working on a second iteration of this that uses a salt derived from your master password to do the encryption/decryption. To decrypt, you would need to provide your master password. I should be able to make some progress this weekend.

Yes, that would be a very elegant solution

 

[rung]

I've been thinking about the same thing, @salvo. I know the .cfg is the Achilles heel in this whole process. I'm going to start working on a second iteration of this that uses a salt derived from your master password to do the encryption/decryption. To decrypt, you would need to provide your master password. I should be able to make some progress this weekend.

Sounds neat. Automated encryption, manual decryption.

 

[rung]

Not sure what exactly you had in mind, but here is an idea that uses a backupmon public/private key pair to accomplish this:

#!/bin/sh

BD=/tmp/backupmon
mkdir $BD 2> /dev/null
BACKUP=$BD/backup.txt
cat <<EOF > $BACKUP
-------------------------------
| This is a backup file. |
| It will be stored encrypted. |
-------------------------------
EOF
RESTORED=$BD/restored.txt

#Demo only. User entry in practice
PASSFILE=$BD/passphase.txt
echo -n "This is a passphrase!" > $PASSFILE

PRIVKEY=$BD/backupmon.pem
PRIVKEYASC=$BD/backupmon.asc
PRIVKEY2=$BD/backupmon2.pem
PUBKEY=$BD/backupmon.pub
BACKUPENC=$BD/backup.enc
KEYFILE=$BD/key.bin
KEYFILEENC=$BD/key.enc
KEYFILE2=$BD/key2.bin

#Only done once per backupmon install:
#rm $PRIVKEY
if [ ! -f $PRIVKEY ]; then
        #Create key pair and secure with passphrase
        openssl genrsa -passout file:$PASSFILE -out $PRIVKEY -aes256 4096
        #Extract public key for encrypting backup key
        openssl rsa -in $PRIVKEY -passin file:$PASSFILE -pubout -out $PUBKEY
        #Ascii versions of key pair
        openssl base64 -in $PRIVKEY -out $PRIVKEYASC

        #Put $PRIVATEKEYASC and PUBKEY ascii files in backupmon.cfg
fi

echo "Input backup:"
cat $BACKUP

#Do this for every backup

#Random key for each backup
openssl rand -out $KEYFILE 32
#Encrypt backup with this key
openssl enc -aes-256-cbc -pbkdf2 -e -in $BACKUP -out $BACKUPENC -pass file:$KEYFILE
#Encrypt random key with Public Key
openssl pkeyutl -encrypt -pubin -inkey $PUBKEY -in $KEYFILE -out $KEYFILEENC

#Archive encrypted backup and encrypted key files $BACKUPENC and $KEYFILEENC

#Do this to restore
#Restore encrypted private key from config file
openssl base64 -d -out $PRIVKEY2 -in $PRIVKEYASC
#Decrypt unique backup key with private key (requires passphrase)
openssl pkeyutl -decrypt -passin file:$PASSFILE -inkey $PRIVKEY2 -in $KEYFILEENC -out $KEYFILE2
#Decrypt backup with decrypted key
openssl enc -aes-256-cbc -pbkdf2 -d -in $BACKUPENC -out $RESTORED -pass file:$KEYFILE2

echo ""
echo "Restored backup:"
cat $RESTORED

Updated with more detail explaining method

 

[Viktor Jaep]

Not sure what exactly you had in mind, but here is an idea that uses a backupmon public/private key pair to accomplish this:

#!/bin/sh

BACKUP=/tmp/backup.txt
cat <<EOF > $BACKUP
-------------------------------
| This is a backup file.       |
| It will be stored encrypted. |
-------------------------------
EOF
RESTORED=/tmp/restored.txt

PRIVKEY=/tmp/backupmon.pem
PUBKEY=/tmp/backuomon.pub
BACKUPENC=/tmp/backup.enc
KEYFILE=/tmp/key.bin
KEYFILEENC=/tmp/key.enc
KEYFILE2=/tmp/key2.bin

#Only done once per backupmon install:
if [ ! -f $PRIVKEY ]; then
        #Create key pair and secure with passphrase
        openssl genrsa -out $PRIVKEY -aes256 4096
        #Extract public key for encrypting backup key
        openssl rsa -in $PRIVKEY -pubout -out $PUBKEY
fi

echo "Input backup:"
cat $BACKUP

#Do this for every backup

#Random key for each backup
openssl rand -out $KEYFILE 32
#Encrypt backup with this key
openssl enc -aes-256-cbc -pbkdf2 -e -in $BACKUP -out $BACKUPENC -pass file:$KEYFILE
#Encrypt random key with Public Key
openssl pkeyutl -encrypt -pubin -inkey $PUBKEY -in $KEYFILE -out $KEYFILEENC

#Archive encrypted backup and encrypted key

#Do this to restore
#Decrypt backup key with private key (requires passphrase)
openssl pkeyutl -decrypt -inkey $PRIVKEY -in $KEYFILEENC -out $KEYFILE2
#Decrypt backup with decrypted key
openssl enc -aes-256-cbc -pbkdf2 -d -in $BACKUPENC -out $RESTORED -pass file:$KEYFILE2

echo ""
echo "Restored backup:"
cat $RESTORED

It's pretty close to what I had in mind, but I won't be writing anything to different key files, nor will I be using public/private key infrastructure. It will all stay in the .cfg using a salt/hash, and that will be all we need along with a master password that never needs to get saved. But all in all, fairly close!

 

[Viktor Jaep]

I should be able to post a working version later tonight for testing...

 

[rung]

It's pretty close to what I had in mind, but I won't be writing anything to different key files, nor will I be using public/private key infrastructure. It will all stay in the .cfg using a salt/hash, and that will be all we need along with a master password that never needs to get saved. But all in all, fairly close!

Great. Just be careful of using the same encryption key for multiple backups.

 

[Viktor Jaep]

Great. Just be careful of using the same encryption key for multiple backups.

My bitwarden is giving you a angry face. Ha!

 

[Viktor Jaep]

For all who are interested, @salvo @rung -- here's a later beta that now no longer saves your master password in the config file, but uses a combination of a salt, hash and nonce file to uniquely encrypt each backup. You will now see a unique enc.nonce file being written along with your backups that is used to decrypt your backups when needed. Don't delete these!

BACKUPMON v1.10.0b7 (Unofficial TEST Pre-Beta)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

BACKUPMON v1.9.1 (Stable)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

What an attacker gets in each scenario

1. If they steal only backupmon.cfg, they get the salt and hash. They cannot reverse SHA-256 to recover the Master Password without brute-forcing it, and the salt makes precomputed attacks useless.
2. If they steal only a backup folder, they get the encrypted files and the enc.nonce. Without the hash from the config, they cannot derive the encryption key. The nonce alone is useless.
3. If they steal both the config and a backup folder, they have the salt, hash, and nonce. They still cannot decrypt without the original Master Password, because the hash cannot be reversed and the only path forward is to brute-force the password. The 100,000 PBKDF2 iterations inside OpenSSL make each guess expensive to compute.
4. If they steal multiple backup folders, each has a different nonce and was encrypted with a different key. Breaking one gives them nothing about the others, because the per-backup keys are independent SHA-256 outputs.

I think that's going to lock things down pretty tight, at least until PQE hits.

 

[Ripshod]

I'm in!
First backup/restore test went absolutely fine with a 24 character Master Password.

 

[visortgw]

For all who are interested, @salvo @rung -- here's a later beta that now no longer saves your master password in the config file, but uses a combination of a salt, hash and nonce file to uniquely encrypt each backup. You will now see a unique enc.nonce file being written along with your backups that is used to decrypt your backups when needed. Don't delete these!

BACKUPMON v1.10.0b7 (Unofficial TEST Pre-Beta)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

BACKUPMON v1.9.1 (Stable)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

What an attacker gets in each scenario

1. If they steal only backupmon.cfg, they get the salt and hash. They cannot reverse SHA-256 to recover the Master Password without brute-forcing it, and the salt makes precomputed attacks useless.
2. If they steal only a backup folder, they get the encrypted files and the enc.nonce. Without the hash from the config, they cannot derive the encryption key. The nonce alone is useless.
3. If they steal both the config and a backup folder, they have the salt, hash, and nonce. They still cannot decrypt without the original Master Password, because the hash cannot be reversed and the only path forward is to brute-force the password. The 100,000 PBKDF2 iterations inside OpenSSL make each guess expensive to compute.
4. If they steal multiple backup folders, each has a different nonce and was encrypted with a different key. Breaking one gives them nothing about the others, because the per-backup keys are independent SHA-256 outputs.

I think that's going to lock things down pretty tight, at least until PQE hits.

Minor bug (but workaround). I was unable to enable encryption for secondary backup in my one off configuration (I have secondary backup disabled as I only invoke it from command line using cru entry) — entering (4) from Configure Backup Encryption menu simply refreshes menu. Workaround is to temporarily enable secondary backup, configure encryption, and then disable secondary backup.

 

[Viktor Jaep]

Minor bug (but workaround). I was unable to enable encryption for secondary backup in my one off configuration (I have secondary backup disabled as I only invoke it from command line using cru entry) — entering (4) from Configure Backup Encryption menu simply refreshes menu. Workaround is to temporarily enable secondary backup, configure encryption, and then disable secondary backup.

Thanks for the report. Entering (4) in the Encryption menu with the secondary backup being disabled will result in the screen just refreshing. It sets all variables to 0, and saves the config. I suppose you could enable the secondary backup, enable encryption for the secondary backup, save your config, then disable secondary backups... then the encryption settings would remain unaltered if you wanted to one-off enable/disable secondary backups. How did you envision this to work, or what is your use-case?

 

[Viktor Jaep]

After having some deep discussions with @rung yesterday, I came to the decision to change the encryption methodology for yet a 3rd time. I'm hoping this is the last, because there's really not many other avenues to go down at this point.

BACKUPMON is now using PKI certificates (public/private keys) to backup and restore encrypted archives using similar types of methods as described above by @rung. The other methods, while secure from a cryptography standpoint, would easily be able to get bypassed if your backups and settings were compromised. With PKI, if an attacker got all your backups and settings, they would still face one last hurdle, which is the Master Password that your private key was encrypted with, so your encrypted archives remain safe.

Yes, this will mean any encrypted archives you might currently have are going to be unrecoverable, because when you configure your encryptions settings under the EN) option, you will need to make a new public/private key pair. Glad we're still in a pre-beta.

BACKUPMON v1.10.0b11 (Unofficial TEST Pre-Beta)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

BACKUPMON v1.9.1 (Stable)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

 

[rung]

After having some deep discussions with @rung yesterday, I came to the decision to change the encryption methodology for yet a 3rd time. I'm hoping this is the last, because there's really not many other avenues to go down at this point.

BACKUPMON is now using PKI certificates (public/private keys) to backup and restore encrypted archives using similar types of methods as described above by @rung. The other methods, while secure from a cryptography standpoint, would easily be able to get bypassed if your backups and settings were compromised. With PKI, if an attacker got all your backups and settings, they would still face one last hurdle, which is the Master Password that your private key was encrypted with, so your encrypted archives remain safe.

Yes, this will mean any encrypted archives you might currently have are going to be unrecoverable, because when you configure your encryptions settings under the EN) option, you will need to make a new public/private key pair. Glad we're still in a pre-beta.

BACKUPMON v1.10.0b11 (Unofficial TEST Pre-Beta)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

BACKUPMON v1.9.1 (Stable)

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Viktor,

Nice work! Installed and successfully did an encrypted backup. Super easy.

Now - kind of a feature request. I sometimes would like to explore my backups (e.g. pull out an old script from the tar) or look at the nvram.txt file. Any suggestions on how to 1) verify the decryption works and 2) do a decryption operation without a full restore so I can inspect the unencrypted contents?

Thanks!
Rung

 

[Ripshod]

Testing

 

[Viktor Jaep]

Viktor,

Nice work! Installed and successfully did an encrypted backup. Super easy.

Now - kind of a feature request. I sometimes would like to explore my backups (e.g. pull out an old script from the tar) or look at the nvram.txt file. Any suggestions on how to 1) verify the decryption works and 2) do a decryption operation without a full restore so I can inspect the unencrypted contents?

Thanks!
Rung

I really like that idea... like a 1-off decryption of a file to a target location of your choosing without unzipping the tar, etc. I can work on that!

 

[visortgw]

Thanks for the report. Entering (4) in the Encryption menu with the secondary backup being disabled will result in the screen just refreshing. It sets all variables to 0, and saves the config. I suppose you could enable the secondary backup, enable encryption for the secondary backup, save your config, then disable secondary backups... then the encryption settings would remain unaltered if you wanted to one-off enable/disable secondary backups. How did you envision this to work, or what is your use-case?

I would allow encryption to be enabled/configured for secondary backup independent of whether secondary backup was enabled. I never enable secondary backups, but rather run them manually using -secondary flag either from command line or using cru entry.

 

[Viktor Jaep]

I would allow encryption to be enabled/configured for secondary backup independent of whether secondary backup was enabled. I never enable secondary backups, but rather run them manually using -secondary flag either from command line or using cru entry.

OK, but if you are running the -secondary flag, secondary backups would have to already be enabled, which means that the encryption menu would allow you to configure encryption for the secondaries. Or am I missing something?

Do you automatedly enable/disable the secondaries in the config with a script?

 

[Viktor Jaep]

I think we're at a point where this can be tested wider beyond the "pre-betas"... Things are looking pretty stable! Please give it a try to make sure I haven't broken anything.

What's new!?
v1.10.0b12- (TBA)
- MINOR: Added the ability to apply enterprise-strength encryption to your primary and secondary backup sets. Huge thanks to @salvo for the encouragement, and lighting a fire under me. This was a fun exercise. New item under the main setup and operations menu, using option (en)cryption. Complete sub-menu that allows you to configure your encryption options for both your primary and secondary backups, as well as choosing between the AES-256 and AES-128 ciphers. The latter is still a very strong and secure encryption, but may perform better on older devices, or larger backup sets. Major rework had to be done to ensure integrity can still be checked, now needing to decrypt before checking for this.
- PATCH: Reworked the encryption methodology a 3rd time after some discussion with @rung, and replaced the salt/hash/nonce method in favor of using PKI RSA-4096/AES-256-CBC (public/private key pairs). These key pairs are located in the backupmon.cfg for ease of use and encryption/decryption purposes. Your private key is encrypted with a Master Password that you must know to successfully decrypt any file.
- PATCH: Added functionality to the main setup and operations menu that allows for the selection and decryption of a single file in a location of your choosing. This option is available using (de)crypt, and will prompt you through a successful file decryption.
- PATCH: Various bugfixes, wording changes and cleanup!
- PATCH: Added "unset LD_LIBRARY_PATH" statement due to the latest Entware binaries using the RUNPATH embedded library search path mechanism instead of the previous RPATH method. RUNPATH is searched *AFTER* the LD_LIBRARY_PATH definitions, whereas RPATH has higher priority than the LD_LIBRARY_PATH environment variable, so it's searched FIRST. Thanks to @Martinski for his advice.
- PATCH: Made BACKUPMON compliant with the amtmupdate functionality to allow for autoupdates through AMTM.

Download Link (BETA) v1.10.0b12

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/develop/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Download Link (RELEASE) v1.9.1

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/BACKUPMON/master/backupmon.sh" -o "/jffs/scripts/backupmon.sh" && chmod 755 "/jffs/scripts/backupmon.sh"

Significant Screenshots:

New Encryption-related menu items.

Setting your encryption options:

Running through a single file decryption and placing it in a location of your choice without doing a full restore: