• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1225
  • Last Modified:

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)
	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
                                            

Open in new window

0
formadmirer
Asked:
formadmirer
  • 4
  • 4
  • 3
1 Solution
 
CaptainCyrilCommented:
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?
0
 
CaptainCyrilCommented:
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

Open in new window

0
 
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.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
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.
0
 
CaptainCyrilCommented:
The more info you give us the more we can help you.
0
 
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
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.
0
 
CaptainCyrilCommented:
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. :-)
0
 
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!
0
 
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.
0
 
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.
0
 
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 ;)
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 4
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now