|  | REVISION 2 - WORK IN PROGRESS -Philip John Jatzek - The TechnoWarriors Handbook (Second Edition) Conceived And Written By Philip John Jatzek The TechnoWarriors HandBook COPYRIGHT (c) 1993-2000 By Philip John Jatzek ALL RIGHTS RESERVED! This page is for PUBLIC VEIWING ONLY! It is not to be downloaded, exploited, reproduced or stored in any way, shape or form in full or in any part of this work! This work is protected by copyright law! This web page www.mnemonicrom.com is the only legal viewing place for this work to be displayed. The Author (The Copyright Holder) maintains all legal rights to this work and can pull it from public view at any time at his discression. The Author allows internet links to this page, but does not allow copies of this work to be made. You may not rerpoduce this work. Any and all reproduction or exploitation of this work in its entirety or part must be pre-authorized in writting by the copyright holder (The Author). You can contact the author at the email address attached to the end of this work. THANK YOU! DISCLAIMER and AGREEMENT: Before you read any further into this work you must fully agree to the following. If you do not fully agree and understand the following please refrain from reading the rest of this work as the author no longer authorizes you to view it. The author (The copyright holder) will be in no way be held responsible or libable fo the use and/or abuse of the contents of this work. Further more any damages and liabilities arrising from the use of this book rests solely on the parties or party that has agreed to the terms of this disclaimer/agreement and not the author (The copyright holder). By reading this work you accept full responsibilities for any/all legalities and actions arrising,, any/all legal rights against the author regaurding this work are waved. In other words, Absolutely NO ACTION AND/OR ACTIONS will be inflicted apon the author of this work. This book is meant for educational and entertainment purposes only and is in no way attributed to any/all applications developed from use of the information contained within this work. You are fully aware that the author hold exclusive rights and all rights to this work under copyright law and will not break or infringe apon those rights. If you have agreed not to take legal action of any kind,agaisnt the author (The Copyright Holder) in any way,shape or form you are authorized to read this work. This does not mean that once you have finished reading this work you can take legal actions against the author as this would have broken the disclaimer/agreement thus breaking copyrights. If you have not agreed or fully understood any part of this disclamer/agreement please dicontinue reading this work now as the author revolks your rights to it. If you fully understand and aggree to the disclaimer/agreement you can continue reading this work. The Author - Philip John Jatzek - INTRODUCTION: The Earlier Release Of This Book, written under pesuedo name, was in no way complete. It suffered many flaws, and was written specifically for the AMIGA computer and its operating system (don't get me wrong I still think to this day that the AMIGA was the best computer ever built, it just didn't evolve fast enough to keep me interested or challenged so I moved on to Intel and the Windows operating system). I truely wish someone had ported over the AMIGA ACTION REPLAY and ASMONE assembler for the Intel Based Platform. In Any Case, this book is meant for the advanced assembly langauge guru and not beginners as I do not go into how to program in assembly language, but rather what you can do with the knowledge you hopefully by now have aqquired. I will at the end of this book list reference material that you can spend reading thouroughly or as reference to increase your skills and knowledge of assembly language and hardware so you can make full use of this book. Unfortunately it will only be intel machine based books that I aqquired to master the langauge and hardware as all my amiga books are gone. So bare with me if my programming skills seem a bit different than what you are use to as I am carrying over my apple, amiga, TRS 80, and atari programming skills with me as I conquor this new to me, but old to the rest of you, machine. This book is devided into four main parts as well as a useful appendix. The main purpose of this book is to show you (and to he rest of the world) how stupidly we evolved a system that is now running our world and how easily it is to defeat it. Control virus construction and use can manipulate even the most secure of systems, perhaps even one day be the basic blueprints be used in biological manipulation. To make this a very brief introduction a control virus consists of three parts, one; being the control virus itself, two;the remote system interface in which the control virus is manipulated and three; the uploaded code segment on which the control virus gives command to, being a program that is run on the host machine and manipulated by the remote interface. Those are the basic components needed to control any system (provided they are in place). There is much more than simpley designing and implementing these three items, you must learn from hackers, crackers and programmers to be able to infect a host with a control virus. If you can not infect the host, you can not control the host. So I will try to write as many techniques in infecting a system as I come accross while writing this book. The first three chapters will be totally devoted to creating, implementing and operating control viruses, the last chapter will be on hardware. Hardware alone opens new and improved methods on manipulating data streams to your advantage on your quest to infect systems with your personally designed control virus code. Be aware that if you are to fully master this book you will need to fully learn and understand both assembly language programming (specific to the host system you wish to infect) and analog/digital electronics as a means of intercepting, delaying and inserting data transmissions in progress. I'm sure this book will be a valueable tool to even the most advanced TechnoWarrior. DESIGNING CONTROL VIRUSES: CONTROL VIRUS DEFINITION Control viruses are simply this, a piece of executable code disigned to infect a (Target) host system and accept then execute any uploaded code it recieves for online manipulation of the (Target) host system. It sounds pretty simply, and is, if you are a very good assembly lagauge programmer. The only true problems that arrise is with communicating with the control virus (which will be covered later). Using a control virus utilizing upload and execute capability you can simply upload any program you have designed and have it run on the (Target) host system. This means you can upload and execute a file server or a system debugger / monitor or even a game trainer (good for unlimited lives and maximum funds, smirk) and begin exploiting the control virus infected host system. The control virus itself will attach iteself to the host system and scan the socket (using internet) for an activation password. If an incorrect activation password is gotten then it is ignored and the control virus continues scanning for an activation password. Once the activation password is gotten, the control virus should lock the host system so the system operators can not intrude or get rid of you (only by unplugging the machine) this mainly is working on a hidden screen, locking the keyboard control out and protecting the memory you are utilizing from any and all intrusions. After the system is good and locked the control virus waits for your upload, which of course you upload and the control virus passes execution to. From here on in its all fun, you have control of your uploaded program, and can completely rape any system thats been infected with it. From actual memory or file manipulation to changing executing code in progress. The sky is the limit if you are a very good machine lagauge programming, and learning the hex / binary reperestation of the instruction set will help GREATLY in your endevours. Once all your exploitation is done you simple have the control virus shut down the executing upload, erase all traces of it from the host system memory (and media if need be) and have it restore itself to normal operation waiting for the next upload (or erase itself even if you want to fully earse your tracks). Hopefully, if this is done correctly, you can exploit a system for months, perhaps even years until you are found out or your virus detected. A good virus is one that can never be detected or can not be easily removed, these will be explained later on. For now, I'm sure you have a pretty good idea of what a control virus is, time to move on to detail. TRIPLE KEY COMMUNICATION DEFINITION Triple Key Communication is a form of communication between the control virus located on the (Target) host system and you the remote system (remote system interface for the control virus). It was developed as a means to bypass character masked systems (binary key does this better also bypassing hardware encrypted systems and will be explain later). Character masked systems only allows for certain asc codes to be sent to / or recieved the host system and remote system. Character masked were designed as a means to strip control characters (and other asc codes) out of data transmission as so they would not affect the operation of the host system. BBSs (bulletin board systems) use to use this on their online menu systems where as only the asc codes represention alphanumeric codes were accepted as input and all others were masked out (stripped). This prevented any unwanted keycodes to be sent or recieved from remote systems. These character masks made it impossible to upload a program to the host system as some of the asc codes would be blocked (unless you were lucky enough to bypass the upload / download stream of a binary file transfer) and the program would not run with missing codes (ie: hex codes that make up the instructional set of a working program), and the host system would crash if the program was executed. However a set of 3 characters used to makeup the 256 character codes that the intel computer uses (keycodes, hex values for mnemonics, values, etc) could and can bypass all forms of character masks. By remapping the 256 computer characters into a series of 3 characters that the host does not mask out, you can communicate to your control virus by simply sending 3 character sequences instead of the normal asc codes, the control virus would then translate the triple key communicated code into its hexidecimal values and presto, you have uploaded a program that uses all 256 codes in communicating to and from the remote system directly to the (Target) host system. The encoding and decoding of triple key comminication is all dependant on what is currently running on the host system. Meaning it only works if the control virus itself or the uploaded program that it is running, does all the translation. In any case, you get the idea. HOST SYSTEM COMMUNICATION REMOTE SYSTEM CONTROL VIRUS <------ AAB-BAC--CAB---> REMOTE SYSTEM UPLOADED PROGRAM <------ ABC-CBA-ACB----> INTERFACE BINARY KEY COMMUNICATION DEFINITION Binary Key Comminication was spawned from triple key comminication as a means of bypassing hardware encrypted systems (such as SDI). This is also another brainchild of the author. How it works is very simular to triple key langauge that bypasses character masks. It translates asc codes into their binary representations. Meaning one hex value is broken up into its binary representation and then sent to and from the (Target) host system. You are problably asking by now, well if it's transmitted in binary why bother using encoding and decoding it at all. The answer is very simple, instead for communicating in ones and zeros the way it is normally done the encoder and decoder transmits in TIME VARIATIONS. Meaning that the 1 could be 0.003 of a second and the 0 could be 0.008 or any time sequence that you wish to use as long as it is measureable by both the control virus and its remote system interface. Using time as a means of binary key communication it no longer matters what data is being sent or recieved by the host system, in fact the comminication does not affect either data stream at all, only the timings of such transfers are ever effected. So the host can merrily go on about its business and you can diluge the host throughouly completely unmonitored as none of the host data is ever manipulated. Meaning if they were scanning all sockets (in internets case) for data you would remain completely invisible as no data is changed in binary key communication. This basically follows the same rules as triple key communication, the control virus (or uploaded program) must preform the necessary encoding and decoding of binary key comminication. Again, in any case, you get the idea. HOST SYSTEM COMMUNICATION REMOTE SYSTEM CONTROL VIRUS <------ 1110110110001----> REMOTE SYSTEM UPLOADED PROGRAM <------ 0010110101011----> INTERFACE Note: That all the 1's and 0's represented in the communications (above) are TIME VARIATIONS and are to be encoded and decoded by both the control virus and the remote system interface inorder to work. You must also take into consideration the data flow, so you protocol must handle changes in the data stream. Remember one byte sent is equal to one bit unless you can manipulate the timing of bits in a byte to speed things up a little (evil grin) and yes it's possible in case you are wondering becuase data transmitted is in binary. So your communication protocol can use a few bits per each byte to set up timmings for the bits that follow for communication and stop communicating on a long pause (no data transmission) thus waiting for the next set of bytes (or byte) to be sent to resume the communication. Over and over again until your communication has been completely communicated. You must sync your binary key communication and have some form of error correction control simular to old protocols used for modem communication (remember bulletin board file transfer protocols). That is why the first few bits always sync the communication and a pause where data is not being sent ends that portion of the communication which means you have to resync to resume the communication on the next data transmission. BUILDING YOUR CONTROL VIRUS Building your control virus is not an easy task. It takes a lot of time and patience as well as tools to get the job done efficiently and error proof. The most important thing to know when creating your control virus is not assembly language but rather the hexidecimal values and binary construction of those assembly language mnemonics. The reason for this, you must know how to change branch and subroutine values by a form of indexing which is attached to the hexidecimal value of the mnemonic code you wish to manipulate, this is done in binary. Also done in binary is the registers, stack, etc parameters for mnemonic instructions such as move. Knowing the binary rules to hexidecimal instruction will be of great benifit to you and your endevours. For example, say you need to scan a file for a branch or subroutine call, you can not scan it simply by the name of the instruction, you have to search memory (or media) for the hexidecimal value of the instruction then manipulate it. Say you want to insert your branch or subroutine call to point to your control virus located in memory instead of what it's currently indexed to, you must know how to change the binary appendature to the hexidecimal instruction (as well as a little math to find the correct index value for the number of bytes forward or backward to jump to from the branch or subroutine call). there are very few books that give detail on this type of information, The intel reference set (noted in the reference section of this work) is a very good place to start. Another good reference is simply using a debugger or system monitor which can display binary, hexidecimal data representation of the mnemonic instructions and manually hacking out the indexing binary scheme amongst other things. The best tools you can use in constructing a control virus is an assembler with a built in debugger (say Turbo Assembler) combined with a system freeze montor (SoftIce is good) to freeze the system and look into the internal workings of memory and your control virus in a frozen state. Switching back and forth between the frozen state and the real time state will uncover a lot of answers for you as you try to master control virus programming. You may also find that the dreaded GOTO command or branch instruction (frowned apon by many programmers) is the best thing to ever happen to a virus writer. Subroutine calls divulge information on the stack (meaning your virus code is not completely invisible to the system if you trace the stack) which gives information on the return addresses to the calling instruction whereas branches do not. If you use branches make sure to save and restore all the data from the code that your control virus was branched to from so you don't crash the calling code apon return. Best to do this in predefined allocated variable (your own created stack) then relying on the system as to remain invisible to it. Using this method is very good becuase it does not divulge any information to the system when transfering control back and forth between programs, meaning it can not be monitored. Only use a subroutine call where it is absolutely necessary and be aware it could be montored by the system by means of the stack. Here's an overview of the control virus construct. CONTROL VIRUS OVERVIEW HOST SYSTEM REMOTE SYSTEM VC LOADER MEDIUM CONTROL VIRUS CONTROL VIRUS<---------COMMINICATION------>REMOTE SYSTEM UPLOAD MODULE<--------PROTOCOL-------------->INTERFACE A control virus isn't simply one program, it is composed of many parts utilizing many techniques in such a way as to create an efficient hand in hand working system. Starting from the ground up. You first write you control virus. Then you write you control virus loader. Then you develope you infection and implementation system so both the loader and control virus work hand in hand when infecting systems. Then you develope your remote system interface and the communication protocol between your control virus and the remote system interface. Then after all that, you work on your upload and execute modules that are to be used for the control virus itself. Sounds like a lot of work, well it is, imagine if I explained it in great detail. Hopefully by the end of this work you will have grasped a pretty good idea on how to construct your own control viruses as well as learned some new skills in programming techniques that are not usually descussed or implemented in real world applications. When you are all finished, you can sit back in your armchair and reach out to control virus infected systems operating them much like you would a typical application program and enjoy your hard labour from the comfort of your own home (or moving vehicle). So enough with the preliminaries, let's get on with the workings. LINKING AND EMBEDDING VIRAL CODE Linking And Embedding the Control Virus is very important and must be done accurately, one small mistake and you will crash the host system and more than likely you hard work making the virus will be detected and dealt with. I am going to explain in a backwards style as to the way you would actually implement these techniques so it will make more sense to you. Linking is to take one line of code from an already executing program or function (ie: rom overlay, exec program, system libraries and os interrupts) and replace it with another that will execute your control virus code. First you copy your virus code into memory using a control virus loader (which by the way must be part of your virus infecting code so that the control virus will load into memory and execute) What happens is your control virus loader writes the control virus code somewhere in memory and then looks for something to link to so that the control virus code will execute regularly. Once a link is found (say keyboard routine, video routine or communications routine) it will take one line of its instructional code and store it near the end of the control virus code. Next the control virus loader replaces the copied instruction with either a branch or subroutine call to the actual control virus code. The actual virus code block is made up of typical assmely langauge ssubroutine conventions. meaning that it saves all registers, stack, heap, etc before executing the viral code and restores them when complete. The second to line of the control virus code is where you insert the instruction you copied from the original linkable code. And the last line of code is simply a branch or return from subroutine to the next line of code just after the link you placed in original program or function. For simplicity I will try to draw a visual. BEFORE AFTER... .... NORMAL LINKING TO CONTROL VIRUS SYSTEM FUNCTION SYSTEM FUNCTION STRUCTURE (CV = Control Virus) system function -----> system function --BEGINNING OF CV CODE BLOCK-- function code function code Save All Registers LINK TO CV ---------> Control Virus Code function code Restore All Registers Original Instruction Copied Here Return to next line of original function --END OF CV CODE BLOCK-- As you can see above. The link to the Control Virus is copied just before the branch / return at the end of the control virus code block. This is done so that it is executed as so that the linked program or routine functions normally without any problems. Always remember to save and restore all possible information before and exiting your control virus code block, one small oversight and you could cuase the original program or function to operate incorrectly. A bug in the system is quickly seen and soon to be correctly. If corrected there goes your nice peice of hard work. Linking can be prefromed anywhere in a program or function only as long as it is in a place that gets executed. Linking over a data segment will not do anything as it never gets executed. Doing a scan of the program you wish to link to before actually linking is a very good idea. For instance, you scan for a branch, subroutine call or or subroutine return using the hex values (and binary) of the instructions themselves. Once found you copy then overwrite the instruction (as long as your branch or subroutine call will not overwrite into the next instruction of the program you wish to link to. If your link code is smaller (in hex size) than the actual instruction you copied and wish to overwrite, simple use NOP (no operation) commands to pad the instruction to the next instruction allowing a return to the next instruction in the original program. Now for embedding. Embedding is usually always used for media infection (Not media files like mpeg etc, but media such as harddrive files and floppy files). It can be applied to memory as wel, but why bother since you have all the free memory at your disposal and the link can point just about anywhere. Embedding control virus code into a file that can and will be executed is pretty straight forward but requires two steps to be efficient. The first step is designing the control virus loader (a small routine to get the control virus into memory and then execute it so it can link up and become operational) and the second is the control virus (which can be located anywhere on the media). First, you embed you control virus loader into the executable file, can be anyplace within the file as long as you put a branch over your control virus loader code as to not interfer with the normal operation of the executable file. After this is done you then attach your a link in the target executable file so that it points to your control virus loader, third you then copy the control virus code into non used sectors on the media which contains the executable file. This is what the loader will load into memory and then execute. The loader is all that is really needed to be attached to executable files (or system subroutine libraries). When the loader gets executed it loads the actual virus code of the sector blocks on the media on which it was placed. This cuts back on overhead as the bigger the file attachment the more likely it is going to get noticed. The loader should only execute once and never again otherwise you will have multiple copies of the control virus all running at once which will slow down the system and may get noticed by the administrator. So remember, only attach the loader to the program files and keep the actual control virus code hidden on the sectors of the media. Here is a basic pictorial. SOLID DISK FILE SECTOR BLOCKS CONTAINING CONTROL VIRUS CODE SEGMENTS PROGRAM CODE BLOCK +--> DISK SECTOR 1 program code | CV CODE segment 1 link to CV loader -------+ | DISK SECTOR 2 program code | | CV CODE segment 2 Branch Over VC Code | | DISK SECTOR 3 CV loader Code <-------+ | CV CODE Segment 3 Sector Log Holding Variable ---+ DISK SECTOR 4 Program Code CV Code Segment 4 END OF PROGRAM ... and so on ... As you can see by the above asc pictorial, the loader is totally responsible for keeping tracks of the actual control virus code segments located on random sectors on the media. This is easily done with a built in hardwired variable value that gets written into the loader code automatically each time it infects another media source. Remember to FLAG this hardwired variable per each media it writes the control virus, to AND NOT each time it infects a file, This means, only one copy of the actual virus code written per media flagged (unless you want a backup source in case the first one fails) otherwise each time the control virus infects a new executable file (or subroutine library) more and more disk space will be used on the system and a weary administrator might suspect something. So simple rule, the loader can infect as many files as it can attach itself and is usualy very small, just enough to get the job done,and utilize one or more media sources to obtain the actual control virus code (which is bulky enough to lock the system, preform the communication, password getting, uploads and execute). Once the control virus code is loaded into memory (by the loader) it is then linked to anything that will execute it regularly. For example, if you want to scan the sockets (for internet) for an activation password before uploading simply link to the functions that handle socket access by a search, find and link. Always link to something that you know will execute frequently. This way you can check the socket access without writing many lines of code to do so becuase the function that you linked too does most of the work for you. Better yet your control virus is garenteed to execute everytime that routine is executed. If you have fully understood the material presented on linking and embedding so far, you are ready for the next part of embedding code.. Embedding code into files in such a way that the file sizes do not change is very easy. You simply follow the rules for linking control virus code and apply it to embedding. You simply obtain the Control virus loader size in bytes, go to the file that you are going to link to, take some random location in it and then copy the original files bytes over to the virus code located on the sectors of the media, then overwrite the original files (the bytes you copyed) with the control virus loader code, add you control virus loader activation link and presto, you have now setup your loader within the target file without changing its file size. If this sounds complicated just review the past material and it will become clearer. Here's a pictorial of how it works. BEFORE AFTER.... ..... ORIGINAL FILE SOLID MEDIA FILE SECTOR BLOCKS CONTAINING COLORED SEG LINKED AND EMBEDDED CONTROL VIRUS CODE COPIED THEN SO FILE SIZE DOES NOT SEGMENTS AND ORIGINAL OVERWRITTEN CHANGE PROGRAM BLOCK PROGRAM PROGRAM CODE BLOCK +--> DISK SECTOR 1 program code program code | Restore Target File program code-----+ link to CV loader -------+ | DISK SECTOR 2 program code | program code | | CV CODE segment 1 program code | Branch Over VC Code | | DISK SECTOR 3 program code--+ | CV loader Code <-------+ | CV CODE Segment 2 program code | | Sector Log Holding Variable ---+ DISK SECTOR 4 program code | +--> Program Code +----------->copied program code END OF PROG | END OF PROGRAM | ... AND SO ON ... +------------------------------------------------+ Is it starting to look complex? Well it's not. following the red arrows you should see exactly what needs to be copied from the target file, copied to where, and overwritten with what. This simple process will always retain the original file size wether it is a program on media or in rare cases a program in memory. When the loader execute within the target file, it will go to its sector log (a hardwired variable containing sector data for which the actual control virus code it located) and begin copying the control virus to memory. After it has been fully copied it will be executed. After executation the control virus setup will take all the original file data and overwrite the control virus loader with it (don't worry this only affects memory and simply gets rid of it, it does not destroy your loader on media that gets executed everytime the file (or system routine) gets executed) thus restoring the original file to its original state whereas it can operate as it was intended to with the control virus completely loaded, setup and executing. After the copied original file data has been restored it can be discarded completely as it only needs to be used after the loader sets up the control virus code off the sectors and the file needs to be restored so it can execute properly. With this simple linking and embedding information you should be able to evolve it. Use your imagination. However imagination is nothing without the ability to bring it into reality, so I suggest you read lots of books, and play with software that can manipulate the computer system in such a way as you can see its operation.Softice, magic game creator, tasm, disassemblers, hex editors, all of these will show you what is going on within your computer as you master it. On to the next topic. VECTOR INTERUPT TABLE The Vector Interrupt table, how nice of them to build the system with a sequential list of subroutine calls. Even better is that it points to where they are all located in memory. There are two types of routines that can be found utilizing the vector interrupt table. One is ROM (Read only memory) routines that are burned into an eprom and can only be bypassed by means of a rom overlay provided the hardware manufactures allow for such a task to be done and the second is the OS (operating system) which sets up the vector interrupt table so that it points to it's routines loaded into memory, which can be changed easily. You do not want to attack the vector interrupt table directly when implementing your control virus as it is the easiest thing to monitor on a computer system, what you want to do is read the addresses stored there so you know where all the subroutines are located in memory and then link into those subroutines so that when the vector interrupt table calls that routine your control virus code gets executed along with it. Here's the overview. VECTOR INTERRUPT TABLE SYSTEM MEMORY .. ..... 038 Address To Routine +-> Start Of Routine +---> CV CODE BLOCK 039 Address To Routine | Routine Code | Control Virus Code 03A Address To Routine ---+ CV LINK -----------+ Copied Routine Instruction Code 03B Address To Routine Routine Code <-------- Return To Routine Code ... AND SO ON ... End Of Routine END OF CV CODE As you can see by the above, it is very simple to implement your control virus into a system using the vector interrupt table. Even better, you can link two or more routines that use this table so that each time any routine is run it executes the control virus code (The more the merrier). Not only can you fully exploit the vector interrupt table but also the programs which are loaded into memory themselves (using windows just scan the PID or manually scan and test the stack) and the system libraries which programs call for subroutines (using windows these would be the DLL files) . This creates a vast resource of code which eventually gets executed in which to link your control virus is also executed in the prcoess. So, you have design your control virus loader carefully for it to know what to attach the control virus links to (or embed it). The vector interrupt table is the most easiest as it lists all the subroutine addresses in a nice orderly fashion so you can manipulate them. In advanced control viruses you should always check the stack first (and possibly backtrack where needed) to see if anything is monitoring the Vector interrupt table before you read it, then take the appropriate steps to bypass the monitoring program (doesn't matter how big your control virus is, the loader is small, and loads the control virus off the media, but try to keep it within reason). EXPLOITING ROM BIOS There is programming then there is hardware programming (which is the best). By hardware programming you bypass the operating system completely, which means it no longer matters what operating system is running on the Target system as your program will still be executable. There are three ways to do this, One: Write a rom overlay, this redirects a normal bios (or rom,eprom) routine to a routine in memory or linking onto an existing rom overlay (this can be found in the vector interrupt table), two; burn directly into the rom, you have to distribute roms (or eproms) with your virus embedded in it (this means assembling your code then EXE2BIN it and burn it onto the chip itself) and three; bios update, this goes directly into the cmos where you can call memory resident code from within it (can be done via programs such as flash bios updates which you should disassemble and create your own). Exploiting the chips is great if you know how to do it as it lets you infect hardware rather than computers themselves, from plane, trains to guided missles. You need a few things to do this however, these include The CPU for the system to infect, an eprom or prom, a debugger board and of course the assembler for the chip (you need a computer still to compile with). Let's say for example you were at war with another country, you have a timed attack on them, you watch their mail and discover they ordered a printer, you get the specs on that printer and then write your rom virus, remove the eprom (or whatever) from the printer and insert your new one. Now when you go to attack them the printer locks their computer up with your nice timed virus code embedded in it. Geezz why isn't our computer working, little lone why can't we get our computer to work (even with cold boots). You can see the potential. Hardware is not safe from control virus attacks, it's just a little more complex to implement them. You can infect just about anything if you have the right equipment and knowledge. Even though assembly langauge differs on all CPUs the basic outline for them is the same. So your basic steps is first get all the equipment and learn the assembly language, use a computer to write your code for the chip, compile it, exe2bin it so you can burn it into an eprom, then burn it and place it on a debugger board for testing. Once its all tested and operational make lots of chips with your control virus (or other virus) burnt in and and infect the system you wish to attack. There are many ways to implement your virus, by selling them to the public, by making a fake maintanance call to the place you wish to infect or even by putting a virus directly into the compiler itself so that everytime it compiles code for the chip it tags you virus code onto it as well. MUTATION AND RUN AWAY CODE Mutation and Run Away Code Are two forms of protecting your control virus against detection. The first is simply a form of changing the code around so that your control virus is never has never the same code twice each time it is written, this twarts of all known search, detect and destroy techniques used to kill most viruses. This is done by placing random variables with random values inside you code and putting a branch around the variables to the next code block, in such a way that you code is broken up into parts and random value blocks are inserted into it. You can also use randomly located NOP (No Process) Instructions to cut up the code so you can not search find and destroy the virus code, You use your descression. The second is a detect and run away technique where as when anything tries to access your control virus in memory or on media, it simply moves out of the way and relocates itself thus avoiding detection. Use the first method to protect your control virus when it is not running and the second when your control virus is running. Together these make it very difficult for someone to locate and get rid of your control virus. FRAG CODE (SELF REPARING) Frag code has to be one of my more complex coding techniques. It is basically a control virus broken up into many parts, each part testing the other parts with a checksum, if the chesum does not match it then repairs the section of code that does not match with a copy of the original code, thus making it impossible to damage the running control virus in any way as it always test and repairs itself during operation. IMPLEMENTING CONTROL VIRUSES: INFECTING A HOST BY INFECTING A FILE There are many ways to infect a system, the most fool proof way is to infect a file. That too, there are many ways to infect a file on a system from trojan horses which mimic programs in order to have them run to media infecting viral method in which all removable media gets infected. These methods have been well documented over the years. the main idea is to get the person to run your virus so that it is activated. A simple search for hack on the internet will yeild many ways of infiltration. INFECTING A SYSTEM BY BUFFER OVERRUNS Buffer overruns (and sometimes buffer underruns) is simply this. A variable is used for input, it is a defined size, if you go over the size limit of the variable you begin overwriting what appears after the variable. In this case, you are betting on overwriting the PC (program counter) or infact the next line that it is to execute. In this type of infiltration you break the bounds of the program variable and cause a buffer overrun. Once you have broken the bounds you want to send your viral code followed by nothing but branch statements all the way back to the start of the viral code. This is done in hope that a branch statement will fall on the PC (progrma counter) and be executed. Once executed the branch statements are followed back to the first branch statement in turn which gives control to the main viral code and you are in. Buffer underrun works the same way but only in reverse. Many people say this will never happen, it is impossible, well no it isn't, you just write a bounds breaker virus to break the bounds. A good bounds breaker uses game training techniques to find the actual bounds checking variable, this increments and decrements for each character typed or removed. So a progressive search for all increments and decrements of unknown values in a sequential character typed or character removed fashion will most definately yield you the bounds checking variable. From here you simple use your game training techniques to locate the compare instruction and NOP (No Operation) it. Once the comparing instructions are removed you can pump characters through the input stream both backwards or forwards eventually overwriting the PC (program counter) and having your code run. The input variable index is incremented and decremented as per your input but never checked for the bounds so you can easily overwrite the program code by forward indexing or backward indexing and eventually have your overrun code executed. OPERATING CONTROL VIRUSES: LOCKING THE HOST SYSTEM When utilizing the target host system it is customary to lock the system operators out of the computer when you do anything that you do not want interrupted. This involves locking the keyboard so the system operator can not type, redirecting I/O to a hidden page so the system operator can not see what you are doing and halting any other running programs so they can not interfer with your work. UPLOAD AND EXECUTE SYSTEM MONITOR RECORD/REPORT AND RECORD/PLAY These two techniques are very useful indeed. First Record and Report is used to find the data entry on encrypted system. It recorded the actual keystrokes and saves them to a file that can be picked up later by the control virus. This is good for system operator account information such as administrator logons as well as getting information that you would normally not be able to get on encrypted systems. The second, Record and play is a technique where as you record all outgoing calls (via modem or internet) and collect all logon information in a script file so that your control virus can call out to all the locations in the script file, log onto the system (with the logon information recorded) and do what ever it has to do to infect or manipulate the new system. HOPSCOTCHING THE INTERNET (AVOID TRACING) All us internet junkies by now probably know how eggbots work for irc. Well this approach is very simular. You infect host systems with a bot program which will call another host infected with a simular bot (and so on) and report directly back to you (not advised) or a previous bot programs until it reaches you (the remote). Doing this bot send and recieve from one bot to the next on busy host systems makes it very difficult to trace from the target host all the way back to you (the remote) as data is transfered inbetween bots and not on a direct route. If someone were to try a trace, it would go to the first bot communicating with the target system and not directly to you as you manipulate it. In order to find you (the remote) they would have to trace all the bots in your bot list to the remote itself. The bots themselves can self destruct (erase themselves) after you are finished with the target host. Even further more, if your bot knows what files to delete on the host system on which it resides you can delete the logs. This I call hopscotching. Even further more, you can have a timed attack against the target system. meaning you communicate to one bot, it waits for a specified time, then communicates to the next bot, and it waits for a specified amount of time till it communicates to the next bot, and so on and so on back and forth between the remote and the target system. Doing this makes it virtually impossible to trace as you no directly connected to the target system in real time. REMOTE ---> HOST1 ---> HOST2 ---> HOST3 ---> HOST4 ---> HOST5 (TARGET) ^ CV1 CV2 CV3 CV4 CONTROL VIRUS5 | RTM1 RTM2 RTM3 RTM4 MONITOR MODULE | RTM5 | | +--------- HOST9 <--- HOST8 <--- HOST7 <--- HOST6 <---------------+ CV9 CV8 CV7 CV6 RTM9 RTM8 RTM7 RTM6 CV=Control Virus , RTM=Recieve And Transmit Module WHO FRAMED ROGER RABBIT (REDIRECTION) AUTOLAUNCH (TIMER RESPONSE) FTP DELIVERY HARDWARE APPROACHES: TAPPING INTO THE SYSTEM (INTERCEPTION, DELAY AND INSERTION) FREQUENCY JAMMING (THE ART OF OCTAVES AND LIKE FREQUENCIES) MASTERING FLIP FLOP COMUNICATION APPENDIX: This contains well commented source code techniques relative to the topics covered in this work. There are presented here to show you that the topics covered in this work do indeed work. They will be presented in squential order as to how a control virus would be developed if you had to do it from scratch. Let's Begin: REFERENCES: This Is A List Of All My Relevant Books Related To This Project: * Intel Pentium Pro Family Developer's Manual Volume 1: Specifications Intel Literature, Order Number 242690, 1996, ISBN 1-55512-259-0 * Intel Pentium Pro Family Developer's Manual Volume 2: Programmer's Reference Manual Intel Literature, Order Number 242691, 1996, ISBN 1-55512-260-4 * Intel Pentium Pro Family Developer's Manual Volume 3: Operating System Writer's Guide: Intel Literature, Order Number 242692,1996, ISBN 1-55512-261-2 * Programmer's Guide To The AMIBIOS American Megatrnds, Windcrest/McGraw-Hill, 1993, ISBN 0-07-001562-7 * Windows Programmer's Guide To DLLs And Memory Management Mike Klein, Sams Publishing, 1992, ISBN 0-672-30236-5 * Advanced Windows Jeffrey Richter, Microsoft Press, 1997, ISBN 1-57231-548-2 * Write TSRs Now Popular Application Series Jim Ras, Wordware Publishing, Inc,1993, ISBN 1-55622-335-8, * Mastering Turbo Assembler Tom Swan, Hayden Books, 1989, ISBN 0-672-48435-8 * 80X86 IBM PC and Compatible Computers: Assembly Language, Design and Interfacing Vol. I and II Muhammad Ali Mazidi, Janice Gillispie Mazidi, Prentice Hall Inc, 2000, 0-13-016569-9 * Introduction to Assembly Language Programming: From 8086 to Pentium Processors (Undergraduate Texts in Computer Science) Sivarama P. Dandamudi, Springer, 1998, 0-387-98530-1 * Assembly Language : Step-By-Step Jeff Duntemann, Wiley, 1992, 0-471-57814-2 * Windows Assembly Language & Systems Programming : 16- And 32-Bit Low-Level Programming for the PC and Windows Barry Kauler, R&D Books, 1997, 087930474X * Upgrading And Repairing PCs (Sixth Edition) Scott Mueller, Que Corporation, 1996, ISBN 0-7897-1053-6 , 0-7897-0825-6 * The Complete PC Upgrading & Maintenance Guide (8th Edition) Mark Minasi, Sybex Inc., 1997, ISBN 0-7821-2151-9 (LINKS) This Is A List Of All My Relevant Links Related To This Project (LINKS) * The Hackers Club (Cracking, Hacking And Other Information) Assorted Tools and tutorials on cracking and hacking programs. Gain very valuable experience when uploading and manipulating a monitor program to a (Target) host system using control viruses. * The Web Universe (Game Training Tools) A very Good Game Trainers, Learn how they work internally by using them, Not only does it allow you to play god in games but serves as valuable experience for later locating and manipulating magic numbers on target systems. * NuMega SoftIce Central Page (Windows Debugger And Tools) Only the best windows debugger ever made. This is the main page for patches, updates and the SoftIce Debugger itself. Experience in this will be a definate asset in your future endevours. Well Worth Buying Comes With Detailed Manuals. Make Sure You Search For SoftIce On This Page For Further Information On The NuMega Product. They Also Produce SoftIce Driver Suite Amongst Other Very Useful Debugging Tools. I hope you enjoyed This Work As Much As I Did Writting It! If you Have have any suggestions, or want to make an addition to the next revision of This Work, With Full Credit Of Course, please feel free to contact me at pjatzek@mail.hypermart.net The Author: Philip John Jatzek