Secure Application (VB6)

Topic

New Reply

I’m about to try my application on a user who does not work for us and not sure of the trust level.

Everything should be OK but I would rather be safe than sorry than them distributing willy nilly.
What I would like to do is implement some kind of serial code system at lets say 6 Monthly intervals.

On first installation, ideally a popup asking for a serial number to proceed.
This has to be unique so possibly a calculation on the current date and time.

So, the user will install for the first time and be prompted for a serial number.
If the current date and time is 11/08/2004 17:15:00 and then for arguments sake, multiply by 3 to give the correct serial.

Can this be done and at 6 monthly intervals, or is there another way ?

Reply | Quote

Replies

How about having a built-in expiration date? Here is some actual code I’ve used. Note that gbAborting is a global “abort” flag, defined in a separate code module.

Private Sub Form_Load()

Dim ldtExpire As Date
Dim lsDate As String

‘Set expiration date as 1/1/2004 – but don’t be obvious
lsDate = CStr(2 2) + “-”

‘here is the day of the month
lsDate = lsDate + CStr((2) – 1#) + “-”

‘Finally have the year
lsDate = lsDate + CStr(1002 * 2)

‘Check for the expiration date
ldtExpire = CDate(lsDate)

If CDate(Now) > ldtExpire + 1 Then

MsgBox “This program expired on ” + _
Format$(CStr(ldtExpire), “mmmm, dd, yyyy”) + vbCrLf + _
“Check http://www.softwarepolish.com” + vbCrLf + _
“for an updated version”, vbCritical, _
“Program Expired!”

gbAborting = True
End If

frmJJJJ_Exit:

'Need to abort if initial Form_load fails
If gbAborting Then
Unload Me
End If

Exit Sub

End Sub

Reply | Quote

Rick

Thanks for your code here.
I’ve had a little play with it and yes there is a possibility I could use it.
I can link it with my FTP to update the user.

The part I’m confused over is where the data is collected.

Dim ldtExpire As Date
Dim lsDate As String

'Set expiration date as 1/1/2004 - but don't be obvious
lsDate = CStr(2  2) + "-"

'here is the day of the month
lsDate = lsDate + CStr((2) - 1#) + "-"

'Finally have the year
lsDate = lsDate + CStr(1002 * 2)

How does this work and how do I use the CStr function ??

Reply | Quote

CStr converts any type of value to a string.
The code fragment assembles “1-1-2004” by concatenating pieces, and obfuscates things by performing some calculations, so that someone who happens to look at the application (for example with a hex editor) will not see 1-1-2004 as a literal string.

Reply | Quote

Hmmmm

A couple of questions on this.

1/ With an HEX Editor, would some-one be able to view the FTP IP, UserName & PassWord which are hard coded ?

2/ With the make up of the date using CStr etc, how do I alter it to a date of my own ?

Reply | Quote

1. Yes, strings that are hard coded can be seen using a hex editor. You can apply some kind of scrambling to the literal strings, so that the strings that can be seen in the exe are useless. But unless you use industry strength enncryption, it may be possible to unscramble them.

Here is a very simple scrambling function:

Function Scramble(AString) As String
Dim i As Integer
Dim strRes As String
For i = Len(AString) To 1 Step -1
strRes = strRes & Chr((410 – i – Asc(Mid(AString, i, 1))) Mod 256)
Next i
Scramble = strRes
End Function

Say that your password is “Dave”. Type ? Scramble(“Dave”) in the immediate window, the result will be “1!7U”. This would be the string you use in your code:

If Me.txtPassword = Scramble(“1!7U”) Then

2. You can make up anything you like. Say that you want the expiration date to be 31 December 2004.

The day is 31. This can be 2 ^ 5 – 1, or 3 * 10 + 1, or 62 / 2, etc.
The month is 12. This can be 17 – 5, or 2 * 2 * 3, or 5 * 3 – 6 /2, etc.
The year is 2004. This is 4 * 501, or 2 * 10 ^3 + 2 ^ 2, etc.

You can concatenate the parts:

lsDate = CStr(2 ^ 5 – 1) & “-”
lsDate = lsDate & CStr”(2 * 2 * 3) & “-”
lsDate = lsDate & CStr(2 * 10 ^ 3 + 2 ^2)
ldtExpire = CDate(lsDate)

or you can use the DateSerial function:

ldtExpire = DateSerial(2 * 10 ^ 3 + 2 ^2, 2 * 2 * 3, 2 ^ 5 – 1)

or you could use the scramble function here too.

Reply | Quote

Hans

[]_#%Ek’%“Ls!*(60E

Reply | Quote

That didn’t survive the browser intact, but you’re welcome.

Reply | Quote

That didn’t survive the browser intact, but you’re welcome.

Reply | Quote

Hans

[]_#%Ek’%“Ls!*(60E

Reply | Quote

1. Yes, strings that are hard coded can be seen using a hex editor. You can apply some kind of scrambling to the literal strings, so that the strings that can be seen in the exe are useless. But unless you use industry strength enncryption, it may be possible to unscramble them.

Here is a very simple scrambling function:

Function Scramble(AString) As String
Dim i As Integer
Dim strRes As String
For i = Len(AString) To 1 Step -1
strRes = strRes & Chr((410 – i – Asc(Mid(AString, i, 1))) Mod 256)
Next i
Scramble = strRes
End Function

Say that your password is “Dave”. Type ? Scramble(“Dave”) in the immediate window, the result will be “1!7U”. This would be the string you use in your code:

If Me.txtPassword = Scramble(“1!7U”) Then

2. You can make up anything you like. Say that you want the expiration date to be 31 December 2004.

The day is 31. This can be 2 ^ 5 – 1, or 3 * 10 + 1, or 62 / 2, etc.
The month is 12. This can be 17 – 5, or 2 * 2 * 3, or 5 * 3 – 6 /2, etc.
The year is 2004. This is 4 * 501, or 2 * 10 ^3 + 2 ^ 2, etc.

You can concatenate the parts:

lsDate = CStr(2 ^ 5 – 1) & “-”
lsDate = lsDate & CStr”(2 * 2 * 3) & “-”
lsDate = lsDate & CStr(2 * 10 ^ 3 + 2 ^2)
ldtExpire = CDate(lsDate)

or you can use the DateSerial function:

ldtExpire = DateSerial(2 * 10 ^ 3 + 2 ^2, 2 * 2 * 3, 2 ^ 5 – 1)

or you could use the scramble function here too.

Reply | Quote

Hmmmm

A couple of questions on this.

1/ With an HEX Editor, would some-one be able to view the FTP IP, UserName & PassWord which are hard coded ?

2/ With the make up of the date using CStr etc, how do I alter it to a date of my own ?

Reply | Quote

CStr converts any type of value to a string.
The code fragment assembles “1-1-2004” by concatenating pieces, and obfuscates things by performing some calculations, so that someone who happens to look at the application (for example with a hex editor) will not see 1-1-2004 as a literal string.

Reply | Quote

Rick

Thanks for your code here.
I’ve had a little play with it and yes there is a possibility I could use it.
I can link it with my FTP to update the user.

The part I’m confused over is where the data is collected.

Dim ldtExpire As Date
Dim lsDate As String

'Set expiration date as 1/1/2004 - but don't be obvious
lsDate = CStr(2  2) + "-"

'here is the day of the month
lsDate = lsDate + CStr((2) - 1#) + "-"

'Finally have the year
lsDate = lsDate + CStr(1002 * 2)

How does this work and how do I use the CStr function ??

Reply | Quote

Rick

Is it possible for the gbAborting code ?

Reply | Quote

Dave, I’m not sure what your question is. I agree with what HansV suggested.

The program uses the gbAborting variable as shown in my first post. I have error trapping code in each routine where errors could occur. If a non-recoverable error occurs, I set gbAborting = True.

There is logic to “bail” out of the program, which gets called from Sub Main. This could do things such as closing open database connections, closing any other open files, and giving the bad news to the user.

Reply | Quote

Rick

Thanks.
I had the feeling the gbAborting routine was something specific to the code you supplied.
I’ve sorted it now with my own error trapping and get out situations.

Thanks for the code anyway, it works fine now.

Can’t wait till the expiry date on the application, the phones will go nuts !!
I think I’ll invest in an answer machine.

Reply | Quote

Another option for encrypting a string is to use simple XOR encryption. Example:

Public Function EncryptTextXOR(strText As String, _
strPWD As String) As String
' Encrypt or decrypt a string using the XOR operator.

Dim b() As Byte
Dim b_Pwd() As Byte
Dim lngPos As Long
Dim lngLen As Long
Dim n As Long

b = strText
b_Pwd = strPWD
lngLen = LenB(strPWD)

For n = 0 To LenB(strText) - 1
' Get the next number between 0 and lngLen - 1:
lngPos = (n Mod lngLen)
b(n) = b(n) Xor b_Pwd(lngPos)
Next n
EncryptTextXOR = b

End Function

The same function is sued to encrypt or decrypt string, given a password. Sample results:

? EncryptTextXOR("MarkD","123")
|SAZv
? EncryptTextXOR("|SAZv","123")
MarkD

For more info see MSKB 110308:

How To Encrypt a String with Password Security

Brief quotes: “Software tools for debugging and viewing binary code can easily find ASCII strings stored in compiled executable .EXE programs.” Some options suggested. Re XOR: “The exclusive-OR operator (Xor in the Basic language) performs a logical exclusion on two expressions. … A useful behavior of Xor is that the first expression expr1 is returned without losing any bits when you perform Result Xor expr2. This ability to restore the first expression from the Result combined with the second expression is why the Xor function is useful for encryption.” See article for more info. Note that XOR encryption is not industrial strength – an expert hacker may be able to crack code – but most non-experts will not be able to decipher encrypted text w/o password. To make things more difficult for any would-be hacker, use a longer password. Also, passwords are case-sensitive – sort of:

? EncryptTextXOR(“MarkD”,”xyz”)
5 =
? EncryptTextXOR(“5 =”,”XYZ”)
mARKd
? EncryptTextXOR(“5 =”,”Xyz”)
marKD

(Some characters were not displayed in HTML above)

HTH

Reply | Quote

PS: If using XOR to encrypt text string, can make it a little harder to crack code by adding a psuedo-random seed to function. Example:

Public Function EncipherText(ByVal strText As String, ByVal strPwd As String) As String

Dim i As Long
Dim n As Long
Dim s As String

Randomize
For i = 1 To Len(strPwd)
n = n + Asc(Mid$(strPwd, i, 1))
Next
Rnd -n

' XOR using random A-Z char
For i = 1 To Len(strText)
s = Int((vbKeyZ - vbKeyA + 1) * Rnd + vbKeyA)
Mid$(strText, i, 1) = Chr$(Asc(Mid$(strText, i, 1)) Xor s)
Next i

EncipherText = strText

End Function

Test results (not all characters displayed in HTML):

? EncipherText("MarkD","ABC123")
7$8
? EncipherText(" 7$8 ","ABC123")
MarkD
? EncipherText(" 7$8 ","abc123")
_ce|
? EncipherText(" 7$8 ","Abc123")
@{}q@

At least now the password is actually case-sensitive… this is still not industrial-strength encryption by any standard, but should work for simple scrambling of text strings.

HTH

Reply | Quote

PS: If using XOR to encrypt text string, can make it a little harder to crack code by adding a psuedo-random seed to function. Example:

Public Function EncipherText(ByVal strText As String, ByVal strPwd As String) As String

Dim i As Long
Dim n As Long
Dim s As String

Randomize
For i = 1 To Len(strPwd)
n = n + Asc(Mid$(strPwd, i, 1))
Next
Rnd -n

' XOR using random A-Z char
For i = 1 To Len(strText)
s = Int((vbKeyZ - vbKeyA + 1) * Rnd + vbKeyA)
Mid$(strText, i, 1) = Chr$(Asc(Mid$(strText, i, 1)) Xor s)
Next i

EncipherText = strText

End Function

Test results (not all characters displayed in HTML):

? EncipherText("MarkD","ABC123")
7$8
? EncipherText(" 7$8 ","ABC123")
MarkD
? EncipherText(" 7$8 ","abc123")
_ce|
? EncipherText(" 7$8 ","Abc123")
@{}q@

At least now the password is actually case-sensitive… this is still not industrial-strength encryption by any standard, but should work for simple scrambling of text strings.

HTH

Reply | Quote

Another option for encrypting a string is to use simple XOR encryption. Example:

Public Function EncryptTextXOR(strText As String, _
strPWD As String) As String
' Encrypt or decrypt a string using the XOR operator.

Dim b() As Byte
Dim b_Pwd() As Byte
Dim lngPos As Long
Dim lngLen As Long
Dim n As Long

b = strText
b_Pwd = strPWD
lngLen = LenB(strPWD)

For n = 0 To LenB(strText) - 1
' Get the next number between 0 and lngLen - 1:
lngPos = (n Mod lngLen)
b(n) = b(n) Xor b_Pwd(lngPos)
Next n
EncryptTextXOR = b

End Function

The same function is sued to encrypt or decrypt string, given a password. Sample results:

? EncryptTextXOR("MarkD","123")
|SAZv
? EncryptTextXOR("|SAZv","123")
MarkD

For more info see MSKB 110308:

How To Encrypt a String with Password Security

Brief quotes: “Software tools for debugging and viewing binary code can easily find ASCII strings stored in compiled executable .EXE programs.” Some options suggested. Re XOR: “The exclusive-OR operator (Xor in the Basic language) performs a logical exclusion on two expressions. … A useful behavior of Xor is that the first expression expr1 is returned without losing any bits when you perform Result Xor expr2. This ability to restore the first expression from the Result combined with the second expression is why the Xor function is useful for encryption.” See article for more info. Note that XOR encryption is not industrial strength – an expert hacker may be able to crack code – but most non-experts will not be able to decipher encrypted text w/o password. To make things more difficult for any would-be hacker, use a longer password. Also, passwords are case-sensitive – sort of:

? EncryptTextXOR(“MarkD”,”xyz”)
5 =
? EncryptTextXOR(“5 =”,”XYZ”)
mARKd
? EncryptTextXOR(“5 =”,”Xyz”)
marKD

(Some characters were not displayed in HTML above)

HTH

Reply | Quote

I typically show the expiration date on the main form of the application. It may not be a good idea to keep the users in the dark about the expiration date.

For example, I had a user who was planning a lengthy road trip. They would have been REALLY unhappy if the application suddenly stopped working with no advance notice!

Reply | Quote

I’ve toyed with expiration dates in the past, and am currently feeling that I don’t like them. The DOS days of a batch file to reset the date before running the application are gone; while Windows users can reset the date to perform a special date application, it is a pain, and so date is a better lock than it used to be. However, a date-limited license seems to send a bad message to the consumer. We are, I feel, of the feeling that once we have paid for software, we should be able to run that software as frequently and for as long as we like.

That said, I can see a use for date-limited applications, but it is a restricted market. Examples that come to mind include:
(a) beta-test software, where I distribute it for evaluation but would be embarrassed to have someone use it six months from now and
( client-specified one-time use, as when a colleague asks for a copy of a utility to help them do a specific job at a specific client site.

I’m currently looking at a license that causes the unlicensed application to (a) issue a pop-up message at initialization and ( optionally restrict iterations to 100 documents, 100 records, or whatever. Licensing involves grabbing machine charactersitcis and emailing a request for a scrambled key (hence my search for XOR encryption). My distribution channel is low-volume, so responding to an email is not a hassle for me.

Comments?

Reply | Quote

We use usage keys which enable the application for a period of time. Prior to the expiration, nags appear to remind the client to call for a new usage key. Once the key expires, they cannot use the application until they have an updated usage key. Our clients know perfectly well what the rules are before they start using the application.

Reply | Quote

I typically show the expiration date on the main form of the application. It may not be a good idea to keep the users in the dark about the expiration date.

For example, I had a user who was planning a lengthy road trip. They would have been REALLY unhappy if the application suddenly stopped working with no advance notice!

Reply | Quote

I’ve done similar routines in some of my programs. You might want to also add a couple of ‘traps’ to your code, as well. Put a clear-text field in that has a date in it. When the program runs, have it compare the checksum of the date to see if it has been changed. If it has, pop up a warning messages, stating that the program has been tampered with – then shut down.

If you REALLY want to be nasty, have it write a value to a data file that is a ‘tamper lock’. The file would have been created when the program was running correctly, so restoring the program from a backup won’t help. They could only get it running by wiping out the data and starting fresh, or restoring from a backup – prior to the tampering. It’s not foolproof, but you just want to prevent the casual hacker. Making things too complicated can sometimes come back to bite you – hard!

Brian

Reply | Quote

Brian

Thanks for the additional info.

have it compare the checksum of the date to see if it has been changed

Could you elaborate on this ?
Sounds very interesting indeed !!

Reply | Quote

Sure – here’s a piece of VB6 code I whipped together.

Option Explicit

‘Declare a “Dummy” date – as bait for would-be hackers
Dim pDummyDate As String

Private Sub Form_Load()
‘Now, set our dummy date.
pDummyDate = “01/01/2004”
Call Check_It
End
End Sub

Private Sub Check_It()
Dim i As Integer
Dim CkSum As Long

‘In this routine, we add up the character values for the string, and compare
‘it against the checksum from the original ’01/01/2004’.
‘If it has changed, we know that someone has used a hex editor to try
‘to change the date embedded in our code.

For i = 1 To Len(pDummyDate)
CkSum = CkSum + Asc(Mid(pDummyDate, i, 1))
Next

‘Now, check to see if the checksums match. If they don’t, we
‘create a bogus error.
If CkSum 486 Then i = i / 0
End Sub

———————————————

Of course, it’s very simple, but it would work as I mentioned. You could have other
pieces of ‘trap’ code sprinkled throughout the code. Internet addresses, for example, could
also be used, so that a hacker couldn’t modify a hard-coded address.

Reply | Quote

Sure – here’s a piece of VB6 code I whipped together.

Option Explicit

‘Declare a “Dummy” date – as bait for would-be hackers
Dim pDummyDate As String

Private Sub Form_Load()
‘Now, set our dummy date.
pDummyDate = “01/01/2004”
Call Check_It
End
End Sub

Private Sub Check_It()
Dim i As Integer
Dim CkSum As Long

‘In this routine, we add up the character values for the string, and compare
‘it against the checksum from the original ’01/01/2004’.
‘If it has changed, we know that someone has used a hex editor to try
‘to change the date embedded in our code.

For i = 1 To Len(pDummyDate)
CkSum = CkSum + Asc(Mid(pDummyDate, i, 1))
Next

‘Now, check to see if the checksums match. If they don’t, we
‘create a bogus error.
If CkSum 486 Then i = i / 0
End Sub

———————————————

Of course, it’s very simple, but it would work as I mentioned. You could have other
pieces of ‘trap’ code sprinkled throughout the code. Internet addresses, for example, could
also be used, so that a hacker couldn’t modify a hard-coded address.

Reply | Quote

Brian

Thanks for the additional info.

have it compare the checksum of the date to see if it has been changed

Could you elaborate on this ?
Sounds very interesting indeed !!

Reply | Quote

I’ve done similar routines in some of my programs. You might want to also add a couple of ‘traps’ to your code, as well. Put a clear-text field in that has a date in it. When the program runs, have it compare the checksum of the date to see if it has been changed. If it has, pop up a warning messages, stating that the program has been tampered with – then shut down.

If you REALLY want to be nasty, have it write a value to a data file that is a ‘tamper lock’. The file would have been created when the program was running correctly, so restoring the program from a backup won’t help. They could only get it running by wiping out the data and starting fresh, or restoring from a backup – prior to the tampering. It’s not foolproof, but you just want to prevent the casual hacker. Making things too complicated can sometimes come back to bite you – hard!

Brian

Reply | Quote

Rick

Thanks.
I had the feeling the gbAborting routine was something specific to the code you supplied.
I’ve sorted it now with my own error trapping and get out situations.

Thanks for the code anyway, it works fine now.

Can’t wait till the expiry date on the application, the phones will go nuts !!
I think I’ll invest in an answer machine.

Reply | Quote

Dave, I’m not sure what your question is. I agree with what HansV suggested.

The program uses the gbAborting variable as shown in my first post. I have error trapping code in each routine where errors could occur. If a non-recoverable error occurs, I set gbAborting = True.

There is logic to “bail” out of the program, which gets called from Sub Main. This could do things such as closing open database connections, closing any other open files, and giving the bad news to the user.

Reply | Quote

Rick

Is it possible for the gbAborting code ?

Reply | Quote

How about having a built-in expiration date? Here is some actual code I’ve used. Note that gbAborting is a global “abort” flag, defined in a separate code module.

Private Sub Form_Load()

Dim ldtExpire As Date
Dim lsDate As String

‘Set expiration date as 1/1/2004 – but don’t be obvious
lsDate = CStr(2 2) + “-”

‘here is the day of the month
lsDate = lsDate + CStr((2) – 1#) + “-”

‘Finally have the year
lsDate = lsDate + CStr(1002 * 2)

‘Check for the expiration date
ldtExpire = CDate(lsDate)

If CDate(Now) > ldtExpire + 1 Then

MsgBox “This program expired on ” + _
Format$(CStr(ldtExpire), “mmmm, dd, yyyy”) + vbCrLf + _
“Check http://www.softwarepolish.com” + vbCrLf + _
“for an updated version”, vbCritical, _
“Program Expired!”

gbAborting = True
End If

frmJJJJ_Exit:

'Need to abort if initial Form_load fails
If gbAborting Then
Unload Me
End If

Exit Sub

End Sub

Reply | Quote

If you are concerned about the trust level of the user, then you would need to invest a significant amount of time/money in trying to protect the program.

Least expensive approach is to use a protection front end such as ProtectionPlus from http://www.softwarekey.com/%5B/url%5D.

Reply | Quote

If you are concerned about the trust level of the user, then you would need to invest a significant amount of time/money in trying to protect the program.

Least expensive approach is to use a protection front end such as ProtectionPlus from http://www.softwarekey.com/%5B/url%5D.

Reply | Quote

> a user who does not work for us and not sure of the trust level.

I’m in the same boat. I had a nifty scheme in Word6 that wrote and then locked a function on the fly; it was tamper-proof even by me. After Word6 we could not lock individual functions, so that sceheme died.

I’m now considering a new method. Specifically I wanted an expiration feature that did NOT depend on a hard-coded date string in any application. (I’ve read the thread up to today’s date). I want a function that sits in my Utils.DOT utility library, that can be called by any one of my 50+ applications, and can permit access to the application code for, say, a period of seven days. I’ll take/send the application to the user and tell them “The password is case-sensitive: rRI@C2ws13Je.

Pretty impressive password string, eh?

The method I’m considering is to ignore all but the two leading digits of the string; to take them, reverse them, and check that this Day number is within a fixed distance from the current date.

Example: Using a “fixed expiry date” of seven days after installation, and taking today’s date as 2005/01/12, I would tell today’s client that the password is rRI@C2ws13Je, and that it will expire in seven days.

Take the two leading digits 21.

Reverse them 12

If this number lies in the range of today’s day number and today’s day number PLUS 7 then the password is deemed correct.

Now, if the user plays with the program for a week, it runs fine. on the eighth day it fails. The user won’t be able to find a hard-coded date in my code.

Of course, if the user tries it a month later, it will work again, fleetingly, but we’re looking at a user who doesn’t know VBA or programming anyway. At worst, they might tumble to the fact that the code runs on the 12th through 18th of every month.

And no, I’m not going to tell you my interval (7 days) or which digits I’ll use (leading two), nor whether I’m going to reverse them. The general principle can be modified for each one of us …..

Reply | Quote

> a user who does not work for us and not sure of the trust level.

I’m in the same boat. I had a nifty scheme in Word6 that wrote and then locked a function on the fly; it was tamper-proof even by me. After Word6 we could not lock individual functions, so that sceheme died.

I’m now considering a new method. Specifically I wanted an expiration feature that did NOT depend on a hard-coded date string in any application. (I’ve read the thread up to today’s date). I want a function that sits in my Utils.DOT utility library, that can be called by any one of my 50+ applications, and can permit access to the application code for, say, a period of seven days. I’ll take/send the application to the user and tell them “The password is case-sensitive: rRI@C2ws13Je.

Pretty impressive password string, eh?

The method I’m considering is to ignore all but the two leading digits of the string; to take them, reverse them, and check that this Day number is within a fixed distance from the current date.

Example: Using a “fixed expiry date” of seven days after installation, and taking today’s date as 2005/01/12, I would tell today’s client that the password is rRI@C2ws13Je, and that it will expire in seven days.

Take the two leading digits 21.

Reverse them 12

If this number lies in the range of today’s day number and today’s day number PLUS 7 then the password is deemed correct.

Now, if the user plays with the program for a week, it runs fine. on the eighth day it fails. The user won’t be able to find a hard-coded date in my code.

Of course, if the user tries it a month later, it will work again, fleetingly, but we’re looking at a user who doesn’t know VBA or programming anyway. At worst, they might tumble to the fact that the code runs on the 12th through 18th of every month.

And no, I’m not going to tell you my interval (7 days) or which digits I’ll use (leading two), nor whether I’m going to reverse them. The general principle can be modified for each one of us …..

Reply | Quote