How to encrypt your config & script files

Sinan · Post by **Sinan** » Sun Mar 07, 2004 8:05 am

As the title says how to encrypt your configuration file, so that IF someone get into your box, he cannot read your configuration file because it is encrypted, but the eggdrop have to read it, otherwise he cannot load the settings

GodOfSuicide · Post by **GodOfSuicide** » Sun Mar 07, 2004 10:36 am

you cant
use the forum search, you'll find topics on that only a few days old

Sinan · Post by **Sinan** » Sun Mar 07, 2004 11:41 am

GodOfSuicide wrote:you cant
use the forum search, you'll find topics on that only a few days old

I cannot ? Sure I can, I heard alot about it.

ppslim · Post by **ppslim** » Sun Mar 07, 2004 11:57 am

Then you should have heard why the peoplet hat do this, closly protect there methods.

If they where to become public, then the encryption would be usless.

You have to somehow tell the bot the password to decrypt it

1: If you told it on the command line. People could easily read it.

2: If you specified it embeded into the code, they could easily get the information using common debug tools.

Think about it for a second. How do you tell the bto the password without anybody reading it? You can't!

Sinan · Post by **Sinan** » Sun Mar 07, 2004 12:45 pm

ppslim wrote:Then you should have heard why the peoplet hat do this, closly protect there methods.

If they where to become public, then the encryption would be usless.

You have to somehow tell the bot the password to decrypt it

1: If you told it on the command line. People could easily read it.

2: If you specified it embeded into the code, they could easily get the information using common debug tools.

Think about it for a second. How do you tell the bto the password without anybody reading it? You can't!

When you tweak eggdrop, and put the key in the source, it is possible.

KevKev · Post by **KevKev** » Mon Mar 08, 2004 2:26 pm

ppslim wrote: 2: If you specified it embeded into the code, they could easily get the information using common debug tools.

He already covered embedding it in the source

ppslim · Post by **ppslim** » Mon Mar 08, 2004 7:36 pm

Right, I have a little more time on my hands now, so lets go a little more indepth as to why encryption of this kind is silly and impossible.

OK, I conceed there are a few ways to prevent people from getting the password.

One method is to code the bot such that it reacts to being traced. There are two cources of action here.

1: Destroy the de/encryption password key
2: Kill the bot, so there is no longer a process to trace

There is one large flaw here. An attacker only needs to attempt a trace, and they bring your channel to a standstill with regards to protection.

With method 1, it can no longer tell who a bot owner is from an attacker. The user list is usless. With method two, the bot isn't there to do the protection.

Also with method one, you could potentialy put the channel into a deep security mode. Where the bot will not let anybody change a mode, and deop people. The only issue with this, if two bots are attacked, they would not know each other is safe, thus you end up with a shortlived war, then when bots are restarted, a channel without ops.

That covers protections methods. Lets talk about what they are designed to protect the bot from.

Common tools used to trace program execution, are usualy intended for programers to know what data is where and when.

All well and good, but it also allows attackers to know what passwords are where and when.

There are three locations you could specify the password de/encryption key.

1: Within the source code
2: Specified on the command line at startup
3: When you start the bot, you are asked for it before the program continues.

All three will occupy memory once the bot is loaded. You can't just destroy it once the bot has started, otherwise, what password is used to re-encrypt the userfile and such.

The said debug tools noted above will do the following.

1: Trace the code path and store it
2: The attacker then reads back this information.
3: They locate a line relating to decryptiing the data or resaving
4: Bingo, they should have the information needed to further the quest.

strikelight · Post by **strikelight** » Mon Mar 08, 2004 8:10 pm

However, with method 2, you must assume there are more than one bot (across multiple machines) guarding the channel.. In which case, a single bot not being there for protection isn't going to hurt any... Assuming of course, only the one machine is comprimised.

[SD]Amon · Post by **[SD]Amon** » Sat Jun 19, 2004 6:09 am

a simple solution (unless your useing a windrop....)
chmod
unless root is trying to access your files, dont worry. you haveto tick someone off alot if they hack a machine, make themselves root, and all they do is look for your bot passwords and settings. Its safe just to restrict access to the file to you.

j0n · Post by **j0n** » Sat Jun 19, 2004 10:18 pm

Public encryption will only keep your files secure from "good guys".
Your brother decides to log into your shell and play with the files, but because he is an idiot he won`t know know how to decrypt.

This is the same concept of those 3rd party firewall software, it only blocks out people with no knowledge.

If someone really wanted to, they could decrypt your files regardless.

Alchera · Post by **Alchera** » Sun Jun 20, 2004 7:05 pm

[SD]Amon:

a simple solution (unless your useing a windrop....)
chmod

ppslim:

4: Bingo, they should have the information needed to further the quest.

Once again ppslim has hit the nail on head.