2088 posts
Location
South Africa
Posted 15 April 2013 - 02:01 AM
Hey guys?
I have a question about creating files which are unreadable to humans, but not code.
I need to create a file for a user with their details into a folder, but I need that file to be unreadable to humans and not java.
Is this possible in any way?
I have seen some files that have some weird characters like blocks, which is so you can't read what's inside it. But how can I do this?
I'm wanting to do this in Java for saving details of a user.
I'm busy googling now, If i find anything I'll post it here
7508 posts
Location
Australia
Posted 15 April 2013 - 02:04 AM
Binary files.
The 'weird character like blocks' are the program attempting to read and display the binary file in text mode, good programs that can read binary files will show it as a hex dump.
2088 posts
Location
South Africa
Posted 15 April 2013 - 02:59 AM
Binary files.
The 'weird character like blocks' are the program attempting to read and display the binary file in text mode, good programs that can read binary files will show it as a hex dump.
Ah, that's what it is.
Hmm, will this work because this is what it's going to do:
It will save the password into the file but the program needs to read the binary to use it to connect to server.
Can it go from binary to normal text?
7508 posts
Location
Australia
Posted 15 April 2013 - 03:27 AM
Its all about encoding, since if you just converted the ASCII to binary it is readable by programs (since files ARE binary)… so you would make your own encoding scheme… however if it's a password why wouldn't you just use hashes stored in an encrypted file?
2217 posts
Location
3232235883
Posted 15 April 2013 - 04:14 AM
just do a bit shift or more preferably XOR it with a key reducing the chance of the user recovering it
7508 posts
Location
Australia
Posted 15 April 2013 - 04:24 AM
bit shift looses data, you don't want to be loosing part of a password. an XOR is very easy to reverse, something you don't want on a password. And Java has built in encryption ability, why not just use it?
2217 posts
Location
3232235883
Posted 15 April 2013 - 04:37 AM
bit shift looses data, you don't want to be loosing part of a password. an XOR is very easy to reverse, something you don't want on a password. And Java has built in encryption ability, why not just use it?
:|
bit shift dosent loose data, you just wrap the bits
XOR isnt easy to reverse, you will have to know the string you XORed it with
the purpose is to make it unreadable by human, not encrypt it
7508 posts
Location
Australia
Posted 15 April 2013 - 04:50 AM
bit shift dosent loose data, you just wrap the bits
If you have 10011101 and do a left bitshift it becomes 00111010 that is a lost bit. The default Java operator does not wrap the bits, you would have to write your own.
2088 posts
Location
South Africa
Posted 15 April 2013 - 06:42 AM
Its all about encoding, since if you just converted the ASCII to binary it is readable by programs (since files ARE binary)… so you would make your own encoding scheme… however if it's a password why wouldn't you just use hashes stored in an encrypted file?
There won't be a password in the file, just an example.
The file would also have custom settings for the user which I would prefer not to be tampered with, although if the file turns out corrupt I could reset the file but I wouldn't want this to happen.
I have a program, TopazChat, that connects to online Warcraft III servers which saves the users' data inside a file. But these files cannot be opened or even SEEN.
You can only see the files when you do ctrl+o, to open a file of settings, within the program. Going to the location of where they are shows up blank.
I can't figure that out xD
Should have mentioned that it needs to be read over and over, so encryption is a no-no?
453 posts
Location
Holland
Posted 15 April 2013 - 07:17 AM
you could hash the password, then save it and later do a check like
if hash(input) == password then
end
1214 posts
Location
The Sammich Kingdom
Posted 15 April 2013 - 07:30 AM
you could hash the password, then save it and later do a check like
if hash(input) == password then
end
He just stated he wouldn't be storing passwords.
2088 posts
Location
South Africa
Posted 15 April 2013 - 09:26 AM
you could hash the password, then save it and later do a check like
if hash(input) == password then
end
Not lua, java! :P/>
you could hash the password, then save it and later do a check like
if hash(input) == password then
end
He just stated he wouldn't be storing passwords.
Well if I can't find any way to do what I want. I'll just hash the password and leave everything else is.
Then on startup, detect if the file has been changed or corrupt and then reset the file.
How's the design going btw? :P/>
1522 posts
Location
The Netherlands
Posted 15 April 2013 - 12:03 PM
Why not just shift a letter 3 to the right in the alphabet? For example, if you have r will be u, and x = b. Its the most simple solution, and can be easily be tracked back. Its not really encryption since its very easy to get the original back.
Its unreadable, and easy to get back at.
Another solution will be:
You have an array of 26 ints, those random ints represent the letter and since you compile it no one will ever now…. If they dont know how to decompile it though…
2088 posts
Location
South Africa
Posted 16 April 2013 - 02:59 AM
What about z? :P/>
Hmm, I don't know. Might use your solution 2, sounds reasonable because only the program will have the array.
2217 posts
Location
3232235883
Posted 16 April 2013 - 05:13 AM
bit shift dosent loose data, you just wrap the bits
If you have 10011101 and do a left bitshift it becomes 00111010 that is a lost bit. The default Java operator does not wrap the bits, you would have to write your own.
thats why i said you had to wrap the bits, and thats not how shifting works, only a right shift will loose data because the first number is on the right
10011101 shifted right will turn into 100110
148 posts
Posted 16 April 2013 - 10:36 AM
If you want to save code you could also remove the spaces and eol characters. If the program is long enough it'll be really painful to read…
2217 posts
Location
3232235883
Posted 16 April 2013 - 04:01 PM
If you want to save code you could also remove the spaces and eol characters. If the program is long enough it'll be really painful to read…
newlines (eol) are whitespace characters
7508 posts
Location
Australia
Posted 16 April 2013 - 04:22 PM
thats why i said you had to wrap the bits, and thats not how shifting works, only a right shift will loose data because the first number is on the right
10011101 shifted right will turn into 100110
In Computer Logics and Essentials at university thats how we were taught that bit shifting worked. That the left or right bit was removed and a 0 was added on the opposite side. Mind you though, the lecturer was a little stupid, so it wouldn't surprise me if she got it wrong.