Well, I hope I have answered all your questions about XOR and why virii need to hide behind encryption in Part 1. Now for the fun part of encryption. Using everything besides XOR to change the bytes in your virii. XOR is good, and certainly has uses, but nowadays its been done to death, IMHO. It should be used with the other bit manipulators to form more complex, and hopefully undetectable algorithms for encrypting. A quick list might help get us started with the other useful instructions. Not, Neg, Ror, and rol are the ones I think are neccassary to viral survival, they must be used in certain ways though to allow proper decryption. 

NOT:

Its actually even more easy to understand than XOR but not used as much as I would like. Anyway... all it does is reverse the bits in an operand. So something like this: 

NOT  BL

Would change all the 1 bits from BL into 0 bits and vice versa. A small graph could help you understand it a bit more.

As you can see its quite simple to understand, anything that was 1 is now 0 and likewise, anything that was 0 is now 1. This is one of the easiest to put into encryption too, because it takes 1 operand ( the value you want to reverse ). Furthermore, you may realize that if you preform the NOT again you come out with your original value :).

We'll use the INT 21h instruction, to see what happens to it, because it is one of the more commonly used commands in virii. Lets assume AX has been set with the INT 21h command, and now its ready to be encrypted.

Now we go from CD21h to 3D2Eh in one simple command ( 2 bytes long ), and we change our 'INT 21h' into a harmless 'CMP AX,??2Eh' where ?? is the next byte in the progge. Thats all I have to say about NOT for now until we get to using all the instructions together. Thats where the real excitement begins.

* Here is an example virus written explicitly for this tutorial.
* Its shows how NOT AL can be implemented into a full fledged virus. 

ROR/ROL:

We'll skip NEG for now and explain ROR, and ROL. Basically all they do is Rotate Right and Rotate Left. But you may ask, "Ummm, ok... I know WHERE they rotate, but WHAT do they rotate?". Its simple, they rotate bits... isn't that what we've been discussing? They take a value like 23h, and rotate the bits in it a specified # of places. The first operand is the one that will get rotated and the second is how many places it will be rotated. Again, lets use a short example.

Now for graphs...

Now, any Tom, Dick or Harry knows that the value of AL just changed, so in essence we encrypted the byte, and we could use the 'ROL AL,1' command to get back our original byte, but that would require another command. And more commands equal more bytes, and more bytes means our virus will be more noticable. Noticable is BAD! We do not like noticable ( *Hint*: thats why we are learning encryption in the first place! ). So how can we utilize the ROR/ROL commands without wasting bytes...? Simple, we make it so that the second operand is equal to 4!! "Why 4 places?" Well... look at the graphs.

I am not sure if you noticed but the HEX number rotated 1 place. 23h has now become 32h, pretty fucking cool for our purposes. You may again be jumping ahead of me in saying that "If we do another 'ROL AL,4' we will get back the original value of AL!!". Well, you would be perfectly right in that assumption. If a byte is 8 bits, and we rotate 4 bits... thats halfway! And so if we rotate another 4 bits, we have rotated the whole byte getting back to the original bit positions AND our original value.

Rotating the first 4 bits is the encryption, and rotating the second 4 bits could be called the decryption. WOW! Like 'XOR AL,DL' ( in the first part of my encryption article ), and like the NOT command that we just did... the ROR/ROL instructions work twice the job with half the size. That is what we want!

Ok, heres the part of the previous example that changes...
Its not very much as you may notice. 

NEG:

To finish up the track we are on now, ( that is using one command for both encryption and decryption ), we are gonna cover the often forgotten NEG command. Like its sibling, the NOT command, it only uses 1 operand... the one we want to alter. Unlike NOT, and the other bit manipulators, it is based on value rather than the bits themselves. All it does is take the operand and subtract it from 00h ( or 0000h if it is a word [2 bytes] ). We have to use the graphs here because its hard to explain with words.

