posted July 31, 2001 09:53 AM            

Mid$(TextStr$, i, 1) = CHR$(ASC(Mid$(TextStr$, i, 1)) XOR 13)

posted July 31, 2001 11:20 PM            

%CryptAdd = 134
%CryptMul =  17
 
sub Encrypt( s$ )
 
local i%, ch%
 
  for i% = 1 to len( s$ )
    ch% = ( 256 - %CryptAdd + asc( mid$( s$, i% ) ) ) and 255
    mid$( s$, i% ) = chr$( ( ( ch% + ( %CryptMul - ( ch% mod %CryptMul ) ) * 256 ) / %CryptMul ) and 255 )
  next
end sub
 
sub Decrypt( s$ )
 
local i%
 
  for i% = 1 to len( s$ )
    mid$( s$, i% ) = chr$( ( asc( mid$( s$, i% ) ) * %CryptMul + %CryptAdd ) and 255 )
  next
 
end sub

------------------

posted August 01, 2001 06:24 AM            

KeyLen = Len(wKeystring)
For Initi = 0 To 255
    s(Initi) = Initi
    Incr KeyCount
    k(Initi) = Asc(wKeystring, KeyCount)
    If KeyCount => KeyLen Then KeyCount = 0
Next
For Initi = 0 To 255
    Initj = (Initj + s(Initi) + k(Initi)) Mod 256
    Swap s(Initi), s(Initj)
Next
i = 0
j = 0
'Don't modify original string
'fromEncPos = 1
fromEncPos = 0
p = StrPtr(St)
pp = StrPtr(St)
For x = 0 To Len(St)-1
    'c = ASC(toEnc, x)
    c = @p[x]
    i = (i + 1) Mod 256
    j = (j + s(i)) Mod 256
    Swap s(i), s(j)
    t = (s(i) + s(j)) Mod 256
    k = s(t)
    @pp[fromEncPos] = c Xor k
    Incr fromEncPos
Next
'MID$(fromEnc, fromEncPos) = RBuff
Function = St
Erase s
Erase k

posted August 01, 2001 08:02 AM              

I run my make key program:

MakeKey
Public = 13, 78
Private = 78, 13

I have a public key of 13,78 and a private key of 78,13

My friend Bob, wants to send me a message the text of which is
"h" He takes the message and my public key and
encrypts it like so:

ENCRYPT "h" , 13, 78
Message = 179

Now Bob sends me the message, but sneaky Bill intercepts
the message. Sneaky Bill has my public key and the encrypter
and decrypter programs so he tries the public key with both
programs. . .

ENCRYPT 179 , 13, 78
Message = ASC(13)

DECRYPT 179 , 13, 78
Message = ASC(21)

Sneaky Bill has been foiled!

I get the message and decrypt it using my private key:

DECRYPT 179 , 78, 13
Message = "h"

Oh yes! "h" I will get on it at once!

The power of public key encryption is in the vast amount
of CPU time required to figure out what the private key
is given the public key and the encryption algorithom. The more
complex the relationship between the public key and the
private key the better.

I bet you can figure out what the relationship of my public
and private keys are by just looking at the above example, no CPU
needed.

The CIA might intercept my message and just run my
public key through their SuperKeyCracker2000

SuperKeyCracker2000 13, 78
Private Key = 78, 13

Drats! The CIA can now read my secret messages! I think I might
need a stronger encryption system!

Now some source code to play with:

DIM sMess AS STRING
DIM iMess AS INTEGER
DIM a AS INTEGER
DIM b AS INTEGER
DIM i AS INTEGER

'// The message we are sending is just "h"
sMess = "h"
iMess = ASC(sMess)

'// Public Key = 13 and 78
a = 13
b = 78
i = iMess XOR a
i = (i + b) MOD 255

'// Your secret message (It will be 179)
PRINT "Your message is: "; STR$(i)

'// Your incoming message is 179
iMess = 179
'// Private Key = 78 And 13
a = 78
b = 13
i = (iMess - a) MOD 255
i = i XOR b
sMess = CHR$(i)
PRINT "decoded message is: "; sMess

------------------

posted August 01, 2001 08:47 AM            

Symetric encryption:
 Encrypted = Plaintext -> Crypt(Key)
 Decrypted = Encrypted -> Crypt(Key)

posted August 01, 2001 08:57 AM            

Anyway, your program was not hard to crack since it relies on some symmetric encryption algorithm. First part of the process was
unpacking, really simple since a lot of tools exist for that. Then removing the SoftIce check, simply by replacing SICE by XXXX in the unpacked program,
then removing the size checks by breaking on rtcFileLen and patching in unpacked program. Then the program would run like a charm, and can be quite
easily reversed. Breaking on rtcFileLen, I had the good size of a valid keyfile, then creating and 4192bytes keyfile, I could trace through the
registration checking area. The encryption algorithm was quite simple to reverse, and I had it turned to C within 2 hours or so. The longest part was to
check what are the encrypted strings in the keyfile and how they are checked, it took me a few hours. So to conclude, it took some time, but no real
difficulty, except the fact that is Visual Basic, which stops easily crackers since the generated code is really a mess. The tools used were SoftICE to
trace, IDA to disassemble, HIEW to patch the few needed bytes, and CASPR to unpack.

