Is it possible to pack dll too? Or only executable files can be packed? I have searched but I couldn't find any program to do this..
Printable View
Is it possible to pack dll too? Or only executable files can be packed? I have searched but I couldn't find any program to do this..
Most executable packers should be able to pack DLLs as well as EXEs.
The most obvious and transparent one will of course pack DLL, OCX, SCR, EXE, AC, MOD, APP, ACC, DSK, ELF etc.
UPX is truly cross platform, and various modifications of it exist for encryption and obfuscation as well as compression.
I still have to ask... why? What's wrong with marking the "compressed" attribute on NTFS, or using a compressed cloop filesystem on *nix.
Bundling I can understand, and that has really been jumped on by Malware detectors, even though there are perfectly good reasons for doing that. If an executable file is compressed or encrypted, I don't want it on my hard drive. How can my A/V keep me safe if it can't analyse the code?
Bundled executables that don't need to mess with my system configuration and don't need to have millions of files just to run one program, but can still be modular and load sections of the EXE at a time and unload them when they aren't in use is good. (eg. PEBundle) But as I say, almost everything decides that is very suspect behaviour.
I don't get it.
I tried using UPX but it doesnt worked.
I want to obfuscate a dll, I dont want anyone spying my codes lol
And I'd like to use something different from UPX, UPX can be unpacked easily...
Try Winlicense...
or Molebox
Why do you not want me to use your DLL? :ott1: (I'm not using any obfuscated executable... ever!)
Please don't share such executables with us. I know MentaL feels the same way about people putting up packed executables as "developer releases". :ott1:
I guess if you are trying to stop hackers it makes some sense... but actually, it wouldn't stop the lowliest of skript kiddies... it will only p*ss off regular users who get warnings from their A/V, or have their firewall block them from even downloading your client. (BTDTGTT)
[rant]Heuristically, anything which looks like it's performing self-modifying code should be flagged as "malware". If for no other reason than this is exactly what the hardware DEP (requested for from iNTEL by Linux, BSD, IBM, Trust, and many other major players in industry, governments and public interest groups) is designed to stop, because it is one of the biggest threats to personal computing security.
If a system allows this form of self-modification, then it allows self evolving virus, permits malicious code to pass un-noticed by any kind of security which cannot "easily unpack it" (how do you make it easy for A/V to unpack but impossible for people?) and allows data floods to allow malicious code to be run via buffer overrun.[/rant]
There are scripts/plugins/apps for IDA and olly that unpack Winlicense and Molebox, I don't think there proper way do secure dll. If you protecting it from normal players than I guess this will work, every other case this is a fail.
If you planing to do some puzzle for hackers than write packer yourself =P
Other app I might recommend you is dotfuscator.
I wholeheartedly agree with that.Quote:
Originally Posted by Vormav
Remember "normal players" is people who usually don't know what a .dll file is. These are the sort of people who will delete a DLL file thinking "well gee, I never run that so I guess I don't really need it" and then wonder why a program doesn't work.
Obfuscating executable files is only useful for bypassing A/V security. Dumb programs that can't see through encryption is one thing, trying to fool a human being, let alone an organisation of collective human beings who all look out for new forms of protected executables and have the complete opposite reaction to "normal users" where they say "gee, this file is encrypted, so that must mean there's something really interesting in it. Let's all get together and crack this sucker open" is another thing all-together. And that's exactly what will happen.
In actual fact, when targeting a "human" audience executable encryption is far better used as a "honeypot" (see Wikipedia) and encrypt / obfuscate something which is boring and pointless to see how many good crackers you can get wasting their time doing that instead of looking at your more useful securities.:blink:
Compression alone is another issue, it does have a practical purpose in that you can cram more information into less space. (ofc) However, unlike using Zip or Rar or 7zip you don't have a single library which will decompress all your files, you have to include the decompression algorithm in every program you pack. So over an entire application (much less your entire hard disk) there is a considerable overhead.
There is always an overhead in terms of decompressing (or decrypting) an executable as it's loaded into memory, and most of these systems leave a certain amount of "wasted memory" if not a large amount of "fragmented memory" after the decompression is complete. So while the program may seem to operate the same, if it's ever running close to the physical boundaries or dynamically compensating it's self to fit within those boundaries then the effort it has to go to in order to achieve that after packing is considerably greater.
I propose using the Compressed attribute feature of NTFS because, although that compression is relatively simple LZ compression not much more capable than GIF compression, it is a built-in part of your OS. You can create a more capable compressed file-system (like a compressed cloop device in *nix) in Windows by using something like Psimo File Mount Audit Package which already comes with the ability to mount an entire 7zip archive as if it where a folder, (all be it a read-only one) and completely transparently to higher levels of the OS or any programs running within it.
I discovered, very early on, in the late 1990's that DR-DOS was provided by Digital Research with every program comprising that OS compressed with PKLite (that's PKWare PKLite executable compression which has now fallen into abandonware, not the PK Lite Java based SQL engine) and that if I decompressed every one of those programs and utilities and then packed them with Barry Norse' DietDisk (This article describes how it was used, but provides what I believe to be the wrong attribution for the author, I still have a copy if anyone really needs it) I would actually save more space across the entire installation and turbo charge loading times and such even more.
The advantage then was that you could read and decompress small files from your boot floppy faster than you could read a larger uncompressed version, simply because of the slow spin speed of those devices and the time it took to move the heads etc.
When I say these things to people who haven't written their own executable compression or encryption system before, or even (as I have) tried modifying an open-source one like Y0das' Protector (from which most of the others are based in some respect) or UPX, they usually seem to think I'm some kind of genius who has skillz way above those of your average h4ckz0r... well, no. Actually, if I where to take on a role in the hacking community, and I have dabbled in the cracking community, it would become very clear that my "skillz" are below that of a complete and utter nub, and most skrypt-kiddiez can do better than me, far faster than I can. :ott1:
I've read the articles by PT hackers in their own forms and I would say that they are considerably more skilled than I am in this field. They crack open official PT clients (to the point that most of the official publishers have stopped packing game.exe) and uPT / rPT and it's quite clear that they enjoy cracking sandurrs clients more these days because they present a more interesting challenge. (in other words, sandurr has made himself a target, in that respect)
So if the DLL you want to protect has anything to do with PT, don't think it will work to stop hackers.
I suspect the reason sandurr does still include areas of obfuscation is actually nothing to do with hackers, but is a means to ensure his USP against other pServers. Because most of us neither have, nor care to have any interest in hacking, but many of us (sadly) are quite happy to rip off sandurrs developments. :(:
Hence, again, why I say... as a development forum, I would rather not see people trying to spread such protected binaries here. If you want to put them in your client release to users to stop other developers adding your features without any understanding of how the implementation works... I don't necessarily agree with your attitude, but I recognise the poor level of human etiquette that leads to that thinking and accept your decision to do so. And if (like sandurr) you make your own method and don't use an "off-the-shelf" technology, this may then be effective for that purpose.
So... for any reason that this may actually be useful, I would not recommend you use anything but look at open-source solutions and develop those to a point where they are no longer recognisable. In fact, you would probably best only using them as a template for a completely new design of your own.
The answer, then, is still none of them that are already available are suitable. :ott1:
I do share some stuff with the ragezone pple, but there are some features I'd like to keep just to my server... -if I had one-
btw, dofuscator isnt only for .net executables?
Agreed. I'd like to tell server owners how to protect their server, and their code from hackers and leechers.Quote:
Originally Posted by SheenBR
The first thing I would tell them is not to rely of executable encryption. ^_^
If you look at any decent obfuscated executable you will find that most of it is not obscured. Only honeypots and important code is deceptive.
The next thing you notice is that a number of different techniques will be used in different parts of the code.
Finally, if DLLs are used, and if more than one DLL is obscured in the same way, it's nicer to include encryption in the main executable and get the executable to decrypt the executables as it loads them.
Sadly one of the most effective encryption techniques is "salting". This basically means you increase the file size by... say 1000%, meaning that only 10% of the data is actually useful, and the remaining 90% is rubbish. This means an attacker has to start by picking the ice cream out of the bullsh*t.
This is why compression is usually used alongside encryption.
However. Careful use of cryptographic hashing, and anti-debug techniques (something more advanced than using the OS IsDebuggerPresent()) can be more helpful.
An interesting technique (used by both sandurr and QuantumFusion at various times) is to confuse a "disassembler". A good way of doing that is to include jumps or calls to code which is feldacarb placed in the middle of useful code, or make them to invalid addresses in your useful code. Of course, make sure that this code can only be executed under completely impossible situations. For example, after you have detected an irrecoverable error and safely terminated your process... or after correctly identifying that the host OS is 16-bit Windows. (in which case it would not load your 32-bit executable and started executing it to that point anyway)--- EDIT ---
For example, if your debug detection code is obscured from disassembly, and secured with a cryptographic hash which is also hidden from disassembly, in such a way as you can be sure that any attempt to clean out the code which confuses the disassembler will lead to incorrect decoding of a pointer table which will crash your executable in unusual ways... then your code becomes (IMHO) considerably safer from prying eyes, and less offensive to security systems than any automated executable encryption method. ^_^I thought it was... all their hype seems to say it is. IDK if that only applies to MSIL dotNET or also to x86 native dotNET. (something which is possible, especially if you write C++ dotNET not C# / VB dotNET, but pretty much a waste of time and not very popular)Quote:
Originally Posted by SheenBR
Ok, first UPX is not executable encriptor is just a compressor, and is very easily breakable, so dont use it, if u want some encription use that yoda encriptor is very good, or also get some versions of asprotect (both of them rebuild imports table and also encrypt the code) wich is average good. But remember that you must know very well what you doing when encrypting and that security is just a concept not a reality.
So im also agree someway with bob that executable protection is not allways good. but mostly important you will only be able to stop script kids, you cannot stop real hackers.
Anyway im suggest that you have 2 kind of dll's, the ones for client and the ones for server. So then u will not worry much about what happens with client wich will not be that important, and try to enforce highest security at server side.
If were my case i would use for critical improvements on client use as lesser code possible (if possible code in assembler and not use higher level languages) and hide it on bunch of garbage code (not just garbage, just write code that does improvements on doing nothing after all it will not be executed) :p, yeah that salting tech that bob said ;)
The best way to prevent your server methods are not stolen is never publish them and keep physical backups only, and restrict the access to server.
btw.. if u try asprotect dont use asprotect 1.23 rc4 :p im sure that many here knows well how to break it too ;)
which version of asprotect do you recomend?
I recommend you do use it if you use anything because it doesn't encrypt and can simply be reversed completely by the recipient if needed. :lol: The same program works in both directions and is free to all. :ott1:Quote:
Originally Posted by telatoro
However, there are several nasty variants of it which do encrypt, and aren't easily reversible. Boo, hiss.ASProtect is:-Quote:
Originally Posted by telatoro
y0da is better, because it's not commercial, and is open source. So you can re-program the signature and encryption to be unique to your purpose, defeating common reverser and A/V signatures. But it still doesn't defeat generic VM depacker most of the time. :(:
- Commercial, and you can only buy the current version. (use of unregistered version is a waste of effort, cracked or otherwise, and can be an even bigger legal flak magnet than running a pServer already is)
- Always has free availability of decrypters which work a treat, because it is so popular with commercial putz. :ott1:
- Easily reversible with a generic VM Decryptor.
- Frequently flags A/V software, which regularly add the signature of each new version of it, because you can guarantee there will be a virus hidden with it within 24hrs of a new release.
- Not clean, and not secure either. :ott1:
I believe that was the version official servers used to protect their clients with? Yea, we always reversed them the same day they released... If you could be bothered turning your A/V off so you could even download it. :thumbdown:Quote:
Originally Posted by telatoro
--- EDIT ---
Here's an idea. You know how to get packets from the server into memory already yea? Get library code from the server, set the memory buffer executable and use it. (don't leave secure code libraries on clients hard disk) Encrypt your packets as much as you like. :wink:
Or release your code as chip that everyone need to solder to main board?
http://oi54.tinypic.com/282xhe.jpg
Not rly but I don't understand why people protect games in general, usually there is crack faster than you go to shop and buy a game. Its better to spend time and money on them game itself!
Nice.
Actually I've patched out hardware protection in a Parallel port dongle for a CAD program that needed to be run on a laptop which had no parallel port once too. Turned out the program sent a crazy code to LPT1 that any printer should ignore and the dongle sent a decryption key back. (too easy) So I replaced the send and receive code with code which knew the key and just loaded it into the correct place for the decryption code to think it had come from the dongle. (this was back in the days of DOS)
I understand that a large proportion of the executable of newer CD locked games is actually read from the hidden sectors of the disc. Crackers just rebuild the PE image after that code has been read from the CD, and then patch out the code which looks for the optical disc.
Likewise Apples TPM (Trusted Platform Manufacturer?) hardware locking of OS X to Apple hardware hasn't proven very hard to bypass. :/: Microsoft are letting large OEMs activated Windoze by something similar which people flash their BIOS to look like a Dell or Acer or something... and the most popular Vista / 7 activation patches fake the NTLoader (I think) to believing this PC is one of the larger OEMs which get reduced activation security. :$:
I still like to use cracked games. I like to use decent cracks to remove dumb-ass securities on games I buy. :ott1:
Anything that makes it difficult to cheat is good. Anything which causes players problems is bhad! And I'm afraid any off-the-shelf executable locking will flag at least one Anti-malware program that some players will use. :(:
I don't believe the overhead of teaching those players how to set an exclusion for your game and assuring them all that even though your game flags as malware it isn't, is ever worth it. Someone independent would have to remove the protection and analyse the program running without it to be confident that nothing malicious lives inside.
So you've only encouraged people to examine your code more closely and reveal what they have discovered.
I liked the DRM of the 90's
"Please do not copy this disk/floppy" Printed on the cd or floppy disk XD
Someone is remembering the past with rose coloured spectacles. (see CAPS project from the Software Preservation Society)