What would be the best way to protect a file from being disassembled, or from getting the source from the PE file?
Is there a way to encode the file so it would be really difficult or impossible?
It's impossible to encode a file some way that it could never be disassembled... you could toughen it up by packing it (ex:Aspack.com) but this won't prevent unpacking it tho :(
There are some common anti-disassembler tricks but these are quickly anhilated too...
btw: how do you get the source from an pe-file?
try encrypting the file an decrypting in run-time , if you dissasembled the file you will se the decryption routine and encrypted program ...
include also some anti-emulation/debuggin rotines to fuck up the emulators/unpackers/tracers ...
it is impossible a 'perfect protection' but you can make it harder ;).
search for more tricks on the net.
I know ASPack is eaisly decoded, does anyone have any expirence or know how to protect against disassembly? Is there any software or websites that would help?
Yah what are some of the common tricks used? Like a high percentage of disassembled programs are disassembled by newbie wanna-be hackers, who don't know much. And anyone with the experience to do anything real won't want to hack my programs anyhow so the basics should be fine.
I've heard some things, like using a hew editor to put illegal values in the resource area of the exe so resource editors can't get it. I've also heard of putting illegal instruction codes in places on purpose which you jump over but the average newbie won't figure out. Or an invalid opcode.
Does anyone have any advice? Even the simplest most easy stuff?
Thanks,
Ben
i have been cracking for over a year an yea only wanna-be's will want to attack somthing really easy. I'll i have to say is if you want to learn to crack and just solve crack me's to get an idea of cool pertections. the best crackme site i can find is http://crackmes.cjb.net/
nothing better than using what you learned.
hope it helps
-rage9
Futur belongs to open sources. The best way to preserve your
marvelous work from others sight is to keep it for yourself
only and publish nothing at all.
betov.
Ehm... I announced the anti-disassembler tricks but forgot to provide the link (*DOH*) Here it is:
http://www.woodmann.com/fravia/snatfo.htm
Of course... have a look around here too :) :
http://www.woodmann.com/fravia/protecti.htm
JimmyC
With PE files, a memory dump will beat most packers/crypters, it is useful to get the PE header directly from the PE file on disk as it can easily be changed once the file is loaded.
Most anti disassembly tricks get beaten over time so all you buy is a little time, PE files are understood very well these days so there is not much that cannot be done with them.
Anakin has a novel PE cryptor on Kaparo's tools site which encrypts the import table so a memory dump does not get the imports but it gets the rest. It really depends on how much work you want to do and how much time you want to buy but most will be broken by someone who knows what they are doing.
Regards,
hutch@pbq.com.au
You could have self-modifying code. One anti-cracker technique I thought was neat came from the DOS era... For example, you could have int 13h (in hex it would be: CD 13) You could do something like change the 13 to some other number like 21.
Then, once your program runs, it could replace that one modified byte with 13!
In the world of Win32, you could do similar stuff. One trick I thought of (but never tried) is to mess with the indirect calls. For example, you could import a bunch of DLL functions. One line of code could be: CALL
You could change the address refered to by that CALL to point to some other DLL function import. Then, when viewed under a disassembler/debugger, it would appear to be: CALL
I wonder if anybody's actually tried this trick before.
If your program is infested with tons of code that are modified in this fashion, it could make it pretty hard for an impatient newbie cracker to deal with.
---------------------------
Team2k PC development team:
http://ppilot.homepage.com
I agree with the last post -- SMC is a good strategy.
Disassemblers like IDA can't cope with SMC. They'll just replace the old asm instructions with the new ones corresponding to the new code, the old code having been overwritten. As a result, the asm listing will omit all information not contained in the latest "go".
Make your code section(s) writable and use a block of code that you overwrite many many times. Calls to system dll functions are unrestricted, but make sure that the current block doesn't call any of your own routines that are not already resident in the block. In practice, this means writing in-line code where possible. Also, you wouldn't want to split For or While loops etc. between blocks (too inefficient, you might have to reload code back and forth hundreds of times).
What I do is analyze my own asm code to package the crucial parts into self-contained blocks. When one block has executed, it is overwritten in place by the next block (possibly of a different size). This analysis can be tricky, requires some modification of the code, and has to be done by hand (there's no straightforward way to automate it), but it becomes easier if you appropriately adjust your coding practices.
mmh, i tryed to do something like a exucutable that encrypts itself everytime it it started with a different encryption key. at the first run it decrypts itself with xor_code 0 so you could paste your code without any problems, then it will increment the xor key after every start with 8. i still stuck on writing to the running exe and i have no clue why this could be prohibited in windows... whatever, the second problem is to relocate the writing address, i think you can do this with the help of the innstruction pointer but i don't know exactly. if someone could tell me how to gain write access to the running executable i would be very lucky (in dos this was possible without any problems because the data is transfered into mem at start...)
.DATA
dummy db 0
old dd PAGE_EXECUTE
.DATA?
thisfile db 300 dup (?)
filehandle dd ?
written dd ?
.CODE
start: call real_prog
real_prog proc
pop esi ;current ip
lea eax,end_of_code
sub eax,offset start
invoke VirtualProtect,addr start,eax,PAGE_EXECUTE_READWRITE,addr old
return: lea edi,start_of_code
lea ecx,end_of_code
sub ecx,edi
mov al,xor_key
decrypt: xor byte ptr ,al
inc edi
loop decrypt
cmp dummy,1
jz exit
jmp start_of_code
xor_key db 0
start_of_code: ;-----------------------
;REAL code goes here...
mov dummy,1
add xor_key,8
jmp return
end_of_code: ;-----------------------
invoke GetModuleFileName,NULL,addr thisfile,SIZEOF thisfile
invoke CreateFile,addr thisfile,GENERIC_WRITE,0,NULL,OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,NULL
cmp eax,INVALID_HANDLE_VALUE
jz exit
mov filehandle,eax
invoke SetFilePointer,filehandle,0441h,NULL,FILE_BEGIN
;don't know if 0441h is right i used a hexeditor for this
;maybe esi should come into the game here
lea eax,end_of_code
sub eax,offset xor_key
invoke WriteFile,filehandle,offset xor_key,eax,addr written,NULL
invoke CloseHandle,filehandle
exit: invoke ExitProcess,NULL
real_prog endp
END start
Another anti-dissasemling trick is to 'hide' your instruction code inside other opcodes i.e
jmp @F
BYTE 43
@@:
mov eax,Offset MemVar
Dissasmbly:
00401000 EB01 jmp loc_00401003
00401002 2BB800204000 sub edi,
It is intresting and it works. Of course any half awake person would notice the jump to the middle of the instruction stream so a better implication would be nesscery or it would be noticed 'to' easy. This combined with a good encyption of the code section will make things more difficult.
But you have to remember, the only real protection against cracking, dissambling, whatever....is to take the only copy of your app, and burn the computer it resides on, simple as.
a nifty little trick to add to SMC is to use the "unused" (in .EXE files atleast) .reloc section for thedecryption routine...;) kinda like encrypting your .reloc section win 0x123456-0x4000000 (or whatever) then changing you base adress in the header to 123456
umm here's the article i found about it... virus related but usefule..;)
Encryptation through relocs
Until now relocs section (.reloc) has been very useful (curiously by useless)
for virus coders. Why? Virus coders overwrite it to hide an increase of size
after the infection. Nothing to worry because when Windows loads an
executable it gives a new virtual address space and it will be loaded into
the base address indicated in his header and it's not necessary to apply the
relocs. That's the reason why by default some compilers don't include the
.reloc section except if you tell the contrary. Of course, it doesn't happen
the same with DLLs since it's more common they have their base already
busy (at least it's already loaded the executable and usually there will be
other DLLs) then it will must to be loaded into other base address and
applied new relocs based in the new base.
Let's see what happens when a module is loaded into another different base of
the indicated in the header and it's needed to apply relocs; each entry in
the relocs table point to the addresses of the module that are needed to be
reseted. To the content of each of these addresses is subtracted the indicated
base in the header (since it's already reseted respect to that base) and it's
added the base where it has been loaded really.
Other fact we will use is that if to an executable we put a base where we know
it will not be loaded, Windows by default tries to load it at 0x400000.
Taking care of all these, we are going to get encrypted a virus and the own
Windows will decrypt it, i mean, it will not be needed any decryption routine.
First, we need the host having his base at 0x400000 and we need to null his
relocs (if it has any). Now we change the base to the executable for one we
know Windows will not accept, per example we take 0x12345678. With this we
will get Windows loading the executable at 0x400000 and applying the relocs;
It's due to that we have nulled the relocs of the host since finally it's
being loaded his choosed base.
Now we create a new .reloc section pointing each DWORD from the body of the
virus and we encrypt every DWORD of the virus in the next way:
DWORD virus + 0x12345678 - 0x400000
We do that since when Windows loads the executable at 0x400000 what it will
do will be subtract the header of the base (0x12345678) and add the real base
(0x400000).
This way: (virus + 0x12345678 - 0x400000) - 0x12345678 + 0x400000 = virus;
We've gotten Windows finally decrypting our virus and then it's different
to how it was in disk without execute any instruction (it's only needed
whereupon it has been loaded into a debugger per example :-)
In NT there are limitations to the use of this method since it doesn't want to
load the executable if it finds a strange base (i believe it must to be
multiple of 64KB).
Tcp/29A