Tremulous Forum
Mods => Mod Releases => Tools and Utilities => Topic started by: Foe of Eternity on March 25, 2011, 04:40:54 am
-
Hey everyone, made a little remote control utility for trem
put in the server, port, and rcon password and you will be able to execute commands and view the results in the console
So here it is:
http://www.mediafire.com/?nq7cym0pmosp62x (http://www.mediafire.com/?nq7cym0pmosp62x)
Enjoy
and as always post any bugs you encounter
-
Uhh, perhaps you should post the source for such a thing; or else you're expecting someone to put the keys to their servers into a program that may darn well be sending all the logins to you.
-
i'd rather not reveal the password encryption method...but here's the code for sending/receiving rcon commands:
string Add;
bool ready = false;
UdpClient cli = new UdpClient();
private void btnSend_Click(object sender, EventArgs e)
{
btnSend.Enabled = false;
try
{
cli = new UdpClient(txtServer.Text, int.Parse(txtPort.Text));
}
catch (Exception ee)
{
MessageBox.Show("Error\n" + ee.ToString());
}
string test = "rcon " + txtPass.Text + " " +txtCmd.Text;
List<byte> bytes = new List<byte>();
for( int i = 0; i < 4; i++ )
bytes.Add((byte)255);
foreach (char c in test)
bytes.Add((byte)c);
byte[] send = new byte[bytes.Count];
for (int i = 0; i < bytes.Count; i++)
send[i] = bytes[i];
cli.Send(send, send.Length);
txtConsole.Text += "]" + txtCmd.Text;
cli.BeginReceive(new AsyncCallback(GetPackets), cli);
ready = false;
while (!ready)
Application.DoEvents();
txtConsole.Text += Add;
txtConsole.SelectionStart = txtConsole.Text.Length;
txtConsole.SelectionLength = 0;
txtConsole.ScrollToCaret();
txtCmd.Text = "";
for (int i = 0; i < 7; i++)
{
Application.DoEvents();
Thread.Sleep(100);
}
btnSend.Enabled = true;
}
private void GetPackets(IAsyncResult iar)
{
Add = "";
try
{
IPEndPoint address = new IPEndPoint(IPAddress.Any, int.Parse(txtPort.Text));
Byte[] receiveBytes = new Byte[0];
for( int i = 0; i < 1; i++ )
receiveBytes = cli.EndReceive(iar, ref address);
Add = Encoding.ASCII.GetString(receiveBytes);
Add = Add.Remove(0, 9);
ready = true;
}
catch (Exception ee)
{
Add = ee.ToString();
ready = true;
}
}Language is C#
(i know it's not optimized but it doesn't slow it down too much)
i know for a fact it only sends data to the server you tell it to, if you feel more comfortable, you can check the connections it opens
(double checked with WPE)
-
Uhh, perhaps you should post the source for such a thing; or else you're expecting someone to put the keys to their servers into a program that may darn well be sending all the logins to you.
Hey, at least it's not obfuscated to buggery like the last .net project he posted ::)
Seriously, what's so precious about your apps that makes it impossible for you to release the source?
-
The project last time was for stability testing and I released a clean version
As for this project, I released all the code that mattered...I added in encryption when it saves the rcon pass to prevent privacy issues and would rather it not be released so I can reuse it
-
Unless you post a full source that someone can both inspect and compile themselves, they cannot be safe, because without compiling it themselves they cannot know that the binary posted is actually from the source provided.
It was already a bad idea for people to run server browsers that are closed like this, but for something that handles sensitive login information, it is an extremely bad idea.
-
As I said before I released all the code that mattered (it's enough information to compile it yourself)
However when I get the chance I'll release the source without encryption
But a packet capture utility (such as WPE is enough because it's clear that the only packet sent is to the server you specify with the data you gave it
You would need to worry more about people on your network sniffing the password than the program itself because you can test the program...
-
Not quite, malicous code can be much more clever than that. One way to do it is to keep a list of rcon passwords and servers (one could probably even store it in the executable itself if one so desired), and send them monthly/weekly. Password encryption would be a sensible place to put such malicious code.
I'm sorry you are not getting more support for these tools but this is an open source community, so I hope you understand our skepticism of closed-source code.
-
As I said before I released all the code that mattered (it's enough information to compile it yourself)
-
How did you manage to make a program in C# thats actually USEFUL???
-
How did you manage to make a program in C# thats actually USEFUL???
There are loads of useful apps coded in C#(f-spot, banshee, tomboy, etc), yes it adds annoying overheads, but it isn't just another visual basic.
-
you want us to run a blackbox c# app w/o showing src
nothx
-
I guess you need to take the encryption out, then, and release it as open source.
-
i'd rather not reveal the password encryption method...
Security through obscurity is no security at all.
-
i'd rather not reveal the password encryption method...
Security through obscurity is no security at all.
i didn't finish the quote but i don't want to release it so i can reuse it...i'm not using security through obscurity
you want us to run a blackbox c# app w/o showing src
nothx
how many times do i need to say i released enough of the source to remake it...i've already made 3 posts repeating this but i'll do it again just for you
As I said before I released all the code that mattered (it's enough information to compile it yourself)
and besides, if you have the source, there's no way to verify that the source that's released is the program that was released...but seriously there's no point in making a malicious program, the tremulous community (and this board specifically isn't very active) isn't exactly large-scale...and hiding the source would raise suspicion, if it was a malicious program a fake source would probably be released as i said earlier
anyway, i'll be releasing the source without the encryption, i was just away for the weekend and didn't have time to release it
-
As I said before I released all the code that mattered (it's enough information to compile it yourself)
and besides, if you have the source, there's no way to verify that the source that's released is the program that was released...
If you release the source, then we could compile it ourselves. That takes your pre-compiled program out of the loop.
-
As author, you are the copyright holder and can use it any way you want, no matter what license you release the source under (which is how MySQL has proprietary and free software (http://www.gnu.org/philosophy/free-sw.html) versions, for example).
So now we've established that obscurity isn't more secure and you can reuse it how you wish, you have no excuse, unless it is malicious ;)
If you care about incorporating community changes into proprietary products you create, I recommend using the Apache 2.0 License (https://secure.wikimedia.org/wikipedia/en/wiki/Apache_License) (as used by Google and Apache) but the Modified BSD (https://secure.wikimedia.org/wikipedia/en/wiki/BSD_license#3-clause_license_.28.22New_BSD_License.22_or_.22Modified_BSD_License.22.29), Simplified BSD (https://secure.wikimedia.org/wikipedia/en/wiki/BSD_license#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29) and zlib (https://secure.wikimedia.org/wikipedia/en/wiki/zlib_license) licenses would all do roughly the same job.
-
how many times do i have to repeat myself
YOU CAN COMPILE THE SOURCE
i gave you enough code that if you knew how to open a C# editor you could compile it
i will not release the full source, no matter how you argue it, so stop trying to convince me there's 'no reason not to release the full source'
i released this for the benefit of the community
if you're so desperate to find the whole source then take the time to decompile it
and seriously, stop posting about how "it could be malicious"
if you think it's malicious, by all means don't download it, as that is a good security practice
-
So, moving away from the topic of full source disclosure, what's the point in this utility, i don't run a server, what would you otherwise use for rcon, how does this app improve on the standard method?
-
It means you can put it on a netbook or phone that lacks openGL. This is not the only way to do so (ssh and screen can also do this), but is one way to do so.
However, you cannot cannot compile the source. Not as given. Sure, it would be easier to figure out what needs done than to write the whole thing myself, but I'd have to re-create your UI, and then try to understand what exactly it is that your code needs done before it can work. Its not working code. There is no reason not to release the rest of the working code (minus the encryption).
What I think we are saying here is that your code is dead until we don't have to care about it to get it to run (compiles without effort).
-
i released this for the benefit of the community
considering it's an open source community with quite a few people running on linux distros, surely you understand the distaste most of us have for closed source software.
it is more than possible to have decent encryption with open source software.
-
i gave you enough code that if you knew how to open a C# editor you could compile it
How are we supposed to know if the code you gave us is even in the program?
if you think it's malicious, by all means don't download it, as that is a good security practice
We all think it's malicious. You're not very good at advertising your product.
-
It means you can put it on a netbook or phone that lacks openGL. This is not the only way to do so (ssh and screen can also do this), but is one way to do so.
ssh and screen sounds good to me.
-
So, moving away from the topic of full source disclosure, what's the point in this utility, i don't run a server, what would you otherwise use for rcon, how does this app improve on the standard method?
it's designed for server owners to be able to use rcon without having to open trem with it, so it's useless if you don't own a server/don't have rcon on it
i released this for the benefit of the community
considering it's an open source community with quite a few people running on linux distros, surely you understand the distaste most of us have for closed source software.
it is more than possible to have decent encryption with open source software.
the encryption is just a rijndael cipher, i don't want to release how i encrypted it, not the encryption, so that people can't recreate the password and use it to decrypt the encrypted data
and yes i understand the distaste of closed source software as i use linux too, but the only thing you need to recreate is the gui, all the names and such are pretty self explanatory
string Add;
bool ready = false;
UdpClient cli = new UdpClient();
private void btnSend_Click(object sender, EventArgs e)
{
btnSend.Enabled = false;
try
{
cli = new UdpClient(txtServer.Text, int.Parse(txtPort.Text));
}
catch (Exception ee)
{
MessageBox.Show("Error\n" + ee.ToString());
}
string test = "rcon " + txtPass.Text + " " +txtCmd.Text;
List<byte> bytes = new List<byte>();
for( int i = 0; i < 4; i++ )
bytes.Add((byte)255);
foreach (char c in test)
bytes.Add((byte)c);
byte[] send = new byte[bytes.Count];
for (int i = 0; i < bytes.Count; i++)
send[i] = bytes[i];
cli.Send(send, send.Length);
txtConsole.Text += "]" + txtCmd.Text;
cli.BeginReceive(new AsyncCallback(GetPackets), cli);
ready = false;
while (!ready)
Application.DoEvents();
txtConsole.Text += Add;
txtConsole.SelectionStart = txtConsole.Text.Length;
txtConsole.SelectionLength = 0;
txtConsole.ScrollToCaret();
txtCmd.Text = "";
for (int i = 0; i < 7; i++)
{
Application.DoEvents();
Thread.Sleep(100);
}
btnSend.Enabled = true;
}
private void GetPackets(IAsyncResult iar)
{
Add = "";
try
{
IPEndPoint address = new IPEndPoint(IPAddress.Any, int.Parse([quote author=kharnov link=topic=15440.msg220325#msg220325 date=1301287581]
[quote author=Foe of Eternity link=topic=15440.msg220306#msg220306 date=1301279453]
i gave you enough code that if you knew how to open a C# editor you could compile it
[/quote]
How are we supposed to know if the code you gave us is even in the program?
[quote author=Foe of Eternity link=topic=15440.msg220306#msg220306 date=1301279453]
if you think it's malicious, by all means don't download it, as that is a good security practice
[/quote]
We all think it's malicious. You're not very good at advertising your product.
[/quote]Port.Text));
Byte[] receiveBytes = new Byte[0];
for( int i = 0; i < 1; i++ )
receiveBytes = cli.EndReceive(iar, ref address);
Add = Encoding.ASCII.GetString(receiveBytes);
Add = Add.Remove(0, 9);
ready = true;
}
catch (Exception ee)
{
Add = ee.ToString();
ready = true;
}
}txtConsole - a textbox representing the console
txtCmd - a textbox representing the entered command
btnSend - a button that when clicked runs btnSend_Click
txtPort - a textbox representing the server port
txtPass - a textbox representing the password
txtServer - a textbox representing the server address
as i said, everything is self explanatory; i would've expected anyone who wanted the source to be able to figure this out...
i gave you enough code that if you knew how to open a C# editor you could compile it
How are we supposed to know if the code you gave us is even in the program?
if you think it's malicious, by all means don't download it, as that is a good security practice
We all think it's malicious. You're not very good at advertising your product.
how are we supposed to know the tremulous executable contains what the source says it does?
you can't.
i gave you enough information to make it yourself if you don't trust it
also, in case you didn't notice, IT'S FREE
it's not a product, i don't care if no one downloads it, as i said i was releasing it for the benefit of the community, if they don't want to use it, it doesn't matter to me
READ THIS POST BEFORE POSTING AGAIN (and the following message)
-
So, moving away from the topic of full source disclosure, what's the point in this utility, i don't run a server, what would you otherwise use for rcon, how does this app improve on the standard method?
it's designed for server owners to be able to use rcon without having to open trem with it, so it's useless if you don't own a server/don't have rcon on it
Sorry, i think i confused you, i was inquiring what one would use for rcon if they didn't have access to your app, trem itself or ssh and screen were the answers.
also, in case you didn't notice, IT'S FREE
it's not a product, i don't care if no one downloads it, as i said i was releasing it for the benefit of the community, if they don't want to use it, it doesn't matter to me
READ THIS POST BEFORE POSTING AGAIN (and the following message)
Surely rcon passwords are rather sensitive pieces of information, not the kind of thing anyone wants to feed into some random guy's app, and if someone's capable of building their own clean version from your source they're probably also capable of figuring out ssh.
If you don't care that no one uses it, that's fine, i personally would care, if i'd bothered to write the program and felt that it was worth the effort, i'd want to provide source that builds and runs on multiple platforms. Have you considered starting a sourceforge or google code account and turning your trem tools into a real project? I imagine people are quite happy to type their rcon password when it's needed, if you just want to strip out the password saving and hashing code i'm sure people wouldn't mind. If you do choose this route, good luck.
You really must appreciate that you're some guy, posting binaries on mediafire for an app that accepts peoples server addresses and rcon passwords as input, anyone would have to be pretty braindead to take that risk.
-
i will not release the full source, no matter how you argue it, so stop trying to convince me there's 'no reason not to release the full source'
You
- dumped a binary on the community
- did not give us reasons which withstand examination for keeping the code proprietary
- released code we can't use since it isn't under a free license
- became completely irrational like the above
How would you react to such a guy's program?
Your reasons examined...
i'd rather not reveal the password encryption method...
Security through obscurity is no security at all.
i didn't finish the quote but i don't want to release it so i can reuse it...i'm not using security through obscurity
the encryption is just a rijndael cipher, i don't want to release how i encrypted it, not the encryption, so that people can't recreate the password and use it to decrypt the encrypted data
Fail. So this reason doesn't make sense.
would rather it not be released so I can reuse it
As author, you are the copyright holder and can use it any way you want
And your only remaining reason doesn't make sense.
Assuming the app is proprietary because it's malicious is currently the only option available to us.
Now you hopefully understand why your program hasn't been accepted by the community.
-
This is not the only way to do so (ssh and screen can also do this), but is one way to do so.
That's obviously the most secure method: disable rcon entirely and send commands over an encrypted connection to the server.
echo -e '\xff\xff\xff\xffrcon [rconPassword] [cmd]' | nc -uw1 [addr] [port]e.g.,echo -e '\xff\xff\xff\xffrcon blah cp You all suck' | nc -uw1 127.0.0.1 30720As for this "Rcon Utility", I have no idea where/why encryption would be used anyway, since rcon does not use encryption.
i didn't finish the quote but i don't want to release it so i can reuse it...i'm not using security through obscurity
I don't know how/why you're using encryption, but I think you need to look up the meanings of the word security.
-
i will not release the full source, no matter how you argue it, so stop trying to convince me there's 'no reason not to release the full source'
You
- dumped a binary on the community
- did not give us reasons which withstand examination for keeping the code proprietary
- released code we can't use since it isn't under a free license
- became completely irrational like the above
How would you react to such a guy's program?
Your reasons examined...
i'd rather not reveal the password encryption method...
Security through obscurity is no security at all.
i didn't finish the quote but i don't want to release it so i can reuse it...i'm not using security through obscurity
the encryption is just a rijndael cipher, i don't want to release how i encrypted it, not the encryption, so that people can't recreate the password and use it to decrypt the encrypted data
Fail. So this reason doesn't make sense.
would rather it not be released so I can reuse it
As author, you are the copyright holder and can use it any way you want
And your only remaining reason doesn't make sense.
Assuming the app is proprietary because it's malicious is currently the only option available to us.
Now you hopefully understand why your program hasn't been accepted by the community.
So, moving away from the topic of full source disclosure, what's the point in this utility, i don't run a server, what would you otherwise use for rcon, how does this app improve on the standard method?
it's designed for server owners to be able to use rcon without having to open trem with it, so it's useless if you don't own a server/don't have rcon on it
Sorry, i think i confused you, i was inquiring what one would use for rcon if they didn't have access to your app, trem itself or ssh and screen were the answers.
also, in case you didn't notice, IT'S FREE
it's not a product, i don't care if no one downloads it, as i said i was releasing it for the benefit of the community, if they don't want to use it, it doesn't matter to me
READ THIS POST BEFORE POSTING AGAIN (and the following message)
Surely rcon passwords are rather sensitive pieces of information, not the kind of thing anyone wants to feed into some random guy's app, and if someone's capable of building their own clean version from your source they're probably also capable of figuring out ssh.
If you don't care that no one uses it, that's fine, i personally would care, if i'd bothered to write the program and felt that it was worth the effort, i'd want to provide source that builds and runs on multiple platforms. Have you considered starting a sourceforge or google code account and turning your trem tools into a real project? I imagine people are quite happy to type their rcon password when it's needed, if you just want to strip out the password saving and hashing code i'm sure people wouldn't mind. If you do choose this route, good luck.
You really must appreciate that you're some guy, posting binaries on mediafire for an app that accepts peoples server addresses and rcon passwords as input, anyone would have to be pretty braindead to take that risk.
ok i'll be even more specific for you
i made it for me and released it here
for the benefit of the community
there's no reason for me to create all of that just so people can feel secure, they can make it themselves if they want to (it really isn't that hard, took maybe 10 minutes to make), i just thought people would be lazy (as they generally are) and want someone to do it for them
and the only reason it's on mediafire is so i can get it from other computers without having to find this topic to download it
you're acting like rconpasswords is like putting a backdoor into your computer, there is nothing you can do with rcon that is permanent or difficult to fix
and read that quote that "makes no sense" again... the encryption is the algorithm used to protect data, how i encrypted it includes password generation and such
and tbh idc what you do with the code
This is not the only way to do so (ssh and screen can also do this), but is one way to do so.
That's obviously the most secure method: disable rcon entirely and send commands over an encrypted connection to the server.
echo -e '\xff\xff\xff\xffrcon [rconPassword] [cmd]' | nc -uw1 [addr] [port]e.g.,echo -e '\xff\xff\xff\xffrcon blah cp You all suck' | nc -uw1 127.0.0.1 30720As for this "Rcon Utility", I have no idea where/why encryption would be used anyway, since rcon does not use encryption.
i didn't finish the quote but i don't want to release it so i can reuse it...i'm not using security through obscurity
I don't know how/why you're using encryption, but I think you need to look up the meanings of the word security.
disabling rcon entirely is a lot more secure, yes, but ssh isn't handled by the program (and by everyone's insecurity, wouldn't want it to anyway)
as for encryption, it saves the password on the computer (if you tell it to) and saves the encrypted password
-
and read that quote that "makes no sense" again... the encryption is the algorithm used to protect data, how i encrypted it includes password generation and such
So you're relying on people not knowing how you encrypted the password, which is exactly what security through obscurity is. You were saying...
i'm not using security through obscurity
So, as I said, you're not making sense.
-
and read that quote that "makes no sense" again... the encryption is the algorithm used to protect data, how i encrypted it includes password generation and such
So you're relying on people not knowing how you encrypted the password, which is exactly what security through obscurity is. You were saying...
i'm not using security through obscurity
So, as I said, you're not making sense.
actually no, the "security" would be the rijndael cypher (as i said before)
the password is just what's used to decrypt it, you don't tell people the passwords you make do you?
so you're saying that everyone who has ever made a password uses security through obscurity which undeference claims is no security at all
if passwords are no security then why do they still exist?
by definition, security through obscurity is using secrecy in implementation/design to have security
as the only thing i'm hiding is the password, it is not security through obscurity
-
- Mention of security through obscurity was before you disclosed your "security" measures
- Your program's purported security may give some users a false sense of security
- Just cut out the cryptographic code, which adds nothing to your program anyway, and recompile and redistribute it with the full source code and [most] people will stop complaining
Or don't
-
Ohhh, you aren't talking about a proprietary algorithm. You mean the secret key?
If you're talking about using a secret key you put in the binary, I believe it can be retrieved.
-
Ohhh, you aren't talking about a proprietary algorithm. You mean the secret key?
If you're talking about using a secret key you put in the binary, I believe it can be retrieved.
This is why its security through obscurity. Given an untrusted client, who, as you've said yourself, is free to decompile the binary, the "password" can be discovered by mere inspection.
I still don't understand though:
As for this "Rcon Utility", I have no idea where/why encryption would be used anyway, since rcon does not use encryption.
So wtf does the encryption exist in the first place?
-
I never dreamed of the day I'd see someone troll a forum with software.
-
So wtf does the encryption exist in the first place?
He's encrypting the saved keys on disk, we've covered this.
-
I never dreamed of the day I'd see someone troll a forum with software.
;)
well it didn't start like that but it turned into that (sorta)
continuing on...there's no password hidden in the binary, you can look yourself
and thank you tremulant, you see why i get frustrated >.>
-
Where does the program get the secret key from?
(keeping in mind that if it is stored as a variable, it is stored as plain text in the binary)
-
it doesn't store it as a variable either
but why would i tell you how i generate the password...kinda defeats the purpose of the password don't you think?
so yes, it is proprietary
-
The method can still be discovered by decompiling.
And your security relies on hiding the details of the secret key generation -- security through obscurity at work.
-
no, security through obscurity would be hiding everything about saving the password, hiding the password generator makes it a proprietary algorithm
security through obscurity implies that there's holes in the security that the owner won't acknowledge as a hole and hides it so they feel safe because they think people won't figure it out
proprietary algorithms are algorithms used to generate a result that have been hidden to prevent misuse
-
security through obscurity implies that there's holes in the security that the owner won't acknowledge as a hole and hides it so they feel safe because they think people won't figure it out
Explain to me how this definition does not apply here. :P
You won't acknowledge there's a hole in your software, you're hiding the details because it makes you feel safe and you think people won't figure it out. Perfect match.
I (and others) maintain, this is still security through obscurity.
Security through (or by) obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security.
-
the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source
-
the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source
Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.
-
the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source
Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.
i don't think you understand what security through obscurity is, security through obscurity is not releasing the source to prevent security holes
i'm not releasing the source so people can't [Edit]recreate the password without difficulty[/Edit], which as i said earlier, is a proprietary algorithm
they're completely different things; i'm not using security through obscurity
-
Your program's design has this flaw regardless of whether or not it is open source.
And you are failing to understand what security through obscurity is, not everyone else.
-
and what might that flaw be?
that it has a generated password?
what about other programs with generated passwords?
are they all using security through obscurity too?
what you fail to see is the reasoning behind why i'm hiding it, there's no need for me to repeat myself like i did earlier
-
i'm not releasing the source so people can't crack the password
i'm not using security through obscurity
-
the reason why it doesn't apply here is because it's hidden to prevent misuse, not because there's a bug in it
your definition of security through obscurity is too obscure, by your definition, security doesn't exist, and that every type of security is security through obscurity unless it's open source
Since you need to be able to reverse the encryption in order to send the plain text password to the server i don't suppose you'd be able to hope for anything more than security through obscurity, and that's exactly what you've got, stop trying to pretend otherwise.
i don't think you understand what security through obscurity is, security through obscurity is not releasing the source to prevent security holes
i'm not releasing the source so people can't crack the password, which as i said earlier, is a proprietary algorithm
they're completely different things; i'm not using security through obscurity
It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.
If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information, such as the exact time the user generated the password, then the password itself could be considered secure (well, to a point, passwords really should be generated by an absolutely safe algorithm, or not generated at all), while the password generation algorithm itself is merely is security by obscurity.
-
as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.
Your argument is invalidated because you failed to not only read, but understand.
I will explain the purpose of the encryption again so you understand why it is there
The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text
The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people. You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure. Not only is this false, but impractical. The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password.
As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity
-
Your "given requirements" are that the data be encrypted and decrypted without user interaction which has a security vulnerability inherent in the design because such requirements rely on data which is all available on the machine (even in an obscured form), unlike passwords.
-
Your argument is invalidated because you failed to not only read, but understand.
I will explain the purpose of the encryption again so you understand why it is there
Look, f50 is clearly a bit slow, just ignore him, it doesn't stop your system incorporating security through obscurity, your reversible password encryption method is secret, if it weren't secret(and you can't assume it'll stay secret) it'd be really easy to reverse the encryption on saved passwords.
-
it's not secret at all, i already told u i was using a rijndael cypher
and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it
all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is
as i said before, the only security is trust
-
the encryption only prevents other people from accidentally finding it and realizing what it is
Lol. You might as well do rot13 on the rcon password given that the above is the only reason you're using encryption. And for either method, the only protection is against people noticing a password like "ThisIsRconForMyServer".
-
if u knew me you'd know i overdo stuff ^^
i incorporate overcomplicated stuff in simple stuff for practice ;)
-
as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.
The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text
I do understand that the encryption is not being used between the program and the tremulous server, but it is still possible to use other secure and random approaches, as is done with ssh keys. Many ssh keys are stored are encrypted on the machine, in a similar, but actually secure, way. However,
If the plain text file on your computer is not considered secure enough, then the natural assumption is to evaluate the problem as if Eve has access to the file, is it not? It is also given that everyone (and thus Eve), has access to your binary.
Now, let me duplicate my previous post for you:
It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.
If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information,
I'll stop there, because it doesn't. Its security by obscurity because everything necessary to decrypt the rcon password has already been published in the forum of the binary.
To continue
The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people. You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure. Not only is this false, but impractical. The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity
Yes, I can, because you already have revealed the method of password generation in your binary, and that knowledge is *all* that is necessary to recreate the rcon. You need to use information that is truly secret (and not just published in assembler, tremulant) to encrypt and decrypt your information here. SSH has done this.
I would stress that all of the methods, as well as the source code for ssh is public. Only the passwords are private. Your algorithm is insecure because the source code for your own cypher is readily available to any hacker that cares to go through the assembly, whereas ssh is not insecure, because the source code (available in hard-to-read assembly as well as some implementations in C) does not need to be secret, only the passwords (at least one of which must not be available on any computer to be secure).
-
(and not just published in assembler, tremulant)
Hello?
-
as i stated earlier, the password generated is used for saving the password on the hard drive, so not only is there no way to generate a completely random password with the given requirements, but there's no point in putting that much into it: it's only for encrypting and decrypting the password on YOUR COMPUTER
It is not available to everyone on the internet, which is how you are treating it.
The encryption, despite what you believe, is not there to encrypt the packets or any information leaving your computer, rather just to provide extra protection: I'm sure you wouldn't want the program to store the password in plain text
I do understand that the encryption is not being used between the program and the tremulous server, but it is still possible to use other secure and random approaches, as is done with ssh keys. Many ssh keys are stored are encrypted on the machine, in a similar, but actually secure, way. However,
If the plain text file on your computer is not considered secure enough, then the natural assumption is to evaluate the problem as if Eve has access to the file, is it not? It is also given that everyone (and thus Eve), has access to your binary.
Now, let me duplicate my previous post for you:
It is almost guaranteed to be a tractable problem to decompile the binary and figure out the password algorithm. Keep in mind that the client here is untrusted, as far as figuring out the algorithm goes. There is no security here, only the potential difficulty of understanding the x86 assembly, as opposed to plain C#.
If reading the source code could allow people to crack the password, then that is security by obscurity. If it would also require other, unknowable information,
I'll stop there, because it doesn't. Its security by obscurity because everything necessary to decrypt the rcon password has already been published in the forum of the binary.
To continue
The only security [that exists] is trust. No matter how many fancy algorithms you create, they can all be cracked; the only place that security comes in is other people. You trust other people to not give away information.
Despite all your arguments, all of you were talking about how the program is 'insecure' because it generates a password, and that doing something else would make it secure. Not only is this false, but impractical. The password has to be able to be recreated otherwise it wouldn't be possible to be decrypted. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. I am not using security through obscurity quite simply because i am not trying to hide the source so people can't find holes in the security, but I'm doing to make it difficult to recreate the password. As this is true with any type of security, you cannot generalize my unwillingness to reveal the method of password generation to security through obscurity without generalizing every other type of security to be security through obscurity
Yes, I can, because you already have revealed the method of password generation in your binary, and that knowledge is *all* that is necessary to recreate the rcon. You need to use information that is truly secret (and not just published in assembler, tremulant) to encrypt and decrypt your information here. SSH has done this.
I would stress that all of the methods, as well as the source code for ssh is public. Only the passwords are private. Your algorithm is insecure because the source code for your own cypher is readily available to any hacker that cares to go through the assembly, whereas ssh is not insecure, because the source code (available in hard-to-read assembly as well as some implementations in C) does not need to be secret, only the passwords (at least one of which must not be available on any computer to be secure).
Look, f50 is clearly a bit slow, just ignore him, it doesn't stop your system incorporating security through obscurity, your reversible password encryption method is secret, if it weren't secret(and you can't assume it'll stay secret) it'd be really easy to reverse the encryption on saved passwords.
let me quote my other post:
it's not secret at all, i already told u i was using a rijndael cypher
and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it
all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is
as i said before, the only security is trust
SSH is secure because the password is stored on the server
not only is your argument completely invalidated once again, but once again, you failed to understand how the program works
Here's what i said, ONCE AGAIN:
it's not secret at all, i already told u i was using a rijndael cypher
and also it's only used on your computer, the only way someone else could get the encrypted data is by 1 of 3 ways:
1) The owner found and gave it to them
2) They hacked the computer, found and downloaded
3) They got on the computer (with or without permission), found it, and copied it
all three of which the program has no control over, the security here is that no one will give out the password
the encryption only prevents other people from accidentally finding it and realizing what it is
as i said before, the only security is trust
SSH, by the way you're looking at my program, is even less secure than my program.
With ssh, you can recreate the session by capturing the keys and spoofing data as it's sent to the client, and not only that, but you can bruteforce ssh keys, all without permission from the owner.
My program doesn't use the internet at all for it's programs, so the only way anyone can get the password (with any method) is by getting it from the owner's computer
Please read before you post again.
-
ssh keys are asymmetric keys, i.e. they consist of the public and the private subkeys. The subkey on the server is the public subkey, which may be published openly without compromising the security of ssh at all. The private key (which you can consider the "password") is in fact stored on the client side.
Also you cannot get the secret keys by snooping the communication. The keys are never sent over the wire, so capturing them is simply not possible. Of course you can break the encryption by brute force, just like you can break Rijndael or every other cipher in existence, if you have the necessary resources...
as i said before, the only security is trust
Yes, but it is obviously easier to trust a program which I can check and compile myself with a trusted compiler than a random binary blob downloaded from the internet.
In the end this whole discussion leads nowhere. If you don't want to show the source code, that is your descision. And if someone else does or does not trust your program, it is his descision.
-
your reversible password encryption method is secret, if it weren't secret it'd be really easy to reverse the encryption on saved passwords.
The main problem being, its in the assembler, the method is not secret.
Please read before you post again.
Believe me, I've read that, but I believed you were more competent than your post seems to suggest. Are you asking me to apologize for having misunderstood? I assume of course that the post you've repeated twice is what you intended for me to read. It seems like you're saying that your encryption method is as good as plain-text, which shares all of the qualities given in that post. Having read the wikipedia article on the AES algorithm I am even more confused, as that seems clearly better than plain-text, provided that the key is not stored anywhere on that machine.
So then, your security is not meant to be security? I'm interested then in why its so important that this remain secret...
AFAIK, AES is not proprietary.
-
ssh keys are asymmetric keys, i.e. they consist of the public and the private subkeys. The subkey on the server is the public subkey, which may be published openly without compromising the security of ssh at all. The private key (which you can consider the "password") is in fact stored on the client side.
Also you cannot get the secret keys by snooping the communication. The keys are never sent over the wire, so capturing them is simply not possible. Of course you can break the encryption by brute force, just like you can break Rijndael or every other cipher in existence, if you have the necessary resources...
as i said before, the only security is trust
Yes, but it is obviously easier to trust a program which I can check and compile myself with a trusted compiler than a random binary blob downloaded from the internet.
In the end this whole discussion leads nowhere. If you don't want to show the source code, that is your descision. And if someone else does or does not trust your program, it is his descision.
I was using the way he was comparing ssh to my code to show that his argument was invalid, i never said ssh was insecure, in fact it's very secure. Also note the spoofing part, it is possible to hack ssh over the packets sent/received, as i said recreate the session using captured keys (public) and a little bit of spoofing (private)
as for the password, i meant that the password can be accessed from the client remotely (not like receiving it, but more like bruteforce)
on the note of source...
do we have to discuss this over again?
you'll find the source is already posted
your reversible password encryption method is secret, if it weren't secret it'd be really easy to reverse the encryption on saved passwords.
The main problem being, its in the assembler, the method is not secret.
Please read before you post again.
Believe me, I've read that, but I believed you were more competent than your post seems to suggest. Are you asking me to apologize for having misunderstood? I assume of course that the post you've repeated twice is what you intended for me to read. It seems like you're saying that your encryption method is as good as plain-text, which shares all of the qualities given in that post. Having read the wikipedia article on the AES algorithm I am even more confused, as that seems clearly better than plain-text, provided that the key is not stored anywhere on that machine.
So then, your security is not meant to be security? I'm interested then in why its so important that this remain secret...
AFAIK, AES is not proprietary.
when did i ask for an apology?
i'm saying you weren't competent enough to read
once again with the not reading: i never said the rijndael cypher was the security, and the cypher is only for me (and to add a little privacy)
i even quoted what i said the security was and you STILL can't figure it out?
and on the note of AES not being proprietary, when did i say it was? i said the algorithm i use to generate the password is proprietary
SERIOUSLY LERN2READ
-
your reversible password encryption method is secret, if it weren't secret it'd be really easy to reverse the encryption on saved passwords.
The main problem being, its in the assembler, the method is not secret.
It's secret, relatively speaking. Have you actually reverse engineered the thing at this point?
So, in short, Foe of eternity is relying on the fact that the source for his encryption isn't available for security and f50 is easily confused and a sometimes louder than he is bright. We're all a bunch of bloody idiots and this topic is going nowhere, lock?
-
I'll admit it is relatively secret, but, as foe of eternity has pointed out, so is one's own machine. It is not secret in the cryptographical sense, as far as I understand it.
on the note of source...
do we have to discuss this over again?
you'll find the source is already posted
The source is not posted, it does not compile. Anyways its official, none of us can hear each other speak. ::)
once again with the not reading: i never said the rijndael cypher was the security, and the cypher is only for me (and to add a little privacy)
i even quoted what i said the security was and you STILL can't figure it out?
What is security but privacy of communication and storage of data? The thing that I still cannot figure out is how this adds any privacy beyond the systems protecting your own machine. If someone is skilled enough to handle that task, I would expect that person to be skilled enough to not be particularly challenged by this. However, it seems so close to a potentially working system, a system capable enough that it would not need to be obscured by a binary. But nevermind, there is no true communication here.
and on the note of AES not being proprietary, when did i say it was? i said the algorithm i use to generate the password is proprietary
Alas, it seems we are incapable of communicating the most basic ideas between each other. A bunch of bloody idiots we are indeed. I did not say that you said that AES was proprietary (ok, that sounds scarily circular). What I meant to say is that the means of generating the password, lets call it the "key" to distinguish from the rcon password, is...rather completely useless, when it seems that one could implement proper key generation . Also, if you re-read this thread (admittedly, a terrible exercise), there are at least three meanings we have put to the word "password"...
-
on the note of the source code, you have enough information to recreate the source even if it's not fully posted
and i agree with tremulant this should probably be locked
-
I love closed source utilities for open source applications.
-
fail troll is fail.