Games with files without extensions

Started by
8 comments, last by NoWo 16 years, 8 months ago
Hi, I unzipped the Jars of a few profi-games ( Cake Mania, Tetris Mania, Deal or no deal). To my greatest surprise all three games contained a lot of files without any extension. Never seen this before. Seems like a good and clever protection. Can someone tell me how such files (I assume they contain mostly graphics) can be done and included into a game? Any helpful answer is appreciated -:) NoWo
Advertisement
Yeah, I see them all the time. They're absolutely EVERYWHERE on Linux. The file "extension" doesn't mean anything in particular, it's just a dumb (simple/easy, not necessarily bad) way to identify and associate a file with certain properties or applications.

EDIT: In case it isn't obvious, you can create them by renaming the file without the extension. So if you have a targa file or something that you want to load into your game you would rename it (F2, mv, whatever) from "superawesomegraphics.tga" to "superawesomegraphics" and then load that into your game the same way you would any other file. Remember, the extension is just part of the file's name.
Quote:Original post by NoWo
Hi,

I unzipped the Jars of a few profi-games ( Cake Mania, Tetris Mania, Deal or no deal). To my greatest surprise all three games contained a lot of files without any extension. Never seen this before. Seems like a good and clever protection. Can someone tell me how such files (I assume they contain mostly graphics) can be done and included into a game?

Any helpful answer is appreciated -:)

NoWo


What exactly are you trying to do?
Are you trying to reverse engineer the game and modify the jar you unzipped? Are you planning on making your own game and want to obfuscate and hide details of it?
Quote:Original post by NoWo
Can someone tell me how such files (I assume they contain mostly graphics) can be done and included into a game?


The trivial way would be to rename your "mysprite.png" file to "a". Then load it with Image.createImage("a").

But these files usually pack more than one resource in a single file in order to save jar space (less files = smaller jar). Making a tool to pack files isn't too hard, and if you know how they are packed you would also know how to unpack them in your MIDlet. There are tools like bincompiler available if you don't feel like reinventing the wheel.

There is more stuff you can do to protect your media/squeeze your jar file, which depends on the type of data you are using, and this thread has many of those tips.

shmoove
Quote:Original post by NoWo
Seems like a good and clever protection.


Not to me. Most of "standard" files like jpg, png, tga, wav, ogg ... and many others have standard header - special bytes at beginning of file, which identifies them very easily. Just open them in some hex editor and it should be very obvious what type of file it is.

Since mobile game development is all about generating the smallest jar possible (hence the removal of unnecessary PNG chunks and packing them in a single file), you might as well remove the file extensions. The change from getResourceAsStream("/a.bin") to getResourceAsStream("/a") might save you some bytes.
This is, for instance, also one of the reasons why obfuscator plugins rename your classes to A.class, B.class etc.

Quote:Original post by bubu LV
Quote:Original post by NoWo
Seems like a good and clever protection.


Not to me. Most of "standard" files like jpg, png, tga, wav, ogg ... and many others have standard header - special bytes at beginning of file, which identifies them very easily. Just open them in some hex editor and it should be very obvious what type of file it is.

True, although headers are typically removed, since they are just redundant bytes (per file) when you have a "custom" loading procedure.
Quote:Original post by WanMaster
Since mobile game development is all about generating the smallest jar possible (hence the removal of unnecessary PNG chunks and packing them in a single file), you might as well remove the file extensions. The change from getResourceAsStream("/a.bin") to getResourceAsStream("/a") might save you some bytes.
This is, for instance, also one of the reasons why obfuscator plugins rename your classes to A.class, B.class etc.

Quote:Original post by bubu LV
Quote:Original post by NoWo
Seems like a good and clever protection.


Not to me. Most of "standard" files like jpg, png, tga, wav, ogg ... and many others have standard header - special bytes at beginning of file, which identifies them very easily. Just open them in some hex editor and it should be very obvious what type of file it is.

True, although headers are typically removed, since they are just redundant bytes (per file) when you have a "custom" loading procedure.

Those of who are interested, there are some of these listed in Wikipedia: Magic number.
---Sudet ulvovat - karavaani kulkee
Hi guys,

thanks to all your clever answers, will follow them tomorrow.

@ trojanman,

no, I do not want to reingeneer anything or steal code or something like that. At the moment my main interest is mainly what different approaches of graphic making are used (it is more a style question for me, should I use 3D Blender or more a vector program like Flash), and on this search I stumbled into these extension-less files. Interesting enough there are no visible graphics in the mentioned games, so the pics seam to be "buried" in the "nameless" files in a special way.
For myself I think this is an interesting approach to try to protect code, pics and other things.

NoWo
Quote:Original post by NoWo
Interesting enough there are no visible graphics in the mentioned games, so the pics seam to be "buried" in the "nameless" files in a special way.
For myself I think this is an interesting approach to try to protect code, pics and other things.


It is common practice -- and a good practice -- to convert your assets (sound, graphics, movies) into the smallest format reasonable. It may be that an image file is reduced to lower bit depths or pre-coded for the target hardware. These reduced assets are typically packed into large data files to reduce the number of files in use, help the OS save space, reduce the number of things that can go wrong, and so on. Often the data files are additionally compressed to save space in distribution, although Java's .jar files already do that.

It doesn't protect anything. It does manage to obfuscate it a little bit, but that generally isn't the reason for the practice. You reduce load times by a huge amount if everything is neatly packaged and ready for binary consumption and direct loads.
Okay,

today I tried a lot but gave up now.
Thanks for up to now, have to do something else now ( earning money and the like ). Thanks for all your fast and informative answers -:)

NoWo

This topic is closed to new replies.

Advertisement