Need a program written in Java to close a .txt file as it opens (so that the user can, hopefully, not see it). How would I go about closing a .txt file as soon as it opens?
The alternatives to this way is to open the file on the secondary monitor or replace the text in the file instantly so the user cannot see this.
As I understand your question you want to intercept all requests, by any program running in a computer, to open any text file, and prevent that file from being accessed.
This is categorically beyond the capabilities of anything you can do in Java, or any "user-space" environment. Anything of this type would have to be done as part of the operating system, operating in privileged mode, and working with the filesystem drivers.
This could probably be done but would be operating-system specific and likely need to be written in C++ or assembler. Also it would require specific user action to be installed and would require superuser or administrator privileges.
This is not something within reach of a developer without significant OS kernel experience.
Sounds like you are trying to write ransomware?
Related
I am making a custom file explorer in java. I came to know of this worm which starts executing when the file icon is viewed in file explorer. I believe, this could be possible only if it is loaded into memory somehow by something like reading of metadata (Please correct me if i am wrong). I have heard java is a 'safe' language but just wanted to know how much safe it is.
I am using the following imports in my program :
java.io.File;
java.net.URL;
java.nio.file.Path;
javax.swing.filechooser.FileSystemView;
I use fileSystemView.getFiles() to get files list and simply display an icon by checking the file extension.Files are not preveiwed also.
So if i disable opening of a file by clicking on its icon in my file browser, then is there any way that some malware can run when my file explorer program displays the contents of an infected pendrive?
Can this be achieved by other programming languages also?
There are several aspects to you question here.
First of all, about the danger of accidentally reading/executing files by clicking them in your application: I think it's a bit difficult to answer that without actually seeing the code you're running. I can't see any obvious threat based on your description, but then again, I don't know exactly what your Java Runtime will do for you when you mark a file, read the directory it is in, and read the file itself - if there's no "magic" happening behind the scenes there, there might not be a problem. If Java does any kind of reading/parsing/whatever with a file in order to register and list it though, it's hard to tell.
From the documentation for Class FileSystemView
Since the JDK1.1 File API doesn't allow access to such information as root partitions, file type information, or hidden file bits, this class is designed to intuit as much OS-specific file system information as possible.
I'm not really sure exactly what this even means, but I take it as an indicator that something is going on behind the scenes when accessing files. Perhaps someone with more in-depth knowledge can add to this.
Now as for using this to analyze potentially infected thumb drives: Be very careful.
When you connect something to your USB, it can do "stuff"(*) automatically as soon as it is connected. This will likely happen long before you've even started your Java app, so it won't really matter how safely you code it.
There are ways to restrict access to USB, and such auto-run behavior. You should at least be aware and look into this, and make sure you have an updated and working security scanner of some kind before inserting anything suspicious into your PC.
(*) There are even examples where USB devices can steal info from locked computers by providing a (fake or real?) network connection, and then listening in to and manipulating the automatic connections computers typically do continually in the background.
Getting An "Access Denied" Error While Editing "Hosts" File Through Java Program.
Program needs an ADMINISTRATIVE PRIVILEGE To Edit The Hosts File.
So Is there any Solution To provide That Administrative privilege to java program so that It can edit Hosts File.
** Note **
I am Using Window 8.1 OS.
Hosts File Location is:
C:\Windows\System32\Drivers\etc\Hosts
Have a look at the AccessController API: Java Access Controller
one thing is for sure though, when the user runs the Java program, the user must right-click and select 'Run As Administrator'.
Another option is that you could read in the file, make your changes in memory, (file could be read in as a string), and then write out the file to replace the HOSTS file. Which again, you definitely need Administrator privileges.
Quick Google search also showed source code for a package that let's you edit hosts file, you might want to take a look at that. It still definitely needs the administrator permissions though. Link here
Have a look at this previous SO question, it might give you a few ideas.
The main issue with writing this kind of programs is the permissions. The Hosts file is a critical part of every operating system, and it's only logically to have layers of security around it to prevent any random program from changing the hosts file, hence all these extra hurdles.
There's a file I wanted to get into, but whenever I try to open it I get the message "The process cannot access the file because it is being used by another process".
Well, I want in! So, how can i do it?
I've been brainstorming a few ways to try, I'm hoping to get some input on other ways, or if my ideas wouldn't work for some reason that is not apparent to me.
Idea 1 The folder knows where the file is, it just won't open it. What if I create a program to read from the memory address of the file, copy it, then rebuild it somewhere else? I'm not sure if this has hope, because it relies on the file being the issue.
Idea 2 How does my process know that another process is using the file? If it's checking against all the other processes, maybe I can also figure out which process is using that file and pause it or end it.
Either of these ideas will probably take me weeks. Is anyone more creative and can think of another way; or more knowledgeable and eliminate an impractical idea?
In Windows, applications are allowed to obtain exclusive locks on files. When the process opens the file, one thing you specify is who else can access it while your process does (those are the .NET methods, but equivalents exist in other languages). Excel, for example, is notorious for getting an exclusive lock when you open a file. The way around it is usually to find the offending process and kill it to break the lock. Unlocker is the app that I'm most familiar with to accomplish this. If the process is a System process, however, you may not be able to kill it. You'd have to reboot to reset the lock.
Reading directly from another process's memory is unlikely to be reliable. The application may not have an in-memory copy, may not have a complete in memory copy, may not have a consistent in memory copy, and may not have an in memory copy that matches what's on disk (If they're editing the document, for example).
Your process knows that the file is locked because when it tries to open the file, it does so by asking the operating system for access to the file. The operating system responds saying, "Request denied. Another process has this file open and locked." The OS doesn't tell your process what process has the file open because trying to open a file doesn't include asking for who already has it open. Your process must ask the right question to get the answer you're looking for.
Windows makes you specify a sharing modes when opening a file. The sharing mode may prevent the file from being read, written, or deleted while you have it open. If you want to allow simultaneous read access you should include FILE_SHARE_READ in the dwShareMode parameter when you call CreateFile (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx).
In other words, if you want to enable concurrent access to an open file you must modify the way the file is opened in the first place.
The portable standard libraries in C and Java don't offer a way to set the sharing mode when opening a file, but their usual implementations on windows set the sharing mode to READ+WRITE.
I am making Scouting Software (in Java) for my FRC robotics team. Scouting is like collecting data on other teams' robots during competition. It is absolutely critical that my program makes that process as simple and easy as possible. My program can save its data in two ways, one of which is by writing a .scout file to the user's hard drive. All this is working well, but as a finishing touch i would like to implement a way to associate .scout files with my program so that .scout files are opened with my program. It's like .docx for Microsoft Word. It associates .doc/.docx/...etc to itself such that when the user clicks on a file with those extensions, Word opens itself up and then opens the file the user clicked on. I want something like this for my application. Keep in mind, it is written in Java and meant to work on different operating systems (Windows, OSX, Ubuntu Linux, etc).
Does the program have a GUI? If so, launch it with Java Web Start.
JWS can associate a file-type with an application on Windows, OS X & *nix. Here is a demo. of the JNLP API file service that associates the .zzz file type with the demo. app.
I've put together a basic applet where the user selects a file from their hard drive, it reads the first line of this file and passes that off to JavaScript for some additional preprocessing, and then when you click a button it tries to upload that file through an HTTP POST request. I found a very basic open source applet for uploading files that I copied and modified for this last bit.
The trouble is, though, it doesn't quite work. It seems like it's running fine, but then I run into two snags related to permissions. The messages in the Java Console say that the applet had access denied errors on the following two permissions:
java.lang.RuntimePermission setFactory
java.io.FilePermission read
I find this strange, because I thought I had granted permission to the applet already when I built it with the "self-signed" option checked in NetBeans, and then clicked to confirm the little security pop-up in the browser.
Also, the part that I coded myself, where it reads the file and passes the first line on to JavaScript works fine. This is a pretty clear indicator that the applet is able to read from the local file system! The trouble doesn't start until I actually try to start the upload. One thing to note, I suppose, is that the upload process seems to run in a new thread, whereas the rest of it all runs in the main class without creating threads.
I am a total novice to Java and know very little about threads in Java; do I need to pass the permissions onto this new thread somehow? Or something to that effect?
Thanks in advance.
You probably need to ask the security manager (code, not administrator) for permission to do a privileged operation. For various reasons, it's not generally a good thing for an applet to be able to open a local file, so it's guarded pretty heavily.
The basic key is to call AccessController.doPrivileged() and there's a good little tutorial on it at the Java Ranch FAQ.
I had a similar problem which took forever to solve. It turns out applet methods called from JavaScript have no permissions, even if you explicitly grant them in a policy file.
This workaround worked for me (adding commands to a queue which the applet loops through):
http://blog.carrythezero.com/?p=5
Make sure you understand the dangers here: Anyone can modify JavaScript on a page and change what's getting fed into the applet. In my case I know the code is never going on a webserver, and the class is unsigned so it will fail unless in the specific location granted by my policy file.
It's probably because the JavaScript is unsigned. I strongly suggest not signing code, particularly if you don't know what you are doing. From 6u10 (not on Mac yet) applets can use JNLP including the FileOpenService, so you don't have to sign.