17 replies to this topic

[remiX]

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

[theoriginalbit]

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.

[remiX]

theoriginalbit, on 15 April 2013 - 01:04 AM, said:

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?

[theoriginalbit]

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?

[PixelToast]

just do a bit shift or more preferably XOR it with a key reducing the chance of the user recovering it

[theoriginalbit]

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?

[PixelToast]

theoriginalbit, on 15 April 2013 - 03:24 AM, said:

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

[theoriginalbit]

PixelToast, on 15 April 2013 - 03:37 AM, said:

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.

[remiX]

theoriginalbit, on 15 April 2013 - 02:27 AM, said:

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?

[wilcomega]

you could hash the password, then save it and later do a check like

if hash(input) == password then

end

[Sammich Lord]

wilcomega, on 15 April 2013 - 06:17 AM, said:

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.

[remiX]

wilcomega, on 15 April 2013 - 06:17 AM, said:

you could hash the password, then save it and later do a check like

if hash(input) == password then

end

Not lua, java!

Sammich Lord, on 15 April 2013 - 06:30 AM, said:

wilcomega, on 15 April 2013 - 06:17 AM, said:

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?

[Engineer]

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...

[remiX]

What about z?

Hmm, I don't know. Might use your solution 2, sounds reasonable because only the program will have the array.

[PixelToast]

theoriginalbit, on 15 April 2013 - 03:50 AM, said:

PixelToast, on 15 April 2013 - 03:37 AM, said:

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

[JokerRH]

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...

[PixelToast]

JokerRH, on 16 April 2013 - 09:36 AM, said:

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

[theoriginalbit]

PixelToast, on 16 April 2013 - 04:13 AM, said:

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.