AL = 23h = 35d = (binary doesn't matter here)

Heres the decimal equivalant for those aren't very good with hex.

"Well Sea, thats fucking great! Why the hell do I care?" Well, if you were paying close attention to the other commands ( NOT/ROR/ROL/XOR ) you would realize they all can be done twice to arrive at the original number. Now if thats true here, we have found another command that can preform encryption on first run, and decryption the second time. Lets see if good ol' NEG can do that:

IT WORKED!!! Neg is a useful encryption instruction. Well... well... don't you owe me an apology, don't you?

And lastly here is an example section using NEG...

Hopefully you understand that each of those instructions does well by itself. Unfortunetly, there are times when they don't work. The command does what it should, but the resulting byte is the same as the one you started with. For example: ROR/ROL switch the hex characters from something like 23h to 32h by rotating four places... but with CCh, DDh, AAh, etc. the result is the not really encrypted. Another example is NEGing by 0 or 80h, if you do the proper math they both end up with their starting values. They may be rare, but they still happen. So what is there to do about such 'errors'?

I hope you figured it out! I may have mentioned it before, but if you combine 2 or more of these instructions they can have a great effect on the complexity of the encryption. How do you do it right though? Just slapping commands together is risky. You can do what I do and make a dual function De/Encryption loop. In the first part of my encryption tutorial I gave an example virus with the following loop:

It only needs SI (where to get the bytes to encrypt), DI (where to put the encrypted bytes), and CX for the number of bytes. After it is called it does the encryption routine on the specified region, and jumps back to the caller. The outer parts with the 'loop' and such are basic things that will not need to be changed much with each different virus or encryption routine. Where it says "encryption command" is the important part.

We do what is called 'plugging in'... since the shell just holds the part we care about, we can take out, and put in what we want. There are a few criteria though.

1) Since the 'victim byte' is AL, the encryption commands should modify... You guessed it, AL!

2) Another thing is that the encryption should NOT modify CX, DI, SI or the Stack ( SP ) unless you know what you are doing.

3) The most important point for us though, is that we should be able to run the Encrypt loop on anything twice, and end up with the starting byte. This is important because we are gonna use the same loop to encrypt AND decrypt. Saves space and makes it look cool.

The commands 'NOT AL', and 'NEG AL' by themselves do that perfectly, but we already realized the need for more than one. So how do we get them to play nicely together? Its a simple idea, but hard to explain. I'll give you an easy example to start with, and explain it afterward.

OK, pay close attention here! This meets the first criteria and the 2nd, but does it meet the 3rd? By itself its hard to see, but remember that this has to be run twice to check its validity, so lets pretend we ran it twice. It would look more like this then...

"Who cares, it just does it twice... it encrypts it even more!" Not so! They cancel each other out! Here is a very important graph...

The last command of the first run cancels the first command of the last run, and vice versa! And the middle commands cancel each other! Isn't it great. No matter what number goes through the first thing, it comes out encrypted, but after going through again, it becomes decrypted! Just follow the lines and review the last few paragraphs till you realize what is going on. Its kind of like stacking plates on top of each other to encrypt, and then taking them off in reverse order to decrypt.

Now to make sure you get the full impact of this, here is a larger example with the same type of graph, but this time if you look at it as canceling ITSELF, you can create loops as fast as you can type em.

Now... how does it cancel itself. Notice that 'not al' is the only instruction that is not repeated. It is also the center of the routine. If you removed the 'not al' you would notice that the routine would do nothing at all to any victem byte, but since we have a command at the center that changes that, its works! So after running those 9 commands we get an ecrypted byte. After running them again the byte becomes decrypted. If you are gonna build a loop like this, try not to make it too long. Here are some basic rules...

1) Always have a center instruction
2) Make sure all the commands are reversible... like if you did them twice to the same byte, it would encrypt then decrypt.
3) Commands after the center command, should be in reverse order. Like above.
4) You shouldn't modify the stack, CX, SI, or DI unless you are sure.
5) Don't do the same command twice in a row, like... 

     xor  al,4h
     xor  al,4h
     not  al
     xor  al,4h
     xor  al,4h

They just cancel each other out, and you really only end up encrypting with a 'not al'.

6) Another combination you shouldn't use is 

     not  al
     xor  al,0FFh

XORing by FFh or FFFFh is the same as NOT. So this would be a waste.

Well thats all there is to know about how those instructions work, but now for how to put them into a virus. Above I showed you an example of a dual function, encryption/decryption loop... here is again for those of you not paying attention.

Where it says "encryption command" is where you can put any combination of commands that fit the above rules. Just use the example virus from the section about NOT and plug in your encryption routine. Test it out and make sure it works.

Yup, that seems all you need to know to make more complex stuff than simple XOR. There are several advantages, like many more different possible encrypted versions, less likey that it will be recognized as a decryption routine by heuristics, and its more creative. Of course, we are not even half-way through what I know about encryption. Here are a few of the things I still want to teach:

1) More encrypting commands... SUB, ADD, and XCHG!
2) Encrypting word sized values with XOR, 65,535 different keys!!,
3) A little idea from a fellow CodeBreaker ( Aperson ), using the victem file's own bytes to encrypt against!
4) Using ROR/ROL with values other than 4!
5) Double and Triple level encryption!
6) That appending example I promised.
7) How to change the values used to XOR with, randomness, system clock, and the incremental way.