VFP Char String from Encoded Number
Thanks to CaptainCyril this will take a string composed of both characters and numbers and convert it to numbers.
What I also need (if possible) is to reverse the process, take the numbers and get the original character/number string back.
What I also need (if possible) is to reverse the process, take the numbers and get the original character/number string back.
Sum = 0
Index = 1
FOR i = 1 TO LEN(lcString)
ch = SUBSTR(lcString, i, 1)
IF ISDIGIT(ch)
Sum = Sum + VAL(ch)*(Index*2)
ELSE
IF ISALPHA(ch)
SUM = SUM + (ASC(ch)-55)*(Index*2)
ENDIF
ENDIF
Index = Index + 1
ENDFOR
Return Sum
The code can be made even smaller:
Sum = 0
FOR Index = 1 TO LEN(lcString)
ch = SUBSTR(lcString, Index, 1)
IF ISDIGIT(ch)
Sum = Sum + VAL(ch)*(Index*2)
ELSE
Sum = Sum + (ASC(ch)-55)*(Index*2)
ENDIF
ENDFOR
RETURN Sum
The algorithm isn't reversable.
Just look into the original in two cases:
lcString="12" is encoded as Sum of 1*2+2*4 = 10
lcString="31" is encoded as Sum of 3*2+1*4 = 10
So you can't tell what you came from, if the encoded sum is 10. This get's worse for longer strings. This is really just a one way algorithm.
Bye, Olaf.
Just look into the original in two cases:
lcString="12" is encoded as Sum of 1*2+2*4 = 10
lcString="31" is encoded as Sum of 3*2+1*4 = 10
So you can't tell what you came from, if the encoded sum is 10. This get's worse for longer strings. This is really just a one way algorithm.
Bye, Olaf.
What's your real world problem? You seem to want to encode some customer specific data like name, serial number into a product key and get it back. This is not the way to go, as that makes very long product keys.
Information theory should be known to you as a developr. With N bits you can only store as much information as is in n bits, and not more. Eg you can compress english text with a mean space of 1.1 bit per letter. That doesn't really ork for small texts, though.
Compression can help you get to that theoretical level of a bit per letter, but there is a limitation of how for you get some information compressed. Eg a 16 char product key with letters and digits can store 36^16=7,95866111 × 10^24 different product keys, which sounds like awfully lot, but that's just holding 82 bits, 2^82=4,83570328 × 10^24 and 2^83 = 9,67140656 × 10^24
So ideally you could store 82 letter long englisch texts, but prosa, lyrics, not adresses or such with cryptic parts like postal codes.
I don't know if I'm totally wrong here and telling you uninteresting stuff for your case, but no matter how you want to make use of your encryption/decryption, you better go for standards than for some self made thing.
In regard to product codes simply store them in a database. Store additional data, once a customer registers. You'll also detect double usage of product keys that way. And while you can't know if a double used key was guessed or copied from the first user or from a product box (on which it shoud not be displayed, of course) you can limit the random guess by just giving out product codes on demand by random generation, not sequential. Then you can be quite sure, if you created 100 codes out of 10^24, that guessing a correct one from knowing one or another is impossible.
Bye, Olaf.
Information theory should be known to you as a developr. With N bits you can only store as much information as is in n bits, and not more. Eg you can compress english text with a mean space of 1.1 bit per letter. That doesn't really ork for small texts, though.
Compression can help you get to that theoretical level of a bit per letter, but there is a limitation of how for you get some information compressed. Eg a 16 char product key with letters and digits can store 36^16=7,95866111 × 10^24 different product keys, which sounds like awfully lot, but that's just holding 82 bits, 2^82=4,83570328 × 10^24 and 2^83 = 9,67140656 × 10^24
So ideally you could store 82 letter long englisch texts, but prosa, lyrics, not adresses or such with cryptic parts like postal codes.
I don't know if I'm totally wrong here and telling you uninteresting stuff for your case, but no matter how you want to make use of your encryption/decryption, you better go for standards than for some self made thing.
In regard to product codes simply store them in a database. Store additional data, once a customer registers. You'll also detect double usage of product keys that way. And while you can't know if a double used key was guessed or copied from the first user or from a product box (on which it shoud not be displayed, of course) you can limit the random guess by just giving out product codes on demand by random generation, not sequential. Then you can be quite sure, if you created 100 codes out of 10^24, that guessing a correct one from knowing one or another is impossible.
Bye, Olaf.
The more info you give us the more we can help you.
ASKER
Thanks. Here's what I'm trying to accomplish. I need a 'simple' software registration solution and, like Olaf just warned against, I was trying to come up with something that hasn't been done before (or is at least not common.) Don't ask me why, that's just the way my head works.
I had looked at
http://www.codeproject.com/Articles/28550/Protecting-Your-Software-Using-Simple-Serial-Numbe
which I really like because it's simple.
The code in my project already includes the ability to gather required hardware information from the host PC, the ability (thanks to numerous help replies here) to encrypt some portion of that data, and then to write it to the registry.
These components all work great already but it's not a complete solution.
With the method outlined in the URL above I could create a register page written in PHP to automate the process. However the code on the site is for vb (I believe) and I don't know how to convert it to work with vfp 9.
I had also looked at
http://www.codeproject.com/Articles/15496/Application-Trial-Maker
but it is written in C# I believe. And, truthfully, this might be a bit more complex than what I need. Again great, but I have no way to convert it.
And, finally, I looked at AuthCode Generator – version 2.02 By Gregory L. Reichert (sorry no link - the website is down). This too looked very good, and, unlike the other two, it's written for VFP. However the web components are for use with ASP and unfortunately I know nothing of ASP. I would have to use PHP.
I did try to convert the ASP to PHP both through an online form and through a desktop application but without luck.
This is what I am trying to accomplish and where I am at right now.
I had looked at
http://www.codeproject.com/Articles/28550/Protecting-Your-Software-Using-Simple-Serial-Numbe
which I really like because it's simple.
The code in my project already includes the ability to gather required hardware information from the host PC, the ability (thanks to numerous help replies here) to encrypt some portion of that data, and then to write it to the registry.
These components all work great already but it's not a complete solution.
With the method outlined in the URL above I could create a register page written in PHP to automate the process. However the code on the site is for vb (I believe) and I don't know how to convert it to work with vfp 9.
I had also looked at
http://www.codeproject.com/Articles/15496/Application-Trial-Maker
but it is written in C# I believe. And, truthfully, this might be a bit more complex than what I need. Again great, but I have no way to convert it.
And, finally, I looked at AuthCode Generator – version 2.02 By Gregory L. Reichert (sorry no link - the website is down). This too looked very good, and, unlike the other two, it's written for VFP. However the web components are for use with ASP and unfortunately I know nothing of ASP. I would have to use PHP.
I did try to convert the ASP to PHP both through an online form and through a desktop application but without luck.
This is what I am trying to accomplish and where I am at right now.
I also use something similar to yours but reversible. I play on ASCII and I check for Hard Disk label and date of installation and I use that to identify the client and it is unique. After that I add many things like options in the software, expiry date and so on so forth. The most important thing is to have a checksum that ensures that no fraud is being done.
I also use PHP to detect the client for error reporting and liveupdates. :-)
I also use PHP to detect the client for error reporting and liveupdates. :-)
ASKER
Yes, this is all new to me. The company I work for is going to attempt to offer a shareware product and they want it all nice an locked up, and it's been left up to me to figure out how to do it.
What I've come to learn is that the reversability is the key (no pun intended but kinda cool).
I am leaning more towards the solution provided in the first URL I posted. However, in order for that to work I must find something that generates only numbers and no characters to use as the key. So far I haven't been able to find this.
That's why I was asking for help earlier with a function to take a string composed of alphanumeric characters and return only numbers.
It wasn't until later that I realized it would have to be reversible...
If I can come up with no other solution, I may grab a motherboard serial and combine it with another and then strip out all the characters leaving only the numbers - that just came to me as I was typing this and may actually work!
What I've come to learn is that the reversability is the key (no pun intended but kinda cool).
I am leaning more towards the solution provided in the first URL I posted. However, in order for that to work I must find something that generates only numbers and no characters to use as the key. So far I haven't been able to find this.
That's why I was asking for help earlier with a function to take a string composed of alphanumeric characters and return only numbers.
It wasn't until later that I realized it would have to be reversible...
If I can come up with no other solution, I may grab a motherboard serial and combine it with another and then strip out all the characters leaving only the numbers - that just came to me as I was typing this and may actually work!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As a side topic look at this for software updating: http://www.sweetpotatosoftware.com/spsblog/2008/02/15/VFPApplicationUpdatingMadeSimple.aspx
You can also embed license checks in this, for checking the legitimacy of an update, for example, if you don't want to go for third party support.
Bye, Olaf.
You can also embed license checks in this, for checking the legitimacy of an update, for example, if you don't want to go for third party support.
Bye, Olaf.
ASKER
Wow. Once again thank you Olaf and everyone else for your replies.
Olaf, you asked if the potential revenue was justifying my time working on this. The simple answer is no. I honestly doubt that this tiny little app will ever see the first purchase.
I've worked on this for two nights now and I'm moving on. I was able to get half of the registration process complete, the part that takes place in VFP.
The other half involves PHP/MySQL on the server side which I will tackle another day.
Now I am moving on to working on a simple ftp solution for use within this same program. I don't know how involved that will get yet.
I wear many hats here. My actual job is product sourcing along with some web development. But lately I've been forced to take on the old fp app that's been in use here since 2001. And that's why I've been here on EE a lot lately ;)
Olaf, you asked if the potential revenue was justifying my time working on this. The simple answer is no. I honestly doubt that this tiny little app will ever see the first purchase.
I've worked on this for two nights now and I'm moving on. I was able to get half of the registration process complete, the part that takes place in VFP.
The other half involves PHP/MySQL on the server side which I will tackle another day.
Now I am moving on to working on a simple ftp solution for use within this same program. I don't know how involved that will get yet.
I wear many hats here. My actual job is product sourcing along with some web development. But lately I've been forced to take on the old fp app that's been in use here since 2001. And that's why I've been here on EE a lot lately ;)
What are the givens?
How long can the original string be?