informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
278a90f7ce
textfiles/virus/g2.txt

565 lines
25 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
Phalcon/Skism's G<> 0.70<EFBFBD>
The Second Generation in Virus Creation
Written by Dark Angel
January 1, 1993
"Where do we think up these cheesy names?"
-Dark Angel
TABLE OF CONTENTS
TITLE PAGE i
TABLE OF CONTENTS i
DISCLAIMER i
PURPOSE ii
FEATURES ii
RESTRICTIONS iii
RUNNING G<> (HOW DO I GET THE DAMN THING TO WORK?) 1
G<> HAS THE POWER 1
STILL NO IDE 1
MODIFICATION OF GENERATED FILES 2
UPGRADES 2
ADDITIONAL G<> FILES 3
PROBLEMS AND FUTURE IMPROVEMENTS 3
CONCLUSION 4
HISTORY OF VIRUS TOOLKITS A
DISCLAIMER
G<> is hereby released into the Public Domain, and may not be sold or
marketed in any form without the permission and written consent from the
author. The author retains all copyrights to this program, in either the
original or modified forms, and no violation, deletion, or change of either
the copyright notice or this disclaimer is allowed.
G<> and the source code generated by said program are not to be used in
any malicious or otherwise irresponsible manner. The author is not
responsible for any damages, incidental or otherwise, resulting from
running either the core program or any programs generated by it. The
program itself is not designed to be damaging and responsibility for proper
usage and containment of any code created by the program (either modified
or unmodified) is entirely placed on the user of G<>. All source code and
executable files generated either entirely or partially with G<> may not be
distributed without the recipient's full knowledge of the contents.
Malicious use of this code is malicious.
G<> is guaranteed to exist for five years or 50,000 miles, whichever
comes first.
i
PURPOSE
G<> is NOT a modification of the Phalcon/Skism Mass-Produced Code
generator; it is a complete rewrite and functions in a radically different
manner. There will be no further releases of the PS-MPC, as the project
represented the amoeba-stage of virus creation.
G<>, Phalcon/Skism's newest virus creation tool, is designed to allow
everyone easy access to computer virus source code. More than a simple
Vienna hack generator, it creates viruses "on-the-fly" as per the user
specifications. G<> is designed to be easily maintainable and extensible
through the use of special data files created especially for use by the
program.
G<> arrives after the Virus Construction Lab and the Phalcon/Skism
Mass-Produced Code generator. These two excellent code generators have
several shortcomings inherent in their design. First, they only create one
specific virus given a specific configuration. Their design allows for no
variability in code generation. Second, upgrading the generated code means
getting a new COM or EXE file. With the overhead of the IDE code in VCL,
this means redownloading over 100K each release, most of which is
redundant. Although the PS-MPC is much smaller and certainly better
written, it still suffers from the same lack of simple upgrades. The
problem arises because the data needed by the programs for code generation
are hard coded, and not in easily updated external files.
G<>, of course, has none of the problems associated with earlier virus
generators. Designed with configurability, variability, and upgradability
in mind, G<> represents the current apex of virus generation.
FEATURES
The target audience of G<> includes both novice and advanced
programmers alike who wish to learn more about virus programming. A
revolutionary tool in virus generation, G<> is both easy to use and
unparalleled in performance. As a code generator, it has a number of
features including:
o Easy updates via data files.
o Accepts MPC-compliant configuration files.
o Different viruses may be generated from identical configuration files.
o Small executable size, allowing for speed during load and execution.
o Still no IDE - edit the configuration file in your favorite editor and
rapidly generate new code; no need for lengthy wait while IDE loads,
allowing you to work faster and have results quicker. A definite
productivity bonus!
o Rapid generation of code, once again allowing for fast results.
o Low memory requirements.
As a virus creation tool, it has the following features:
o Generates compact, easily modified, fully commented, source code.
o COM/EXE infectors.
o Resident and nonresident viruses.
o Supports multiple, semi-polymorphic encryption routines (full
polymorphism coming soon).
o Easily upgraded when improvements are needed.
Clearly, G<> is the most advanced virus code generator available today.
ii
RESTRICTIONS
Everyone is free to use this program at no charge except for ex-Senior
Engineers of Data Plus, who must pay off the American national debt in
order to use this program or view the documentation beyond this page (only
one or the other). Payment of the American national debt and a sum not
less than said debt to the creator of this program is necessary for the
privilege of both using the program AND viewing the documentation. Failure
to do so will result in a still penalty.
This program and this document are copyrighted materials of Dark Angel
of Phalcon/Skism. No one may duplicate the document in printed form,
either in part or in full, without an appropriate citation. Ex-Senior
Engineers of Data Plus are not allowed to duplicate either the program or
the document in any case.
IF YOU ARE A SENIOR ENGINEER, STOP READING NOW. IF YOU ARE OR KNOW OF A
SENIOR ENGINEER WHO HAS VIOLATED THE RESTRICTIONS, THEN IT IS YOUR MORAL
AND CIVIC DUTY TO CALL THE SPA, ASP, PSA, PAS, OR ANY OTHER ORGANIZATION
WITH SOME COMBINATION OF THOSE LETTERS TO REPORT THE VIOLATOR AND TO MAKE
SURE HE OR SHE IS PUNISHED TO THE FULLEST EXTENT UNDER THE LAW.
iii
RUNNING G<> (HOW DO I GET THE DAMN THING TO WORK?)
Make sure that the G2.DAT file is in the current directory. Edit the
configuration file to set the desired parameters. Then use the following
simple command to generate the assembly code:
G2 [<datafile>] <configfile1> [[<configfile2>] ...]
Datafile is an optional parameter which allows G<> to use other data
modules in lieu of the default (G2.DAT). Configfile refers to the name of
the configuration file which G<> uses to determine the characteristics of
the generated virus. The sample configuration file, G2.CFG, contains all
the information you need to generate your own virus. There can be any
number of configuration files following the first parameter. Once invoked,
G<> will dutifully create the source code files. To assemble, simply follow
the instructions found in the source code files. The source code is
written for Turbo Assembler and will not work with other assemblers without
modification.
EXAMPLE:
Let's say you have created a configuration file called FOOBAR.CFG and
wish to generate a virus from it. Simply type:
G2 FOOBAR.CFG
and the deed is done. It doesn't get much simpler than this.
EXAMPLE:
Let's say you wish to create viruses from the data file BLIP.DAT and
the configuration files BLOP.CFG and BLUP.CFG. At the DOS prompt, type:
G2 BLIP.DAT BLOP.CFG BLUP.CFG
Two files will then be created.
G<> HAS THE POWER
The key to G<>'s power lies in its flexibility in code generation.
Source code files created by G<> from identical configuration files almost
always differ in both size but not in functionality. G<>'s data files allow
for multiple code segments for each given routine. Additionally, the lines
of assembly within each routine may be placed in different relative
positions by G<>. Consequently, few code segments are stable and it should
therefore be tough to find a generic scan string for G<>-generated viruses.
Finally, since G<> operates with easily-upgraded data files, any such
generic scan string is guaranteed to have a very short life, i.e. until the
next release of the data file. As more routines are added, the number of
possible viruses will grow exponentially, thereby making a generic scan
string approach unwieldy, if not impossible.
Aside from the inherent power of the code generator, the data file is
also an integral part of the G<> package. Since it is written in the G<>
metalanguage, it is easily upgraded and maintainable. It is an easy task
to redesign the structure of the viruses generated by G<>; it's a simple
matter of rearranging the various routines. This allows for both more
variety in the generated viruses as well as increasing the difficulty of
finding a single generic scan string for G<>.
STILL NO IDE (INTEGRATED DEVELOPMENT ENVIRONMENT)
"
Everyone agrees that Microsoft Windows is for cripples. Obviously,
you, the user of the PS-MPC, are no cripple, so you need no puny IDE with
colourful, deluxe windows to aid you. If you are a cripple, go ahead and
1
create the configuration file in your favorite Windows text editor. Hell,
port the code to the Macintosh and you can be truly crippled (although
you'll have your pretty windows and icons).
"
- From the PS-MPC documentation
Creating an IDE nowadays is merely an exercise in running a package
designed for generating a snazzy interface. Naturally, this is entirely
unnecessary and may not even be wanted in many instances, as an IDE adds
tremendous amounts of extra code accompanied with a tremendous decrease in
execution speed. It's pretty stupid to put an IDE in a code generator;
there's simply no need.
Several analogies come to mind. The first, of course, is that using
an IDE is akin to a walking person intentionally crippling his own legs or
a sighted person poking her own eyes out. Using an IDE for no reason is
like sitting on a porcupine, bashing yourself over the head with a brick,
or jabbing yourself in the belly with a hot poker for no reason; it's just
not a good idea.
You want Windows compatability? You want customizable colours? You
want CUA/SAA-compliant pull-down menus? Then go write your own interface.
You want speed? You want tight code generation? You want to learn how to
write viruses? Then G<> will do the job nicely.
MODIFICATION OF GENERATED FILES
You are encouraged to alter the generated source code files. You may
add to the code in any way except for the addition of malicious code.
That's a no no and is frowned upon. The source code is commented for easy
modification. Everything is open for modification except for the creation
signature string, [PS/G<>]. Leave it in.
Note that G<> includes absolutely no destructive routines in it. This
ensures that those who use G<> must do the dirty work themselves. Any knob
can write a hard drive trashing routine or rip such a routine out of a
trojan; heck, any programmer worth his salt can write one in his sleep.
Remember that G<> is designed not for destruction, but rather for learning.
In the hands of a knowledgeable user, G<> may be quite powerful.
UPGRADES
Although the G<> package is designed as a virus creator, it is really a
generic code generator. The G2.COM file processes the G2.DAT data file to
create the virus. The executable contains no inherently virus-oriented
data; it is all contained in the data file. This is the key to G<>'s power
and ease of upgrade.
Thus, two types of upgrades are possible with G2: code and data file.
Code file upgrades refer to changes in the G2.COM file itself. This will
occur periodically as improvements are needed. Data file upgrades are
changes in the G2.DAT file. Note that data files are NOT and will NOT be
compatible across different versions of G<>. This is to allow for
improvements to the file format which may be made during a code upgrade.
Each release of the code file will be accompanied with a new release
of the data file. This does not necessarily mean that the data module is
improved; it is simply a convenience to the user. The filename of G<> code
file releases will be of the format G2-CXXXY.ZZZ where XXX is the version
number, Y is either blank or a 'B' to designate a beta release, and ZZZ is
2
the extension of the appropriate archive format. The filename of data
upgrades will be of the form G2-DXXXY.ZZZ where XXX is the version of G<>
the data file is to be used with, Y is a version number of the data file,
and ZZZ is once again the extension of the appropriate archive format.
This naming scheme is subject to change without notice.
ADDITIONAL G<> FILES
Note: This is not to be confused with the files generated by G2.COM during
the course of normal operation, which are to be used freely by the user of
G<>.
Due to the nature of G<>, there are several files which may eventually
be made available. The first is the compiler module, which generates the
G2.DAT file from several data files. Along with the compiler module will
be the data files themselves, which hold the virus code definitions used by
G<> in creating source code. These will not be made available for some
time, at least until the data module format is stable and I've made pretty
much all the improvements that I wish to do. Target version number for
release of these files is 35.2.9.31(3), although this may and will be
changed at will and without notice.
I am not releasing the source code at this point simply because of all
the hassle I went through after releasing the source to the PS-MPC. The
numerous complaints received from people who couldn't compile it properly
(due to improper setting of compiler switches) showed that it is difficult
to distribute a product in this form. For those that are interested, G<>
was written using Turbo C 2.0, an excellent product indeed and the source
code was tested with Tasm 2.5.
PROBLEMS AND FUTURE IMPROVEMENTS
I'm much happier with G<> and have put more heart into programming it
than I had with the PS-MPC. Although I was initially excited with the
possibilities of the PS-MPC, it was intrinsically limited and I soon saw
that it would grow too bulky to keep up. So I thought up of the idea of
the data file and so far it's been working pretty well.
Although this program was written with less frenzy than the PS-MPC,
(it took 3 days versus the 2 for the PS-MPC) it may have a few remaining
problems, hence the preversion 1.0, beta designation. The processing of
the configuration file is not contained within the data file; I wish to
change this sometime. Additionally, I wish to add a bit more functionality
and variability into the code generation before version 1.0. Further
control of the code generation and a batch creation mode will also be added
before version 1.0. A few tidbits to look for: true polymorphism, boot
block/partition table/SYS infectors, stealth features, more commenting, and
improved speed in data file and source code generation.
If you should find problems of your own (euphemism for bug), then make
sure you tell me what is wrong and it will be fixed as soon as possible.
If you have a suggestion for an improvement in the code, or even have
alternate code fragments, then send them to me and they may be incorporated
into subsequent releases of the data file.
If you should further run into any problems in learning how to use G<>,
then be sure to get word to me. Even post it on FidoNet if you wish; I
don't mind feedback in a public forum. Although I will not stoop to the
level of a GUI-making, toolkit-using programmer-drone, I will try to make
using G<> as simple as possible and may possibly release a tiny shell which
3
will automatically place the appropriate parameters in a configuration file
suitable for use with G<>.
Of course, if you have any positive comments, feel free to post them
anywhere I'm likely to be; either leave me email at a particular board that
I frequent (make sure it's the right Dark Angel) or leave a public message
on FidoNet or another net that I am likely to read. Don't be too critical
of ex-Senior Engineers; they have nothing better to do than bash virus
writers.
CONCLUSION
G<> represents a new level in modern virus creation. Although nothing
can possibly beat either the quality or the thrill of a hand-crafted virus,
the viruses generated by G<> are quite powerful and useful for learning how
to write your own viruses.
Where does it go from here? Only ex-senior engineers of Data Plus
have been entrusted by the government to know this secret information.
However, secret agents have infiltrated the tight safety net surrounding
said senior engineers and this knowledge will be made publically available
at the appropriate time.
4
HISTORY OF VIRUS TOOLKITS
Note: The original text from which this was based, the PS-MPC
documentation, has been copied extensively by journals such as Virus
Bulletin and presented as their own text. If you copy the text, it is
expected that you cite the source. It's not very nice to plagiarize and
your mommy might scold you if she knew what you were up to.
The first known virus toolkit was called VCS, or Virus Construction
Set. This program generated a new virus each time it was run. However,
there were no code differences at all between any two viruses generated by
VCS. All viruses generated were 1077 bytes in length and all could be
detected with the identical scan string. The advantage in this approach
was that the user needed absolutely no knowledge of 8086 assembly to take
advantage of this program. This program of limited usefulness spawned only
one well-known variant called Manta. It is hardly worth mentioning here.
The second virus toolkit was CrazySoft, Inc.'s Dark Avenger Mutation
Engine (MtE). This magnificent work of Bulgarian coding allowed virus
authors to create viruses with an almost limitless number of decryption
routines. Although the author needed to know how to write 8086 assembly
code, no knowledge of the inner workings of MtE save the entry parameters
was needed to use this toolkit. It has since spawned several viruses,
including Dedicated, Pogue, Fear, and Groove.
The next virus toolkit to be released was VCL, or Virus Construction
Laboratory. This was written by NoWhere Man of NuKE. This toolkit allowed
the user many options, including the creation of parasitic COM infectors,
overwriting COM/EXE "infectors," spawning EXE "infectors," trojan horses
and logic bombs. The only thing missing from this motley assortment of
formats was the ANSI bomb. Since it could handle parasitic infections only
of the COM file format, it was of limited usefulness. Additionally, it
incorporated only one decryption formula, once again limiting its
usefulness. Further, the initial release included a quirky installation
program which failed to install properly under certain conditions. An
errant pointer probably contributed to another bug, which occasionally
caused garbled source code to be produced. Perhaps the worst bug of VCL
was the failure of some of the generated programs to work properly. On the
bright side, however, this package contained a colourful IDE loosely based
on the Borland interface. This IDE was easy to use and even the average
Joe could understand how to use it without understanding 80x86 assembly.
Unfortunately, the activation routines included with the package were of
limited usefulness. Most of these involved manipulating the BIOS memory
area at segment 40h and seemed to be mere afterthoughts, rather than
planned "features." Virus researchers quickly dismissed VCL's importance,
as it was primarily an overblown Vienna hack generator and incapable of
generating dangerous viruses. The Vienna ancestry of VCL was apparent in
many of its "options" such as virulence rate and PATH= tracing. The F-Prot
which existed during the release of VCL immediately scanned most viruses
created by VCL as Vienna hacks. VCL 2.0, so far merely vaporware, is
rumored to fix the previous version's many problems. However, the package
will continue to be haunted by its ancestry and its inherently crippled
nature due to being a first generation virus creator.
The latest virus toolkit was the Phalcon/Skism Mass-Produced Code
generator (PS-MPC). Released shortly after VCL, this product, written by
Dark Angel, had none of the problems associated with VCL. Although this
virus generator didn't create overwriting COM/EXE "infectors," spawning EXE
"infectors," trojan horses, or even logic bombs, it could handle parasitic
COM and EXE infectors with ease. It also had a random
A
encryption/decryption algorithm, allowing well over 150 possible routines
in that area. Version 0.91<EFBFBD> incorporated both resident and nonresident
infectors. No previous virus toolkit could generate resident viruses,
generic or otherwise. Further, the PS-MPC had no IDE to cripple the user,
clearly an advantage, as the program lacked the overhead associated with an
IDE. Thus, the PS-MPC was a good tool for learning how to write viruses as
well as an excellent method of creating good viruses. The PS-MPC was not
intended to be used destructively; no destruction routines were
incorporated. Therefore, irresponsible dissemination of destructive code
was not initiated; rather, it left the activation of the virus up to the
user. Interestingly, although released soon after VCL 1.0, the PS-MPC
version 0.90<EFBFBD> fulfilled the "wish list" for VCL 2.0 and the PS-MPC version
0.91<EFBFBD> improved still further, with the capability of creating full-fledged
resident infectors. Another bonus was the availability of the source code,
which allowed extensions of the core program.
B
Reference in New Issue Copy Permalink