To Jack of Shadows (JS) and +Seniors:

	I'm pleased for many reasons, first, it has been proven that a good 
protection can be written in matter of hours with plain assembly using few 
or none dirty ready-made tricks at all; second, this protection has 
surpassed all my expectations as it was only a game and not a serious 
attempt to protect anything, still, it took 4 hours to be defeated, while it 
just took 2 hours to be created. Many serious protections, with the aid of 
ready-made tricks and hugh amounts of code take fewer time than that to be 
cracked.

	The protection, as I designed it, has many important leads to 
facilitate the cracking process, because as I said, it was not meant to be 
uncrackable, on the contrary, it was weak in many (on purpose) points. Both 
strings: Reg and Unreg, are very close which other and not in any manner 
fragmented or created on the fly. The encryption system used is as simple as 
possible, but it will defeat most of wannabes. It is very easy to neutralize 
if you realize the encryption key changes all the time and it is word sized 
which gives you much more possible encrypted variations than usual (byte 
sized). The whole program ends up encrypted with a different key each time 
it is ran, so the only way to read it is annihilating the encryption system 
or as JS did, creating an ex profeso gadget to do the job.

	With the naked program in hand, there are several additional 
facilities. First let's talk about the Random code generator. It has 6 main 
functions, each one of them is capable of creating perfectly working valid 
"senseless" code. The first function creates paired PUSH and POP 
instructions. That configuration has the advantage to preserve the stack 
pointer unchanged, so the coder can still use the stack without any risk of 
corrupting it or overwriting the main program itself. The second function 
creates MOVE instructions using as source and destination operands any 
REGister except AX or DX because they are needed intact for latter use or 
CS, ES, as it can't be done. The third function mixes all up creating sbb, 
cmp, xor, etc., except it won't execute any DIV instruction, to preserve DX 
as it uses a 16 bits destination operand. The fourth branch creates XCHG 
instructions. The fifth and sixth functions create direct addressing mode 
operations. First, MOV to REG from directly pointed memory location using a 
16 bits random displacement. Notice that this random value could be FFFFh 
producing therefore an error because Intel CPU process a 16 bit addressing 
mode operation pointing to the last byte of any segment, by loading the last 
byte of that segment and the first byte of the following one. The primitive 
intel processors would simply wrap around back to zero and load the last and 
first bytes of the same segment. That's why the code generator will only use 
8 bits registers as destination operand in this function, as it is obvious, 
you cannot control the content of every register at any time during 
execution ending up probably with a general fault protection (win95 will 
snoop that at once). For compatibility reasons the sixth function works 
right the same but using the most complexes Intel architecture addressing 
modes. I was not sure to include this last function because complex memory 
addressing modes like: base plus indexed plus 16 bits displacement are CPU 
intensive operations which probably makes this configuration unpractical if 
we would want to employ it at major scale in a commercial product. All six 
functions are able to create perfectly working code that never touches the 
stack, important registers or any memory location. The code is easy to spot 
because it performs suspicious operations as PUSHing and POPing the same 
register, exchanging values using the same register, etc. It was meant that 
way again just to facilitate the job of the potential cracker, off course, 
with several few additional precautions and another 10 or 11 more functions, 
you could create realistic code hard to fish for the untrained eye.

	JS could not explain why the junk registers are cleaned up, he said 
that it was an unnecessary action; he stated this, because he knew what the 
hell was going on, however, if the potential cracker doesn't understand the 
protection and we pretend (by using random code) to simulate a very complex 
mathematical process, it would be very nice to add a register initialization 
sequence as if the value in these register needed to be cleared before going 
any further. Many instructions in a protection scheme are there just to 
confuse, that's part of the game, isn't it?

	JS could not understand the last segment because it is unfinished, 
two hours was not enough to fix everything, it changes the encryption key at 
random, stores it in memory, encrypts the whole program on memory, saves it 
back on the dead file, decrypts it back to prevent CS:IP from pointing to 
junk and the execution continues cleanly. There's an error recovery addition 
at the end, just in case some wannabe decides he's to clever and tries to 
fools the protection by changing the file name or anything like that, 
however, at the end I decided to leave that door open to ease things. JS 
found it and changed the filename, that was the way to do it.

	The Unreg string is presented using INT 21h, no direct screen write, 
no binary level code generation or complex displacement calculation. All of 
that, guess why? Again, to facilitate the cracker's job.

	Finally, the ultimate code, the one which encodes the meaningful 
instructions provides a subtle randomicity system, preventing the main 
operations from falling in the same offset every time because that would 
make the whole code generator worthless. Still the string displaying 
sequence is nothing more than basic.

	Even with all the facilities named, this baby made your life 
miserable at list for four hours, je, je :-)

	There's no point on which language you use to protect, if you do it 
because you want to earn money or limit people's choice, you'll fail. If you 
do it as an art, you'll succeed. I don't agree with the statement in regard 
to the fact that assembly is only useful if you crack DOS targets. On the 
contrary, it doesn't matter what language you've used to protect, the 
cracker will end up dealing with assembly, I don't have to hook an API using 
assembly to probe my point or Do I? I sincerely wish to see more assembly 
targets out there, or maybe more clever ideas as +RCG's even if they are not 
written in assembly. Remember this, if you program in any language, 
depending on how flexible it is, you can play God, if you master assembly, 
you don't have to play God, coz you're him...


	To JS: You're good, so many years out of the scene and you're not 
rusted at all. I wanna hear more about your ideas, so be good to us an write 
about some protection you like or anything else you think could be helpful 
for us, I'm sure Fravia+ will publish it as he's the best to seize the 
brightest stars out there in the cracking scenario. There are bad news too, 
the baby's little brother will be delivered as soon as I have some spare 
time to code again.

	To the +Seniors: Coding in assembly permits you to downgrade your 
communication with the CPU at the very binary level itself, where there are 
no barriers and all of the CPU's resources respond merely as slaves to your 
will. Experiment the sensation of leaving aside your asm interpreter and 
talk with the CPU in binary is sensational, there's no limit for what you 
can accomplish. +ORC's warned us about junk random generated code being used 
as a a mean of effective protection. Encryption is already being effectively 
used (timelock for instance) to protect. Random code is not yet a 
frequent practice, but we have to teach protectionists to use it, I'm sure 
it'll be great fun to crack their pathetic random code.



						Aesculapius.