Raw disk access on Windows 8 [duplicate] - java

This question already has answers here:
How to access specific raw data on disk from java
(8 answers)
Closed 9 years ago.
I have a problem with raw disk access in Windows. I wrote program in Java, which works with USB flash device, reads its MBR and etc. Device is opened as RandomAccessFile.
If i open NetBeans and execute by program as usual user i have exception
Exception in thread "main" java.io.FileNotFoundException: \\.\PhysicalDrive2 (Отказано в доступе)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:241)
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:122)
at main.USBFlashDevice.<init>(Main.java:90)
at main.Main.main(Main.java:196)
Java Result: 1
If i do it as admin, everything is OK.
What can i do to execute program and edit MBR when i work as usual user on somebody's PC?

What can i do to execute program and edit MBR when i work as usual user on somebody's PC?
You can't.
Writing to the raw disc device is a potentially dangerous operation. It could effectively trash the file system.
Even raw disk read access allows you to read files that are denied by normal Windows access control.
It is therefore mandatory that any program that accesses raw disk has admin privilege. The operating system insists on this. Note: this applies to all multi-user operating systems, not just Windows.
You have to run the program with admin privilege. An if you are really asking how to do that ... your question is off topic. Try asking on "superuser.com".
But I should also say that:
Writing this kind of stuff is dangerous and probably a bad idea. Use an existing utility; e.g. one provided by Microsoft or a reputable 3rd-party software provider.
If you (really) need to write this yourself, doing it in Java is probably a poor choice. Most people would use C or C++.

Related

Can a file browser, with file opening and previewing disabled, be safe from malware which run when viewed in explorer?

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.

How to close a .txt file as it opens

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?

How to read from a file that is in use

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.

Alternatives to SQLite Database Encryption [duplicate]

This question already has answers here:
SQLite with encryption/password protection
(9 answers)
Closed 9 years ago.
My desktop Java app uses several read-only SQLite databases, which I would prefer people not be able to open up and look at. Normally, this might be accomplished through encryption, but I'm currently using the sqlite4java library, which does not support encryption and doesn't easily allow other SQLite encryption libraries (e.g. SEE) to be used.
What I'm trying to do is make it as difficult as possible for a "casual hacker" to just find one of these database files and open them up. For instance, someone threw out the idea of sticking them in a password-protected ZIP file, then using a library like the ones suggested here to decrypt it on the fly as either an InputStream or a temporary file.
Would this be something that is worth doing?
EDIT: I realize that this isn't going to be perfectly secure, and a hacker dedicated enough might be able to still find a key and decrypt it (this seems like a vulnerability with any such programs).
"What I'm trying to do is make it as difficult as possible."
You are probably just making it as difficult as possible for yourself.
Regular users don't open application binaries. People that open application binaries have tools to find your encryption key.
If you want to engage in security through obscurity, just name the database file "commons-io-3.2.1.jar" instead of "mydb.sqlite3". No trouble for you, still throws off the "casual hacker".
Instead of password protecting your SQLite DB, you can choose not to ship it with the application APK, rather download the content on first run, so that you don't have to encrypt and decrypt and your APK is lighter.
Also remember, your DB can still be hacked by intense hacker.

Write to hidden files in Java [duplicate]

This question already has answers here:
Modify a hidden file in Java
(2 answers)
Closed 10 years ago.
I have a problem with my hidden files in Java. I would like to write to a hidden txt file but it always says "access denied".
My suggestion would be to make the file visible, write into it and then make it hidden again.
But how can i make a hidden file visible?
I previously said: The problem is not that the file is hidden. The problem is that your program doesn't have write access for the file. Making it "unhidden" is unlikely to help.
It seems that it is more complicated than that for Windows. Certainly it is worth trying to "unhide" the file before modifying it.
Anyway, if you are using Java 7, the way to read and write Windows-specific file attributes is to use the java.nio.file.Files API, and specifically the getFileAttributeView(...) method. For older versions you will either need to use an external utility (see #Achintya Jha's Answer) or use a JNI / JNA wrapper to call a Windows native API.
If you are using Linux, change Windows-specific to POSIX and/or Linux specific. (Note that a lot of this stuff to do with file attributes and permissions is intrinsically OS specific.)
Finally, if the problem is that the program doesn't have write access to the file, there is a fair chance that there is nothing that it can do to get write access.

Categories

Resources