I want to personalize (customize, preconfigure etc) each copy of the installer I give out. But, of course, I do not want to recompile the installer every time.
NSIS has a solution where you append the data to the executable. Can you suggest a solution with IzPack?
One idea I had, is to add data post installation to the installer JAR file, but I can't figure where and how to read it...
Thanks
A JAR stores its headers at the end of the file, this means your custom data must be added to the beginning of the file (A combined GIF and JAR is known as a GIFAR and has been used for some exploits in the past, so just make sure you don't start your custom data with something that looks like a GIF (or other image format) header to avoid AV false positives)
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.
I thought this would be an easy task but . . .
I want my Java program to get the user's Windows file associations.
In other words, I want to know what the user uses to open .txt files, .cvs files, etc.
The assoc and ftype commands provide that info, but not for the user.
In other words, if I've set my text editor to Notepad++,
assoc and ftype don't show it. They show the system default, Notepad, instead.
It looks like I have to get that info from the registry but I have two problems.
1) I don't know the exact registry keys I want to pull
(though I've looked at "reg query HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, etc.)
2) I don't know how to pull the key from the registry. I've seen JNI mentioned
but haven't figured out the details.
Any hints appreciated.
In Win7, you can find the "class"* for each file extension in the
HKLM\SOFTWARE\Classes\<extension>\(Default)
key.
For example, on my machine
HKLM\SOFTWARE\Classes\.txt
has a (Default) key of txtfile.
In that same path, you can find what opens files of the class txtfile:
HKLM\SOFTWARE\Classes\txtfile
Which should have a subpath of ...\shell\open\command
On my system,
HKLM\SOFTWARE\Classes\txtfile\shell\open\command\(Default)
is
%SystemRoot%\system32\NOTEPAD.EXE %1
Which you could parse to find the executable that opens .txt files.
For user-specific customizations, you can replace
HKLM\SOFTWARE\Classes\
with
HKCU\Software\Classes\
All that being said, I like MadProgrammer's suggestion if possible for your application.
* I'm sure there is a better name for "class", I just don't know it.
Take a look at the Eclipse's Program class, which should to what you want: http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fprogram%2FProgram.html.
If you would like to launch the program, use the Desktop-class (like MadProgrammer suggested)
I list some filenames with their icons (like the ones in the Windows Explorer) in a JTable. I know the two ways to get the icon if I have a File object from the local file system:
javax.swing.filechooser.FileSystemView.getFileSystemView().getSystemIcon( file )
for a 16x16 icon or for a bigger one:
sun.awt.shell.ShellFolder.getShellFolder( file ).getIcon( true ) )
Since my files are stored in a database, I don't have the File object. My workaround is to create a temp file with the specific filename extension, use one of the two methods above and cache the icon to display it in a CellRenderer.
I searched for a solution without temporary files and found two I don't like either:
org.eclipse.swt.program.Program.findProgram(String extension).getImageData(), but I don't want to use SWT
org.jdesktop.jdic.icons.IconService from the Incubator of the JDIC project. The last changes on the IconService are 6 years ago, on JDIC 2 years ago and I can't find a downloadable jar.
Is there another solution?
Looks like you already discovered the way to do it, unless you want to dive into native libraries etc.
FileSystemView uses Win32ShellFolder internally so they are basically the same.
I also dug up the Source for org.eclipse.swt.program.Program and with it org.eclipse.swt.internal.win32.OS. The OS class then uses a native call for the Icon. At this point unless you really really cannot create a Temp File i would not go down that path.
For JDIC i only found http://kickjava.com/src/org/jdesktop/jdic/tray/internal/impl/WinTrayIconService.java.htm with a little bit of digging(may not be related but does icony things :D). Also calls native.
Do you really need the temporary file to use the first option? A File does not have to denote a file that actually exists...
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.
I am doing a project in java and in that i need to add and modify my
text file at runtime,which is grouped in the jar.
I am using class.getResourceAsStream(filename) this method we
can read that file from class path.
i want to write into the same textfile.
What is the possible solution for this.
If i can't update the text file in jar what other solution is there?
Appreciate any help.
The easiest solution here is to not put the file in the jar. It sounds like you are putting files in your jar so that your user only needs to worry about one file that contains everything related to that program. This is an artificial constraint and just add headaches.
There is a simple solution that still allows you to distribute just the jar file. At start up, attempt to read the file from the file system. If you don't find it, use default values that are encoded in you program. Then when changes are made, you can write it to the file system.
In general, you can't update a file that you located using getResourceAsStream. It might be a file in a JAR/ZIP file ... and writing it would entail rewriting the entire JAR file. It might be a remote file served up by a Url classloader.
For your sanity (and good practice), you should not attempt to update files that you access via the classpath. If you need to, read the file out of the JAR file (or whatever), copy it into the regular file system, and then update the copy.
I'm not saying that it is impossible to do this in all cases. Indeed, in most normal cases you can do it with some effort. However, this is not supported, and there are no standard APIs for doing this.
Furthermore, attempts to update resources are liable to cause anomalies in the classloader. For example, I'd expect resources in JAR files to not update (from the perspective of the application) until the application restarted. But resources in exploded JAR files probably would update ... though new resources might not show up.
Finally, there are cases where updating a resource is impossible:
When the user doesn't have write access to the application's installation directory. This is typical for a properly administered UNIX / Linux machine.
When the JAR file is fetched from a remote server, you are likely not to be able to write the updates back.
When you are using an arbitrary custom classloader, you've got no way of knowing where the actual bytes of an updated resource should be stored, and no way of storing them.
All JAR rewriting techniques in Java look similar. Open the Jar file, read all of it's contents, and write a new Jar file containing the unmodified contents (and the modifications you whished to make). Such techniques are not advisable for a Jar file on the class path, much less a Jar file you're running from.
If you decide you must do it this way, Java World has a few articles:
Modifying Archives, Part 1
Modifying Archives, Part 2
A good solution that avoids the need to put your items into a Jar file is to read (if present) a properties file out of a hidden subdirectory in the user's home directory. The logic looks a bit like this:
if (the hidden directory named after my application doesn't exist) {
makeTheHiddenDirectory();
writeTheDefaultPropertiesFile();
}
Properties appProps = new Properties();
appProps.load(new FileInputStream(fileInHiddenDir));
...
... After the appProps have changed ...
...
appProps.store(new FileOutputStream(fileInHiddenDir), "Do not modify this file");
Look to java.util.Properties, and keep in mind that they have two different load and store formats (key = value based and XML based). Pick the one that suits you best.
If i can't update the text file in jar what other solution is there?
Store the information in any of:
Cookies
The server
Deploy the applet using 1.6.0_10+, launch it using JWS and use the PersistenceService to store the information. Here is my demo. of the PersistenceService.
Also, if your users will agree to a trusted applet (which seems overkill for this), you might write the information to a sub-directory of user.home.