VB Forum / General / September 2004

"=?Utf-8?B?RGF2aWQgSG9kZ2tpbnM=?="
<DavidHodgkins@discussions.microsoft.com> wrote in news:935F55C8-DC65-4C19-
A701-5F97C6B9B467@microsoft.com:

That's what I do, and that's how I've seen it done.  I'm guessing a
determined hacker could still get at it though.  It's not inconceivable the
Chr() function has an identifiable fingerprint in a compiled exe.  The
value is literal, so that could be examined as well.

It's really all about level of risk.  If you need to keep this password out
of the hands of terrorists, then yeah, you should do more.  You could mask
your values with a few math operations and function calls.  Perhaps use
split to parse them.  There's really no end to the number of ways you could
obfuscate it.

If you're simply trying to keep honest people honest, then you're probably
good how you are.

You didn't mention the Windows plaform you need to support, so the actual
library or call will vary, but don't bother creating your own encryption
routines - they are often buggy and never as safe as the authors think they
are. Use the routines provided by your OS. Or open Google and start
searching for one of the many freebies out there.

On Win2k checkout the "CryptAPI".

hth
-ralph

It is a better method, and is probably as far as you need to go but without
going too far. There'll always be somebody that breaks it, but you've got to
weigh up the ratio of your effort to designing encryption algorithm to your
effort at designing the rest of the program, aswell as the cracker's effort
in breaking it against the cracker's potential gain by breaking it.

I always think that making it so you need to have at least *some* reasonable
knowledge of disassembly / assembly language / machine code to crack it is
always a good benchmark.

FWIW, one of the major problems with designing a licensing algorithm is that
no matter how sophisticated it is, any person cracking it by attempting to
unravel the machine code may not need to know *how it works*, they may only
need to know *where it is*, and just find out what it is supposed to return
and just intercept it before the end.

(Still fwiw)
To this end, I have designed an algorithm to fox people who may be able to
try their hand at this. I haven't implemented it yet, as the component which
it is designed to protect isn't finished yet, but in principle, what it does
is this: the application (my application, that is allowed to use the
component) instantiates it. It then calls a method, passing it an IDispatch*
(object). The component then gets some data from its resource, and calls a
method on this IDispatch which gets the same amount of data from the client
application's resource. It then XORs these two pieces of data together, to
get a string, (n * m * r) long. n is the number of 'security' functions the
component must call off the IDispatch* that it has been passed, m is the
length of the name of each one, r is the 'red-herring' padding factor of the
functions (completely cryptographically random function names). Hidden to
about three or four levels or indirection in the XORed data is the actual
number of functions to call (i.e. only part of the big string represents
valid names of functions at all), and some algorithm runs on the return
values of the functions (also cryptographically random strings), this
algorithm will be probaby just another 3 or 4 levels of indirection, to tell
it which is the correct return value. Hidden in the return value of the
correct function, is some data which is actually relevant to the program.
Hence, if it uses the wrong data - it won't 'refuse' instantiation in any
way, it will just crash spectacularly.
Deliberately designed to make the licensing code 'peppered' all over the
place. Just think of how it will look in machine code -that's all you have to
do... not necessarily understand it!

"David Hodgkins" <DavidHodgkins@discussions.microsoft.com> wrote

...

Depending on who you want to stop, you may just use an encoded string
in some other base (like base 57, or some odd figure).  But for my money,
the trick is to force that hacker to have to look all over your code for the
needed parts to figure out the name/password.

To do that you can simply put the various parts at distant places in your
code, including secondary modules, and so forth.  Calling routines out of
the VB runtine will also force him to look there to know what your code is
doing.

For an example, imagine if the following routines were tucked in amonst all
your other event code, and so forth:

HTH
LFS

Option Explicit

Private HiddenValue As Double

Private Sub Form_Load()
Dim Name As String
Dim dummy As String
Dim idx

   ' Placed in your init code
   HiddenValue = 2.62845

  ' Build Name part
  dummy = runaround()
  For idx = 1 To 14 Step 2
    Name = Name & Puzzle(Val(Mid$(dummy, idx, 2)))
  Next
 
  MsgBox Name

End Sub

Private Function runaround() As String
' Tucked in between two large events, etc...
 runaround = Fakeout1 & Fakeout2
End Function

Public Function Fakeout1() As Variant
' In some .BAS module
Dim data As String
 data = Format(3 / 7.219, ".0000000000000")
 Fakeout1 = Mid$(data, 2)
End Function

Private Function Fakeout2() As Variant
' Tucked in between two large routines, etc...
Dim data As String
 data = HiddenValue * 0.214 * CDec(0.19119787)
 Fakeout2 = Mid$(data, 3)
End Function

Private Function Puzzle(ByVal Index As Long) As String
'  This same routine could be used to build other strings
'  Debug.Print Index
 
 Select Case Index
 Case 1: Puzzle = ""
 Case 2: Puzzle = "mi"
 Case 35: Puzzle = "t"
 Case 38: Puzzle = "ch"
 Case 41: Puzzle = "Jo"
 Case 45: Puzzle = "Pa  "
 Case 49: Puzzle = "h"
 Case 55: Puzzle = "e "
 Case 70: Puzzle = "S"
 ' ...
 End Select
 
End Function