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.

Sum = 0
Index = 1
FOR i = 1 TO LEN(lcString)
	ch = SUBSTR(lcString, i, 1)
		Sum = Sum + VAL(ch)*(Index*2)
			SUM = SUM + (ASC(ch)-55)*(Index*2)
	Index = Index + 1
Return Sum

Open in new window

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
If you mean we have the Index and Sum you wish to get the original string back?

What are the givens?

How long can the original string be?
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
The code can be made even smaller:

Sum = 0
FOR Index = 1 TO LEN(lcString)
	ch = SUBSTR(lcString, Index, 1)
		Sum = Sum + VAL(ch)*(Index*2)
		Sum = Sum + (ASC(ch)-55)*(Index*2)

Open in new window

Olaf DoschkeSoftware DeveloperCommented:
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.
Starting with Angular 5

Learn the essential features and functions of the popular JavaScript framework for building mobile, desktop and web applications.

Olaf DoschkeSoftware DeveloperCommented:
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.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
The more info you give us the more we can help you.
formadmirerAuthor Commented:
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
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
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.
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
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. :-)
formadmirerAuthor Commented:
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!
Olaf DoschkeSoftware DeveloperCommented:
Well, there are many solutions to your problem already. And reversability is not neccessary. A one-way algorithm, which also is called a hash is not uncommon to check for the validity of a message, or software registration or whatever.

For example hashes are also stored instead of passwords. Instead of decrypting an encrpyted password to compare with the entered password at login, the password entered is hashed in the same way it was hashed for the first time, to be stored in a database. And then the two hashes are compared. This strategy relieves you from storing that secret. If a hacker get's your user data he's not able to decrypt passwords, not even by bute force attack. The only attack vector is to compute hashes of words or names or dates, which are coommonly used as passwords and see, if you find them in the user data. But there's a weapon against that: adding random "sand" to the user entered password, before hashing that. I could go on, but that leads too far off.

In your case your hash algorithm would compute the same hash value of 10 for "12" and "31", which means both "12" and "31" would count as equal in a password check. But that's just due to the shortness of the password and the bad algorithm. A hash algorithm should better compute totally different values for even just slightly different passwords. And there are well known algortihms like SHA or HMAC. VFPEncryption.fll has them all for easy use with VFP.

My idea of a software registration is already outlined and very common, the name for it is key server. There are third party products for software registration, you don't need to reinvent the wheel. Pick one of the existing ones... http://en.wikipedia.org/wiki/License_manager

For example http://www.agilis-sw.com/ActivationLandingPage.htm

It costs, yes. But your time to reinvent the wheel costs more, or you only get a half baked solution, and I'd also say that about myself, even though it seems I know a bit more about encryption and hashing and security related algorithms than you do.

Yes, it's also common to use hardware serial numbers to check a license validity, but that's not done by decryption, you rather compute several hashes of hardware serial keys and recompute them for a validity check. You better do that in a way you can still see part of the hashes are valid and accept change of one hardware component to allow that without your interaction to reactivate the software.

Also: Is the revenue you expect really justifying activation licensing and your efforts on this? There are third party services for software distribution, too. You can cut down your efforts and even let them market it. That's perhaps more important for a success than a protection. That also depends on the type of software of course.

Bye, Olaf.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Olaf DoschkeSoftware DeveloperCommented:
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.
formadmirerAuthor Commented:
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 ;)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.