Free EXE packers?
Community Forums/General Help/Free EXE packers?
| ||
| Hi, Do any *free* executable packers exist for BlitzMax? You know the kind that doesn't allow people to edit media or mod the application? |
| ||
| Doesn't BlitzMax have this built-in, via IncBin? (Why would you even want to do that?) |
| ||
| Why would you even want to do that So that my media such as 3D models, sound, music, images etc could not be edited by the consumer of course. IncBin How do I use this? Does this work with the MaxIDE CE? EDIT: also, how can I put an icon into the exe? Resource Hacker will not work. Last edited 2012 |
| ||
| How do I use this? Does this work with the MaxIDE CE? It's a BlitzMax compiler-level feature, has nothing to do with which editor you use. The file specified gets included as a binary blob in your file. You can then get a pointer to the raw data with IncBinPtr and IncBinLen, and either read it directly or pass these to CreateRamStream (or perhaps there is a simpler way when dealing with filetypes known to BlitzMax... I don't know, I'm not up to speed on idiomatic Max programming). So that my media such as 3D models, sound, music, images etc could not be edited by the consumer of course. How is that a good thing? (PS: it is literally 100% impossible to "protect" media from theft, and any attempt to do so is both misguided and doomed to failure. All you'd be doing is making life slightly more difficult for anyone who wanted to edit it for some legitimate reason.) |
| ||
| UPX for-the-win (FTW) http://upx.sourceforge.net/ p.s. I'm all about protesting assets as much as possible. While not imperative, I'd just rather keep my files from prying counterfeiters. Last edited 2012 |
| ||
| The file specified gets included as a binary blob in your file. You can then get a pointer to the raw data with IncBinPtr and IncBinLen, and either read it directly or pass these to CreateRamStream (or perhaps there is a simpler way when dealing with filetypes known to BlitzMax... I don't know, I'm not up to speed on idiomatic Max programming). It is indeed simpler than that. Incbin "folder/myimage.jpg" embeds the file into your exe (call just once). LoadImage( "incbin::folder/myimage.jpg" ) For user file types you can still ReadFile( "incbin:: " ) and get the same stream you would with any other file. I think its best use is for GUI apps that use panel images and toolbar images etc, so users can move "myApp.exe" around without breaking it. And of course it makes the installation folder tidy if you're an OCD'er like me :) But for games where you have a tonne of resources to manage, there are better ways *cough* that don't depend on you maintaining an incbin list (which will quickly become a pain). |
| ||
| I thought UPX is only a run-time compressor and doesn't support encryption. |
| ||
| Why would you even want to do that? (PS: it is literally 100% impossible to "protect" media from theft, and any attempt to do so is both misguided and doomed to failure. All you'd be doing is making life slightly more difficult for anyone who wanted to edit it for some legitimate reason.) When does stealing other people's graphics to edit them and pass them off as their own no doubt, ever be legitimate? Yes 100% protection isn't possible, but that doesn't mean you shouldn't discourage theft. Last edited 2012 |
| ||
| Yes 100% protection isn't possible, but that doesn't mean you shouldn't discourage theft. Any protection via encryption is more or less 100% impossible. What is both possible and effective is protection through copyright. Use the law, that's why it exists, and it is far more powerful than some easily-cracked hash check could ever be. Heck, if you have the time and resources to waste, knock yourself out, but the Captain is a new coder with limited time and experience who arguably should be focusing on things that will actually improve his product, not conditioning himself to waste effort on things that, at best, might not overly harm performance. Besides, you also lock out the mod scene and the people who just want to look at the graphics and play with them legitimately on their own computers, which is a far larger proportion that the complete idiots who think they'd get away with redistributing copyrighted assets without permission. (Hint: anyone who has the money to get away with it, has the money to 1. break your encryption, and 2. rebuild everything from scratch without causing a fuss.) |
| ||
| Another approach to make it a lot harder for people to 'borrow' your media: - Create a password-protected zip file (If the data is poorly compressible, then just use archive instead of compress to maximize the speed) - Incbin the password-protected .zip into your executable - Use koriolis' zipstream module to access the data.| From the zipstream documentation: The zip stream works over another stream. This means that you can not only access zip files on the hard drive, but also zp files that are incbined, or even zip files within other zip files, and so on. Example of valid urls: "zip::myGame/myZip.zip//someFile.txt", or even "zip::incbin::myGame/myZip.zip//someFile.txt" if the zip file is incbined. So you could do by example: LoadText("zip::myGame/myZip.zip//someFile.txt") In the previous version of this module, TZipStream was not seekable. It is now entirely seekable, and will thus work with any underlying stream. Another option is to create your own proprietary data file formats to make it harder for others to do anything with them, but that is a pretty big hassle and tends to be larger/slower than the industry standard file formats already in use. Last edited 2012 |
| ||
| Where do you get TZipStream module? is this included in the latest blitzmax distribution? EDIT: nevermind, i found it here: http://www.koriolis-fx.com/forum/index.php?topic=15.0 Last edited 2012 |
| ||
| If it helps Captain, here's my workflow for when it comes to incbin'ing zips... I put all my resources into a folder called "data" next to the exe. The data folder can have subfolders. I only incbin the resources during release build because a) it adds to the build time (quite significantly for big zips) and b) it saves having to build the zip after every tweak of some resource or other. So at the front my project code goes: ? Not Debug Incbin "data.zip" ? That means during debug builds it reads resources off the disc and in release builds it reads from the zip. So before I make a release build I use 7-zip and right click the data folder in windows explorer where "add to data.zip" is a context menu option. The final thing to manage is the paths to the resources as they change between debug and release. I always load stuff with a relative path, ie "data/images/image01.png". To find the file in the zip, that becomes "zip::incbin::data.zip/data/images/image01.png". So I wrapped all of Blitz's Load functions (LoadSound, LoadPixmap etc) with versions that will alter the prefix of the file..
Function mbm_LoadPixmap:TPixmap ( fileName:String )
If ( Len( g_mbm_StreamPrefix ) )
Local f:String = g_mbm_StreamPrefix + fileName
f = Replace( f, "\", "/" )
Local t:TPixmap = LoadPixmap( f )
If ( t )
Return t
Else
DebugLog "Image not found in zip stream: " + fileName + "*** (" + f + ")"
End If
End If
Return LoadPixmap( fileName )
End Function
Then I just set the global "g_mbm_StreamPrefix" before any loading occurs, in fact you could add to the other Non Debug specific code from above.. ? Not Debug incbin "data.zip" g_mbm_StreamPrefix = "zip::incbin::data.zip/" ? Of course you can test your incbin'd version in a debug build just by commenting out the compiler directives "? Not Debug" and "?". |
   |