Stone's Generic ComFile decrypter! by Independent (IND)
12427 of 48,915 files
-
This download is an executable MS-DOS program that will not run on a modern computer.
It needs a DOS emulator such as DOSBox-X, Staging;
or a virtualized MS-DOS or FreeDOS system.
Browsers may flag this download as unwanted or malicious. If unsure, scan it with VirusTotal. -
Last modified Dec 3, 2017 7:32:40 PM
MD5 checksum 8d77f7cd8b7ba0ef7f3d04620be358c1
Mime type Zip archive data
Download stone generic com file decrypter-stone.zip
Size 5 kB
1997
- Zip - DOS / Computer tool
- Stone, program credits
2 items in the archive
- STNGCMD.DOC
- STNGCMD.EXE
*********** 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! ;>