Use: "upx -d bsnes.exe"
![Neutral :|](./images/smilies/icon_neutral.gif)
Yep. SNESGT and no$gba also use it. The latter is interesting, too. You can decompress it with UPX, but it won't run anymore. Somehow the author added protections to the post-UPX'ed executable that verifies the checksum of the program. I'm sure there's lots of ways to do it, and that I could break the check with a debugger, but I don't really care. It's just one more reason not to use that app in my opinion.Last I checked, apps like ZSNES, Snes9x, SNEeSe, bsnes, NSRT, NSRT Frontend, NF DLLs, all used UPX.
There is out there tools that mangle the PE header after UPX has had its fun. Lots of apps use this approach...Daemon Tools/Alcohol 120% (uses this in conjunction with VMProtect), Project64 1.7, Y.A.S.U (a virtual drive cloaking utility)...but as you said, all it takes is OllyDbg with OllyDump, to unpack the EXE, and then rebuild the executable without the protection.Somehow the author added protections to the post-UPX'ed executable that verifies the checksum of the program.
upx makes it simpler:Dullaron wrote:I don't understand why everyone using UPX to compress over compress their program. It doesn't make those to run faster or anything like that. There is nothing special about upx rather than hacking to change the size.
To decompress a zip, use unzip program. To decompress a upx, use upx program.Anyway those of you doesn't want a compress over compress bsnes. http://www.megaupload.com/?d=Y932RPJ0 or just use upx -d bsnes.exe to set the size back to normal.
How can you say it is a protection? I mean what error does it give?Decompress Regen using upx and run it. It will also not run. This does not mean that I have added protection. It just happens to be that when you upx-compress a stripped program (using strip from gnu binutils) it will run fine until you upx-decompress it after which it will not run. Maybe it only happens when one uses MSVC compiler (I didn't check with GCC).byuu wrote:Yep. SNESGT and no$gba also use it. The latter is interesting, too. You can decompress it with UPX, but it won't run anymore. Somehow the author added protections to the post-UPX'ed executable that verifies the checksum of the program. I'm sure there's lots of ways to do it, and that I could break the check with a debugger, but I don't really care. It's just one more reason not to use that app in my opinion.
Nach wrote:In the case of bsnes, it really doesn't make much of a difference once it's downloaded whether it's UPX'd or not.
It specifically tells you that the program was modified, and to re-download it.How can you say it is a protection? I mean what error does it give?
bsnes uses strip + UPX, and you can decompress and run it just fine. I've also used an MSVC build with UPX (obviously without strip involved), and that also works fine. If it's failing for you, then you've probably found some sort of bug in UPX. Well whatever, don't use UPX for your project then.It just happens to be that when you upx-compress a stripped program (using strip from gnu binutils) it will run fine until you upx-decompress it after which it will not run. Maybe it only happens when one uses MSVC compiler (I didn't check with GCC).
I have 3gb of memories and it is enough to run bsnes without worrying about wasting.byuu wrote:Pretend it saves all the memory you want.
But WE don't give a rat's ass about people complaining. >:Dbyuu wrote:Go bug pagefault, TRAC, GIGO and anomie or something. They all use UPX as well.
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
You can generally fix that with editing the binary to enable all memory permissions, like with the utility that byuu once posted here.henke37 wrote:I like upx for a different reason:
It can properly read those not so proper executables that some old compilers created and then output something that recent windows versions will happily run.
Because it sucks when you don't get to play your old games that rivals snes games in age.