Saving data after application exit

[Sam Bluesman]

Hi.

I know data can be saved to a text file when a java application is exited and can be retrievd again from this file when opened again. But, can data be saved into a different type of file so that it is not so easily accesable by the user?

Thanks

[Nicholas Jordan]

yes, just specifiy the file name in the constructor:

File filbert = new File("Internal.dat");// or whatever

and the file writes can be done with some more work and with a little bit of forward motion in your studies. The answer to your question is a definite yes - and it is usually done that way. Do you want to save the data in an internal format that prevents snooping ?



[ Message edited: here's another person working on the same problem ]
[ They are somewhat ahead of you: http://www.javaranch.com ]
[ September 23, 2007: Message edited by: Nicholas Jordan ]

[Stan James]

One caution on using ObjectStreams for this purpose. Many classes in the library warn you that a serialized version of this object may not be compatible with future versions of Java. That means if you compile with a newer JDK one day, you may not be able to read the files saved with the old version. You decide how big a risk that is to you.

[Nicholas Jordan]

Yes, it's like Stan says - almost every file I look into has the disclaimer:


... well, I went looking for it and did not find it but is states serial version id may not be compatible with future versions.

Okay, that makes sense, but this is really what you need to look at:

     * a b c d e f g h i j k l m n o p q r s t u v w x y z
'\u00DF' '\u00E0' '\u00E1' '\u00E2' '\u00E3' '\u00E4' '\u00E5' '\u00E6' 
'\u00E7' '\u00E8' '\u00E9' '\u00EA' '\u00EB' '\u00EC' '\u00ED' '\u00EE'
'\u00EF' '\u00F0' '\u00F1' '\u00F2' '\u00F3' '\u00F4' '\u00F5' '\u00F6'
'\u00F8' '\u00F9' '\u00FA' '\u00FB' '\u00FC' '\u00FD' '\u00FE' '\u00FF'

Don't try to do character conversions yourself, either work in your own internal format, or let the jvm write characters as the local platform understands them.

[Sam Bluesman]

Thanks for your help people. I shall research into your suggestions.

BTW Nicholas, yes it is snooping I definately DONT want.

SB
[ September 24, 2007: Message edited by: Sam Bluesman ]

[Nicholas Jordan]

[Sam Bluesman:]BTW Nicholas, yes it is snooping I defiantly DONT want.

Then you will have to look into the Java Cryptography Architecture.

Crypto is widely discussed and it is almost a collary of crypto that trying to do your own will result in weak protections. The average curiosity seeker can be defeated by just writing what you want as byte[], naming the file to extensions such as dot dat, which will be picked up by the music player if the shell is used to explore.

I got random byte[256] written to a file in the last few days, not to say that I know how to use that as a source of random bytes or keys or anything else: It has a great deal to do with how sophisticated your inquisitor is and how valuable your data is. See discussion I had recently with Pat Farrell in the advanced forum.

Note, I tried using file buffers that sounded like they were correct for what I wanted to do ~ all of them failed miserably. I went back to the basics, writing some code I could understand, and got some useable file writes done.

See my discussion of the issue at:

http://docdubya.com/belvedere/statement/index.html

It discusses the attack scenario, set to midi background music, in a manner that is brutal in it's dismissal of many first approaches to the problem.

Do not under-estimate your attacker.

[Nicholas Jordan]

package demo;
 
import java.io.*;// 
 
/*
 * Provides for system input and output through data 
 * streams, serialization and the file system.
 * 
 * To write data in manner that resists routine
 * curiosity seekers.
 */
 
 public class  AntiSnoop extends FileInputStream
 {
     // be sure to keep ++/-- and indexing the same in read/write
     byte[] byteBuffer;//
     int[]  dataReadBuffer;//
     static final int loopLimit = 512;//
     FileOutputStream dataSaver;//
     protected AntiSnoop(File lastSaved) throws FileNotFoundException
     {
        /* Creates a FileInputStream by opening a connection
         * to an actual file
         */
         super(lastSaved);
         byteBuffer = new byte[512];// or whatever size you want
         dataReadBuffer = new int[512];//
     }
     int read(int length) throws IOException
     {
         int bytesReadBySuperclass = 0x0000;//
         int position = 0x0000;//
         int index = 0x0000;//
         // fill buffer with nulls before passing to superclass
         do
         {
             byteBuffer[index] = (byte) 0x0000;
         }
         while(++index < byteBuffer.length);
         do
         {
             dataReadBuffer[position] = super.read();//
             if(dataReadBuffer[position] < 0) return bytesReadBySuperclass;
             else
             {
                 ++bytesReadBySuperclass;//
                 byteBuffer[position] = (byte)dataReadBuffer[position];//
             }
         }
         while((++position < length) && (position < loopLimit));
         return position;//
     }
 }

The data would be available in the byteBuffer after a read. Java should, to keep up with the developments in other facets of the linguistic, provide for a 64 byte broadside datablock transfer op from persistent storage to L2 cache, to do all io as 8-bit bytes sorta bites you in places you do not want to be bitten in.

The code has not been tested, significant work remains. The posting is only for ideas on how to approach the problem.


[ September 30, 2007: Message edited by: Nicholas Jordan ]

[Jim Yingst]

The AntiSnoop code is rather inefficient and has very little to do with what Sam asked about; he would be well advised to just study the Java Cryptography Architecture. Specifically, I would look at Using Password-Based Encryption. If you're guarding one user's data against other users, then get the user to supply a password. If you're trying to guard against snooping by any user, that's much harder if the users are hackers, but you can at least guard against casual snooping by hard-coding a password into your program.

Nicholas, if you want to discuss what your think is wrong with the standard IO classes, or how to use them more effectively than you do here, I suggest a separate thread. Let's not distract Sam from what he's actually trying to do.
[ September 30, 2007: Message edited by: Jim Yingst ]

[Nicholas Jordan]

[JY:]The AntiSnoop code is rather inefficient and has very little to do with what Sam asked about.

Sam's question was:   But, can data be saved into a different type of file so that it is not so easily accesable by the user?  

My approach was to provide code that ran. While you are correct in directing original poster to JCA, I found that I was not able to use it to accomplish concealment from snoopers. What power, in the hands of untrained, is efficient ? My code, by not using passwords, allows Original Poster to dispense with password management issues entirely by writng the data in a format of Sam's design and thus accomplishes his goal: not so easily accesable by the user . The idea of of storing a password hardcoded in a program introduces a weakness that did not exist before, that of a real intruder recovering the password from the compiled code and thus aliasing the authorized user. This was discussed recently in the Advaned:   Criptography   where PF dismisses hardcoded keys

Originally posted by: Pat Farrell Keeping the key in a config file or other secret or obscure place is not secure, and making a human type it in every time the system restarts is a headache at best.

I direct Sam's attention to that post if he needs anything more effective than class AntiSnoop, especially to avoid hardcoding passwords in source code.

[JY: ]Nicholas, if you want to discuss what your think is wrong with the standard IO classes, or how to use them more effectively than you do here, I suggest a separate thread. Let's not distract Sam from what he's actually trying to do

Agreed, except that I would like to be called Nick in routine, casual conversations. I am posting your pointer in Using Java as opposed to another language where performance counts
[ October 03, 2007: Message edited by: Nicholas Jordan ]

[Jim Yingst]

[Nick]: My code, by not using passwords, allows Original Poster to dispense with password management issues entirely by writng the data in a format of Sam's design

In other words, it leaves it entirely up to Sam to find a way to encrypt or at least obfuscate his data. Your class AntiSnoop doesn't do anything remotely resembling encryption or decryption; it just does what a FileInputStream does, but more slowly. It doesn't seem to be of any use in answering Sam's question.

[It also has nothing to do with solving the blocking problem you refer to here, - but I'm not going to follow you there since that is, once again, an off-topic post in someone else's thread. If you want to talk about something specific, don't parasitize other people's threads - start a thread of your own, and stay focused on that topic long enough to make your point without driving people away with rambling discourses on everything else under the sun. Focus, please.]

[Nick]: The idea of of storing a password hardcoded in a program introduces a weakness that did not exist before, that of a real intruder recovering the password from the compiled code and thus aliasing the authorized user.

Sam was vague about who he's defending against - snooping by whom? If you read what I wrote, I only suggested the hard-coded password in the event that the programmer is attempting to hide the data from all users, including the person running the program. Against such a user, there's not much you can do if the person has enough technical knowledge - anything you do can be reverse-engineered somehow. Which is why I said my hard-coded password suggestion might be good against casual snoopers, nothing more. Again, we don't know who Sam is trying to defend against, but if it includes the owner of the process running the program, obfuscation is probably the most we can hope for. Feel free to make a specific alternate suggestion; I don't see a specific solution for this problem in the Cryptography thread.
[ October 03, 2007: Message edited by: Jim Yingst ]

[Nicholas Jordan]

[JY:]In other words, it leaves it entirely up to Sam to find a way to encrypt or at least obfuscate his data. Your class AntiSnoop doesn't do anything remotely resembling encryption or decryption; it just does what a FileInputStream does, but more slowly. It doesn't seem to be of any use in answering Sam's question.

Sam's question was "can data be saved into a different type of file ", which the java source I wrote did just exactly that, nothing more. From what I can find, Serialization leaves data in a readable format. The code I provided addressed additonally what I thought to be a flaw, clearing the buffer before a read so that on return -1 the buffer does not contain garbage from a partial buffer fill.

Sam asked "save the data in a different format" and did not ask about encipherment. It seems a simple rot 1 or something would come to the posters mind and would make the risk assessment correctly.

[JY:]Sam was vague about who he's defending against - snooping by whom? If you read what I wrote, I only suggested the hard-coded password in the event that the programmer is attempting to hide the data from all users, including the person running the program. Against such a user, there's not much you can do if the person has enough technical knowledge - anything you do can be reverse-engineered somehow. Which is why I said my hard-coded password suggestion might be good against casual snoopers, nothing more. Again, we don't know who Sam is trying to defend against, but if it includes the owner of the process running the program, obfuscation is probably the most we can hope for. Feel free to make a specific alternate suggestion; I don't see a specific solution for this problem in the Cryptography thread.

It was apparent to me, and still is, that if Sam writes bytes in a format that only he knows, then the issue of passwords does not enter the solution. (unless of course he tells us he wants to do it that way ) Your solution brought to mind the type of person I have to deal with every day, and caused me alarm. I wrote the code for the poster because in my experience, trying to utilize JCA when the poster just wants to write bytes introduces a partially implemented solution and is a seriously flawed because of an incomplete grasp of the method used. Granted, the only real solution to Sam's question is real enciperment, which JCA can put within his grasp. But casual snooper defense does not require JCA.

I chose FileInputStream becase it does not do character conversion, which I assumed it would be incumbent on someone doing this type of work to at least read enough to know the difference between Streams and Writers.

The solution in the cryptography thread is very specific:   Java includes a real SHA256, so it is not much harder, and not all that much slower to just take the user's password, push it through the SHA256, and store the results when the userid/password is created which would alleviate the storing of passwords in compiled code.

That would be the correct solution. Since Sam was vague about who he's defending against, and has not provided further information, it may be difficult to work our discussion productively.

I deleted the f=15 t=001635 post, that does not interest you. At a minimum, assent that the code I posted was well intentioned. Protecting data from anyone, informed or otherwise, requires the type of discussion we are having. We know this, observers may not.

[Jim Yingst]

[Nick]: The solution in the cryptography thread is very specific: Java includes a real SHA256, so it is not much harder, and not all that much slower to just take the user's password, push it through the SHA256, and store the results when the userid/password is created which would alleviate the storing of passwords in compiled code.]

If you use the user's password, then obviously the user has the ability to decrypt it. If you look again at the part where I mentioned a hard-coded password, I was considering the possibility that Sam was trying to prevent snooping from everyone, including the user himself (or herself). So using the user's own password is hardly any more secure against them than using a hard-coded password that they can reverse engineer.

[Nick]: It was apparent to me, and still is, that if Sam writes bytes in a format that only he knows, then the issue of passwords does not enter the solution.

If the snooper can figure out how to read the hard-coded password, they can also read the code that writes the data, and figure out the format easily enough. Moreover, merely using "a format that only he knows" has a high chance of leaving Strings readable to even more casual viewers unless extra steps are taken to scramble it somehow. Rot-13 would work for this purpose too.

[Nick]: I wrote the code for the poster because in my experience, trying to utilize JCA when the poster just wants to write bytes introduces a partially implemented solution and is a seriously flawed because of an incomplete grasp of the method used. Granted, the only real solution to Sam's question is real enciperment, which JCA can put within his grasp. But casual snooper defense does not require JCA.

Nick, you were the one who advised him to look into the JCA earlier. I merely pointed him towards a specific working example of it, because your "AntiSnoop" did nothing at all to scramble the data in any way, even with rot-13.

Any how, without more info on what sort of "different format" Sam wants, and what sort of snoopers he wants to defend against, there's little point in continuing this.
[ October 03, 2007: Message edited by: Jim Yingst ]