Hi I would like to know if it is possible to use java to create files of extensions .dll
and storing images ? ???
Cause I want to protect my images but yet to need to use it in the game i am creating… is it possible by any chance?
or is there other methods ? ;D
Cheers! 
Sure it’s possible… heck, you can even create .exe, .com files also, just they won’t work as user expects ;D
other then JARs I don’t know. Maybe you can put all image data into array in the class itself and load it that way… source code would look horrible
Maybe puting all images into a single file and then grabing them out one by one as raw data… of course then load that data as image or something.
oh? so we are able to create a .dll file with java? but according to what you say… using codes… is it possible? as in it can really work…
cause i have seen some .dll files contain images and it is deeply compares which saves on the disk space…
but if i am not wrong the extraction process is also fast according to the remainding RAM left for usage…
so other than JAR files there is not other way??
Can any one else suggest other methods if any?
THANKS ! ;D ;D ;D ;D ;D ;D
Cheers.
Actually I don’t know a thing about dlls, I just ironicly staded you can create file with any name you like and put data (image) in it. I’m not sure about image data in array from start, other guys will need to help you on this.
You could encrypt your images and load them via a FilterInputStream.
Write a tool to create encrypted files using the following FilterOutputStream:
public class ObfuscatedOutputStream extends FilterOutputStream
{
// This is the encryption "password".
private static final byte[] keyBytes= new byte[]{ 104, 22, -95, -63, 59, 100, 49, -101};
public static final int DECRYPT_MODE= Cipher.DECRYPT_MODE;
public static final int ENCRYPT_MODE= Cipher.ENCRYPT_MODE;
private static final String algorithm="DES";
public ObfuscatedOutputStream(OutputStream outputStream)
{
this(outputStream,Cipher.ENCRYPT_MODE);
}
public ObfuscatedOutputStream(OutputStream outputStream, int cipherMode)
{
super(new CipherOutputStream(outputStream,getCipher(cipherMode)));
}
private static Cipher getCipher(int cipherMode)
{
Cipher cipher;
SecretKey key= new SecretKeySpec(keyBytes,algorithm);
try
{
cipher= Cipher.getInstance(algorithm);
cipher.init(cipherMode,key);
}
catch (Throwable t)
{
throw new RuntimeException("Could not initialize ObfuscatedInputStream!",t);
}
return cipher;
}
}
And wrap the following FilterInputStream around the InputStream to read your Image:
public class ObfuscatedInputStream extends FilterInputStream
{
// This is the encryption "password".
private static final byte[] keyBytes= new byte[]{ 104, 22, -95, -63, 59, 100, 49, -101};
public static final int DECRYPT_MODE= Cipher.DECRYPT_MODE;
public static final int ENCRYPT_MODE= Cipher.ENCRYPT_MODE;
private static final String algorithm="DES";
public ObfuscatedInputStream(InputStream inputStream)
{
this(inputStream,Cipher.DECRYPT_MODE);
}
public ObfuscatedInputStream(InputStream inputStream, int cipherMode)
{
super(new CipherInputStream(inputStream,getCipher(cipherMode)));
}
private static Cipher getCipher(int cipherMode)
{
Cipher cipher;
SecretKey key= new SecretKeySpec(keyBytes,algorithm);
try
{
cipher= Cipher.getInstance(algorithm);
cipher.init(cipherMode,key);
}
catch (Throwable t)
{
throw new RuntimeException("Could not initialize ObfuscatedInputStream!",t);
}
return cipher;
}
}
NOTE You should change the keyBytes byte sequence before using it, since this is the encryption password
You might have to optimize the above like caching the cipher to gain some performance.
Except that I could easily inject my own class into the classloader and intercept all the data after you’ve decrypted it for me. Or I could just hook into the OpenGL dlls and extract the image data as you pass it in. Or I could just use print screen.
If it’s on the client then it’s insecure. You just have to live with that.
If it's on the client then it's insecure. You just have to live with that.
Could not argue with that 
All you can do is to prevent “normal” users from copying the images. If someone has a little technical knowledge and the will to extract your coprighted data, there is nothing you can do.
In which case the easiest way is to just change the file extension. ;D
[quote]In which case the easiest way is to just change the file extension. Grin
[/quote]
Naaah… There are some more types of users between DAUs and powerusers (a DAU is a german abbrevation for “Dümmster Anzunehmender User” - “dumbest user in existance” ;))
A DLL is a dynamic link library. Which is tol say a peice of code that can be loaded bythe program at run-time.
Java loads ALL its code at run-time so DLL files are not necessary. In essance, every .class file is a Java DLL.
What this has to do with your image data though I haven’t a clue.
Ye, change the extension. ImageIO for example uses the header to determine the format. Use the class extension for irritation or something like “spr” for making it look like a custom format.
But then somebody could just simply take a screenshot and use the image anyway? Still hard, but not impossible.
anyone looked at System.loadLibrary() yet?
kingaschi is right, it doesn’t matter how you encrypt it, because it’s all just raw image data by the time it hits the screen.
same reason why iTunes (for the few who legally obtain music) can’t limit your music to one computer, because, by the time it hits your speakers… it’s sound, and VERY recordable from the line out port 
anyway, what I’ve done before [when I used to care about my image data] is create a file that has the EXTENSION of .dll but isn’t really a .dll. I was just using ZipOutputStream to shove all my images to one zip file [but it wasn’t .zip, it was just .dll]. So, to a newbie who doesn’t know how a normal DLL looks on the inside, this worked fine. But to all of us who happen to know that all zip file data starts with “PK”… it’s just a matter of renaming that file to .zip and ta-da.
[quote]But to all of us who happen to know that all zip file data starts with “PK”… it’s just a matter of renaming that file to .zip and ta-da.
[/quote]
That’s where encrypting the content helps to some degree. You can’t prevent your images from being stolen by criminals, but you can reduce the amount of users capable to do it:
Using unencrypted images with correct suffixes: everyone can steel it
Changing the the suffix: everyone that is courious enough can steel it (Just drag and drop to a capable image viewer)
Using an archive and change the suffix: everyone knowing about archives and hex-editors can steel it
Using encrypted images: the user must at least know about java, processes, classloaders and jad to steal it
I have not listed an encrypted archive, because ZipInputStream generates temporary files afaik.
As pointed ot before, there is always the possibility to steel images directly from screen by just taking a screenshot. This might be a smaller problem, since you can’t “bulk-steel”, cause one is limited to a single image per screenshot.
There might also be the possibility to steel images with a memory exploration tool.
As a rule of thumb, just protect your data to a degree, where the effort to steel it rises to a degree that enough of your target audience will lose interest to do so. What this means depends on you and your target audience.
The last and probably best option might be just to trust them
Heys… Thanks alot people!!! ;D
Your information really help me alot… i learnt something…
Thanks Kova, cylab and the rest!!! :-X
Cheers!
But then somebody could just simply take a screenshot and use the image anyway? Still hard, but not impossible.
Actually there are situations where normal screen shots will fail, believe it or not. Some media players will direct stuff through some hardware pipe or something (I presume), and the image information will not be inside the memory which the screenshot copies (this, of course, depends on how ‘close’ to the screen that memory buffer resides). This is sometimes a pain in the butt when trying to display movies on an external screen. One ‘fix’ I usually apply is to start TWO instances of media players, of which the first one will use the hardware piping thingy (or whatever it is), and the second will display properly
I doubt that… you have a link to article or some info we can google about?
I think screenshots take data directly from output of graphics card, the data that arrives in monitor. If it’s like that it would be impossible to hide image from a screenshot.
I’ve seen it happen: In my final year at university, one of the groups went to the trouble of making a 3D movie for their presentation. They distributed the 3D goggles, the expectation was palpable, and then the projector gave them a blank section of screen where their movie should have been :-\
You can only screenshot image data that is displayed in the normal graphic memory of the video card (at least with the standard screenshot methods). If the media-player or game uses overlays, you will just capture the overlay color. It might be possible to implement a game using overlays to disable screenshot capability by rendering to a background buffer and blitting it to a window or the screen using overlay methods. But don’t ask how