Stone's Generic ComFile decrypter!   by Independent (IND)

*********** DISCLAMER ************ Warning - this program is a disaster waiting to happen I take no responsibility for any damage caused by the program or sourcecodes supplied in here. That goes for both direct and consequensial damage - use it at your own risk! *********** DISCLAMER ************ Stone's Generic ComFile decrypter! **************** 1.0 List of Contents **************** 1.1 Introduction 1.2 Usage 1.2.1 Standard usage 1.2.2 Things to avoid 1.2.3 Error Messages 1.3.1 Tested on 1.4.1 Alternative uses 2.1 Technical breakdown 3.1 Known bugs, problems, insufficiencies...(sometimes suggested solutions) 3.1.1 Stack error? 3.1.2 PSP not created 3.1.3 "Selftracers"/int1vector problems 3.1.4 The traceflag 3.1.5 Image size calculation 4.1 Greetings, contacting... **************** 1.1 Introduction **************** A while back I wrote a .com file encrypter and released the source for it. I had a pretty good respond on it and I decieded to write a exe-file encrypter. Both these projects were done for my personal education, not with the purpose of releaseing anything. Anyways both was released with full source and an explaining doc along with it. Last night I had a couple of minutes before I had to attend soccer practice and I just had an idea about how to make a generic .com file decrypter. So for personal education I started programming it. Anyways a couple of hours worth of programming and it was done. And again as always - I release to you the source and a document about how it works. To all those who've written me with encouragements - thanks - you're the reason I share! The most important thing I can stress about this comfile decrypter is: IT IS NOT INTENDED FOR USE - IT'S INTENDED FOR YOU TO LEARN FROM If you wanna unpack comfiles I refer you to: Cup386 by Sage/UCF or other programs ARGH! No bitching - I'm not a freaking coder! ;) **************** 1.2 Usage **************** 1.2.1 Standard usage As always I'm a lazy mofo - so I made no userinterface whatsoever the way you use it is: You copy the file you want decrypted to input.com in the same directory as stncmd.exe and then you run it. The decrypted file will be in output.com 1.2.2 Things to avoid While it is possible to run it with a debugger loaded it might not be a good idea - it may be the cause of conflicts between this and the debugger and might cause random "breaks" of the debugger (atleast my winice sometimes act up on me when I'm running this and debug.exe will freak for certain - though one experienced with using debug.exe will know how to deal with it) Do not attempt to undecrypt/unpack files that are not encrypted - that might cause your machine to chrash. Attempting to unpack files that uses "selftracing" or programs that otherwise uses protection that utillizes int1 will cause your machine to act wierd, crash, spontaniously combust, or just mal function. In general this program is highly unstabile and might cause errors or chrashes. 1.2.3 Error messages The program can come up with 3 different error messages: 1) File input.com NOT found - terminating means that for some reason stncmd could not find input.com or the file was locked by another process or something. Stncmd will terminate! 2) Unable to Create file output.com - terminating Means that an error occured while creating output.com - there may be many reasons why this is. StnCmd will just terminate. 3) An error has occured while reading input.com - terminating This is pretty self explanatory. 4) File is too big - either illegal com file or use CUP386 to unpack Due to a problem with my imagesize calculation routine files are limited to be less than 57344 bytes large. It's also worth while remembering that real comfiles are no larger than one segment - that is less than 65279 bytes large. For now I have quite a few ideas how to solve this problem but I've not bothered to implement it yet since it's really irrellevant because such good programs as CUP&GLTR exists and the few encrypters they don't unpack are often supported by special unpackers as you'll find them released by your very favorite group: UCF :) 1.3.1 Tested on I've only tested the decrypter on Stone's comcrypter v1.0 (C) Stone 1996 Pklite (C) 1995 PkWare *) Important: See also 3.1.5 I tested it on a large number of old trainers I had lying around - in all but 2 cases it unpacked the file. I then inspected the 2 cases it could not unpack and found that both of these two trainers used selftracing/other int1 techniques On the bad side I also experienced that generally the files were unpacked but too much of the memory was saved! :(.. See 3.1.5 1.4.1 Alternative uses A possible alternative use is that of virus disinfection. As the program is now it'll be able to remove a virus from a comfile - given that the virus is a non-overwritting .com file virus. However it's worth noting before venturing in to this use: 1) Resident virii's might reinfect as the file is saved 2) The virus will be run during disinfection and thus might cause further damage to other files or load it self resident! 3) Only the code that sees to it that the virus is executed is removed not the virus body itself - thus some scanners will still sound an alarm on the file - see 3.1.5 4) Some virii contains self-tracing code see 3.1.3 This was tested on: Stone's unreleased polymorphic comfile infecter Dark Stalkers unreleased polymorphic comfile infecter :) - thanks to DS for Sharing his work and thanks for not letting it become a "wild" virii. **************** 2.1 Tech Stuff **************** I'll in the following assume that you know the basics of encrypting a comfile. And have some prerequisits in assembly language programming. The hole idea of the program is using the x86 debugging feature: Tracing. By turning on a flag in the flag register the x86 generates an int 1 after the execution of each instruction. By intercepting this vector, turning on the flag and then running the program - while keeping an eye on when the decryption is done we can decrypt a comfile using it's own decryption algorithm. So... How is this done? First we load the input.com into the otherwise empty datasegment. Then we hook interupt 1 and installs a handler. After this we setup the segment registers doing like this: mov ax, @data sub ax, 10h ; adjust for missing PSP mov ds, ax mov es, ax This means that @DATA:0 is the same linear address as ds:100h in this way we we can jump to ds:100h and the comfile will be executing as it would've had it been loaded by dos (For a elaborating comment on this see 3.1). However before we let the program run we turn on our tracer so int1 is called each time an instruction is processed. What we do in this interupt is that we see if the return address is 100h (The starting offset of a comfile!) this will obviously be true for the first instruction so I've build a mechanism that will ignore it the first time. However the second time we run thru this address it's because the decryption program has turned back the control the the unpacked comfile. At this point all we have to do is save the datasegment in output.com. **************** 3.1 Bugs and stuff **************** 3.1.1 Stack error? - Fixed (I think) I suspect that I've made an error trying to make the comfile-decryption routine have the same stack as it would've gotten if dos had loaded it. e.g. SS=CS. This might be the cause of serious problems! 3.1.2 PSP not created! - This will be fixed for version 1.01▀ Unlike when dos loads a program I do *NOT* make a PSP for my comfile - this is a problem that with out too much trouble could be dealt with. However it should only prove to be a problem should the decryption algorithm use the PSP. I have yet to see a comdecrypter that uses the PSP! (Well I have: pklite) Programs that exit thru int 20h on error uses the PSP there in that int 20h restores the error handler as it's found in the PSP. But hopefully I allocated enough memory so it won't be a problem!.. Dealing with this problem shouldn't at all be hard.. Actually to be very thourough not only the PSP isn't created a MCB should be created as well in the very extreme case that the com-decryption algorithm should use it. 3.1.3 Selftracer/int1vector problems "Selftracing" or other decrypters that take use of the int1 vector will surely cause stncmd to chrash or behave very strangely. Imagine this code xor ax,ax mov ds,ax mov [0004], newint1vector mov dx,5555h While this in a comdecryption routine would work perfectly it wouldn't when the tracing flag is set because only half the interupt vector would be set and a call to some random address would be issued... Avoiding this problem is possible - however dealing with it was beyound the scope of a "late night after soccer" project. If you need to unpack comfiles with selftracing/int1vector protections I refer you to other programs: CUP386 by Sage/UCF or GLTR by Hendrix/Obsession 3.1.4 The traceflag The traceflag is "vounerable". The program can fuck with the traceflag a cause the decryption to fail. This can with relative easy be interveened with since the pushf/popf instructions can be jumped over thru return-stack manipulation. E.g. ... mov bp,sp mov bp, [bp+10h] cmp byte ptr [bp],09Dh ; 9Dh=opcode of popf (I think :) ) jz jumpinst popa iret jumpinst mov bp,sp inc byte ptr [bp+10h] ; jump one byte further! popa iret That is a very crude way of doing it... but it could be enhanched with some effort! Obviously you'd need to build a defense of the int 1 vector too! 3.1.5 Image size calculation At best my image size calculation routine stinks. How does it work? It works by before loading filling the data segment with something identifiable: 0a9a9h Then after unpacking it takes the file size and multiply it by 4, moves this far into the datasegment and starts searching backwards until it no longer finds these 0a9a9h's. This position is then used to identify how many bytes must be saved. The problem with this way of doing it is: on simple decryption schemes we save too much - that is we save part of the heap where the decryption routine is stored. On large files we cannot multiply the filesize by 4 and expect it to be with in the segment!! **************** 4.1 Greetings etc. **************** 4.1.1 You may use this program and the source code free of charge, you may even modify the sourcecode to that of your needs if you give me proper credit in your own work. (Email address must be included) 4.1.2 I may be reached thru email at: [email protected] - I love hate mails - I love bugreports - I love suggestions - and.. I love getting positive feedback - that is the only reason I release this stuff.. if I didn't I'd keep it to myself! 4.1.3 Greets to: UCF, Klan, Patriarch, Mr. Mox, Gdd, yrreb & #Cracking on EFFNET ^2nd! 4.1.4 Creditz: Thanks to Patriarch for the idea to the current crude but working imagesize determination algorithm UCF ROOOLz 1997! ;>