I have made an encryption system and I'm looking for a way to add some way to integrate it with file system on windows(if possible also on linux). I don't want to rise a debate whether it is needed, that it already exists etc...
I was hoping to find a way to mount a virtual disk drive that will be able to access the files in the decrypted form, encrypt and decrypt on the fly using my software, it is currently written in java, but if needed I can port it to c++.
I have found one way to do it, which is to run a java ssh server and use another software to mount it in windows, but it doesn't work work well, constant crashes or it sometimes just doesn't mount the drive.
I need it as I want to access the files using IDE and other programs without coping the files as it decreases the security and doubles the disk space used.
Has anyone found a way to do it preferably in java?
Is there some kind of API for it (all I need is list files, get parent, read file, write file)?
Or is there a good java lib what works with another program to do it?
Related
I am trying to implement a simple encryption utility for educational pourpuses, it works, at least with simple files, but when I succesfully encrypt one file, i'd like not to encrypt it again, because that could lead to loose my data if i encrypt/decrypt it in a wrong way... Is there a way to prevent me from do it?
I am using java, and the default encryption library.
Thanks in advance
The answer to what you want to know here depends very much on how your encrypting the files in the first place.
I'll list a couple of different approaches that might help you however
Approach 1 - Scripting
If your using a 3rd party tool such as an encryption util written by another java programmer, and if your running this tool in some kind of a shell session, your best bet might be to wrap the invocation of said tool in a shell script.
If your running on windows this could be a batch file, on Linux a bash script.
Essentially you use this approach by working out ahead of time what command you need to use, then putting that command into said shell script while substituting any parameters you need to change.
Following on from the wrapped command you could then provide further commands to rename the file, or embed some kind of information in it's file properties or file name, a possible example might be something like:
IF NOT EXIST %%0.encrypted(
encrypt %%0 -a -b -c -d
rename %%0 %%0.encrypted) ELSE (
)
ELSE
()
NOTE: These are just theoretical examples as I don't know what your OS is
If this was saved in a file called 'myencrypt.bat', then you could just type
myencrypt.bat afile.ext
Approach 2 - Custom Bytes
If you have direct control of the source code and consequently the application that performs this encryption, then why not make a pseudo file format.
Add some kind of a marker into the file that your program then checks for.
By way of an example, you could perhaps
add the following string to the front of the file
ENCFOriginalFile.Ext
Turn that into a set of bytes, then load the file in, encrypt it, add the bytes from the text on and save it back out, maybe with a custom file extension.
When you come to encrypt a file again, all you then need to do is read the first 4 bytes and if they are equal to ENCF you know that the file is already encrypted.
Those are just 2 ideas I can think of off the top of my head, but it's late here and I'm tired. If I was more awake I could probably come up with a whole page full.
Since it is encrypted it cannot be opened in the default program for that file type, so you can savely rename the file. This can be done for example by adding .enc as the extension. Doing so will make it easy to spot the encrypted file for you and your java application.
Depending on your use case you can also let your java application manage a database of encrypted files.
Ok, the question is quite simple.
I have a Java program, which I am extracting some save-files to an external location.
Right now, I use C:/ApplicationName, however, that is a very bad way to do that.
I know alot of locations i could use, for instance:
%Appdata%
C:\Program Files (x86)
C:\Users\Users\Documents (Ive seen some indie games use this.)
Other locations?
But I can't figure out, when to use the proper one.
And if i want to support Linux and OSX, is there a libary, which supports that, or do i manually have to wrap them into an if/else with System.getProperties("os.name")?
Keep in mind that sometimes when games save to a specific directory, they aren't built to be cross-platform.
There are two ways you could do this. The first (and personally my preferred version) is to save in the directory of the application. This also has the advantage of being portable. However, the saves are linked to the application, so if the user deletes the application and reinstalls later they'll lose their data (which may or may not be a good thing).
Another option is to use System.getProperty().
Specifically, you can use:
System.getProperty("user.dir");
System.getProperty("user.home");
System.getProperty("user.name");
To figure out where to put your files.
This will be a lot more complicated, so the first method is preferred.
If it's data the user does not need direct access to, such as stored application/game state data, then it's appropriate to store it in the user's application data directory. Try this:
1) Determine the OS.
2) Get the user home directory.
System.getProperty("user.home");
3) Append OS-specific application directory:
Mac: /Library/Application Support/MyApp
Windows: \\Application Data\\MyApp
Linux: MyApp (there's no convention here that I know of)
If the data needs to be exported, such as saving a document from your application, then ask the user where to store the file via a file dialog, defaulting to their Documents directory.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions must demonstrate a minimal understanding of the problem being solved. Tell us what you've tried to do, why it didn't work, and how it should work. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I want to recover files from a disk by Java without using native libraries
I'm doing this using Java 8
As far as I know deleted files remain on the disk until they are overwritten
I have direct access to disk on linux and I can read raw data, but, how can I parse deleted files on an ext4 or NTFS file system for example?
Thanks.
Recovering deleted files requires knowledge of how the underlaying file system is implemented, so you have a bit of reading to do before you can get anywhere.
In theory, YES, you can definitely do this in pure Java; you just need to find out how to read data from a raw disk, bypassing the file system. On a Unix system this is simple: open the device node as a file (you'll need root permissions) and just read. On Windows there is probably a similar process; at worst you'll have to create a helper library in C or C++ to read the data for you.
Once you get access to the raw data, look up how files are stored in your particular file system and start looking for similar patterns in the data that you read.
This is not something you can do in an afternoon though.
Update: How to bypass the file system.
On a Unix system you can read from a partition or volume like this:
InputStream sda1 = new FileInputStream("/dev/sda1");
int firstByte = sda1.read();
On Windows you would read from \\.\PhysicalDisk0. From Naming Files, Paths, and Namespaces:
Another example of using the Win32 device namespace is using the CreateFile function with "\\.\PhysicalDiskX" (where X is a valid integer value) or "\\.\CdRomX". This allows you to access those devices directly, bypassing the file system. This works because these device names are created by the system as these devices are enumerated, and some drivers will also create other aliases in the system. For example, the device driver that implements the name "C:\" has its own namespace that also happens to be the file system.
APIs that go through the CreateFile function generally work with the "\\.\" prefix because CreateFile is the function used to open both files and devices, depending on the parameters you use.
If you're working with Windows API functions, you should use the "\\.\" prefix to access devices only and not files.
Most APIs won't support "\\.\"; only those that are designed to work with the device namespace will recognize it. Always check the reference topic for each API to be sure.
I don't know if the Java API is implemented using CreateFile or if it does some name mangling that means you can't access the device namespace. In the worst case you'll have to create a wrapper library that calls CreateFile and turns the HANDLE it returns into a file descriptor that can be used in Java; that's no work at all.
Files by definition are named sequences of bytes stored on permanent storage device.
Files are managed by OS component named file system. File system operates with term "file" and translates this term to lower level terms like volume, sector, block etc.
Mapping between file name (and path) and blocks on your disk where the information is actually stored is named files table and is managed by file system.
When you delete file you ask file system to remove appropriate entry from file table. This means that indeed the file content is not deleted from disk physically and if you are lucky enough can probably be restored. Why probably? Because once the file entry is removed from the table the space occupied by file can be re-used and therefore other information can be stored there.
There are tools that try to restore the information. These tools work on level under file system, i.e. use lower level APIs. Probably they are talking directly to driver. Java does not provide API for doing this.
Therefore you have the following solutions.
Implement this task in native language.
Use existing tools that do this task and provide either API or command line interface.
I am making the setup of java swing application by using Inno Setup as an exe i am selecting the jar file of my project, I am also adding other necessary resources as folder.
When I am installing the setup on the client side. it is putting the jar and other
resources in program files folder but there client can extract the my java classes
and other resources from jar. I want that client can only use the resources by
application program but he could not extract the resources. How is it possible?
There is literally nothing you can do to entirely prevent someone from extracting the resources.
The best you can do is to make the process a bit difficult; e.g. by storing the resources in the JAR file in encrypted form. The problem is that your program would need to decrypt the resources in order to use them. Someone with sufficient skills and patience can reverse engineer your decryption code and capture the unencrypted resources.
By the way, this is not a Java-specific problem. Any application that you provide to a user as an executable can be reverse engineered ... assuming that the user has the wherewithal to run it in the first place.
The bottom line is that if you are not prepared for the possibility that someone might extract the resources, you should not distribute the executable.
I'm currently developing an application for a company which includes livescoring. The XML-files I access (from the net like: "http://company.com/files/xml/livescoring.xml") are not intended to be public and should only known to me.
I was wondering if it is possible for anyone to decode the .apk file and read my original .java files (which include the link to the XML files).
So, I renamed the .apk file to .zip and could access the "classes.dex", which seemed to include the .java files (or classes). Googling led me to a tool named "AvaBoxV2" which decoded this "classes.dex" file. Now I have a folder including an "out" folder where files named .smali exist. I opend one of these with an editor and finally there is the link to the xml file. Not good. :(
Is there a way to encrypt my app or the classes.dex file? I don't want to tell that company, that anyone can access the original xml-files. Maybe signing the app probably helps?
Also, do you know a really noob-friendly tutorial to prepare apps (signing, versioning,...) for Google Market?
Thanks in advance!
The .java source code is not included in the APK.
It is possible to disassemble the Dalvik bytecode into bytecode mnemonics using a tool like baksmali, but there's no way a user can recover the original .java source.
Furthermore, you can use a tool like proguard (included in the Android SDK) to obfuscate your byte code, making it hard to interpret the behavior of the disassembled bytecode.
You can make small tricks too, like storing the link string in some sort of obfuscated form, and then de-obfuscating it at run-time in your app (a simple example would be to use base 64 encoding, but someone could probably reverse that quickly if they wanted to).
That said, it's pretty trivial for someone to run tcpdump and sniff the network traffic between your device and the server, and get the URL that way, so there's no way to completely prevent anyone from getting this value.
Yeah, its impossible to fully prevent something like this. Its the same on a desktop application, or any other application.
As mentioned, obfuscation will help, but people who are persistent can still get past it. Especially for something like a url like that.
One solution of making it much more tricky for hackers is to use PHP on your webserver and some sort of token system to determine if the request is coming from your app or not... That would get a bit tricky though, so I don't really suggest it.