ASM Community

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?

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?

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

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

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

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

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