Once the algorythm reversed, and knowing I can used any key to encrypt a keyfile since it's shipped with the keyfile, the only things I have to do are:
1) create a valid unencrypted keyfile, 
2) generate a random key,
3) encrypt the keyfile with this key,
4) give the user both key and keyfile.
Even if the key is not random, but checked within the executable (not 'clear' comparison, but some one-way stuff like getting the MD5 of the key and
comparing it with a hardcoded MD5, in that way you cannot get the key from the hash), getting a valid key/keyfile would allow to make a generator, and usually
registered users are glad to help us from time to time, or maybe even carding groups can release a valid serial we would use to create a generator.
The only scheme that would deny crackers to make generators, even if in possession of a valid key is public-key cryptography, such as well implemented
RSA. The other thing you can do is leaving some parts of the keyfile unchecked in current version, and each time a generator is released, add new checks to
render it useless, without changing the version number. I think the latest is rather a temporary solution, but can turn many crackers mad   

posted August 01, 2001 09:38 AM            

...but possibly there are other meanings for the term.

It is not really possible to make a key-protected program that can't be broken.
The whole point of the computer is that it is a manipulator of data, and a
program is nothing more than data. Your program is constrained to be in a form
that the computer can run-- so, it is fundamentally unprotected. Breaking any
encryption or protection may take work, but it can't be prevented. The best you
can hope for is to make it a nuisance, or provide other forms of "value added"
that a user won't get with a pirated copy.

posted August 01, 2001 10:53 AM              

How about:
Public Key 125, 53
Private Key 78, 13

DIM sMess AS STRING
DIM iMess AS INTEGER
DIM a AS INTEGER
DIM b AS INTEGER
DIM i AS INTEGER

'// The message we are sending is just "h"
sMess = "h"
iMess = ASC(sMess)

'// Public Key = 125 and 53
a = 125
b = 53

a = 112 XOR a
b = 123 XOR b
i = iMess XOR a
i = (i + b) MOD 255
'// Your secret message
PRINT "Your secert message is: "; STR$(i)

'// Your incoming message is 179
iMess = 179

'// Private Key = 78 And 13
a = 78
b = 13

i = (i - a) MOD 255
i = i XOR b
sMess = CHR$(i)
PRINT "decoded message is: "; sMess

posted August 01, 2001 11:26 AM              

There is how the system works:

The user enters the reg code in to the program:

It looks something like this:

EE4R877 WZA3JUU GP86BYU 3RGDDYT TFEK8L7 19

To verify the reg code is good I have my program
convert the whole thing a series of longs using a
very complex set of math.

I then mask half the bits at random and use whats left and
feed it through a very complex hashing function that
has parts of its steps commented out depending on which
bits are being used and which bits are masked out.

The hashing code is stread out in over 20 places in my program in
the cores of important functions, the resulting values of the
hash are hidden in many odd places inside of important data
that the program is using.

In over 50 places the program does a quick check of the hash
value and sometimes does a bad bad thing if the value is not what is
expected. If it is SUNDAY it might crash the program with a devide by
zero error. . . It might pop up a message like, "Catch the Cows!".

The bottom line is you can not make a all powerful key generator
for my program using the EXE because only half the HASH algorithm
is compiled in any one release of the program. You can make a key
generator that will work for one release but it will break as
soon as a new version is released.

You can not crack an algorithm that was never
compiled into the code!

I have the added bonus of having my programs exchange data with
other users of the program, (interactive game). When one player
upgrades to the newer version of the game host program with a
different version of the hash, it will will detect all other in the
same game that are using fake keys by exchanging a hash value and
has the option of "zapping" them.

To date the only ones that have made fake keys have been
the Russians and the system is detecting them and stopping them
exactly as planned.

posted August 02, 2001 02:33 PM            

Given the public keys and the encryption algorythm in the examples
given the decryption keys and decryption algorythm could be found
in a short amount of tme. (Minutes or at the very outsise hours)

PGP uses large prime factorials, due to the fact that it would take
many hundreds of years given current processing power to find the
private keys.

If you are interested in how they do it follow this link
http://pajhome.org.uk/crypt/rsa/rsa.html

regards
Trevor

posted August 02, 2001 11:25 PM            

In his book, he presented a private key system that encrypted
the plain text message using a random number generator.
If one wrote a program using PBCC random number generator,
I wonder if the code breakers using their decompilers could
'easily' decipher the random number generator code to obtain
the plain text message again?

Thank you to those that reply!

Rodney Wirtz