Strconv() data corrupted in exe creation?

[grahamrhind]

Hello,

I distribute lookup tables with an application, which had been encrypted using Cryptor. As Cryptor does not work well with Windows 7 I altered the encryption to use strconv(). This works fine in testing.

When building an .exe file with InstallShield 5 for Foxpro these tables go into the build process looking correct, but come out of it encoded differently, which makes them useless. Can anybody confirm that this occurs, tell me why and whether there's a workaround?

If not, does anybody have a simple but effective (and quickly implemented!) piece of code for basic encryption (it doesn't have to be hacker proof) which won't get messed up by Installshield? I'm using VFP 9.

Many thanks.

 

[Dan Freeman]

What does Installshield have to do with building an exe? You use the Foxpro project manager to build an exe and Installshield to build an installer.

Which process is messing up? Are your lookup tables built into the exe or separate files? It seems rather far-fetched that Installshield would alter the payload it delivers so I fear there are some details being left out here.

 

[grahamrhind]

Thanks Dan - to clarify, I'm talking about Installshield packing up all the files into a .cab file and then into setup.exe. When that setup.exe gets run, the encoding of the tables which get unpacked has changed. The lookup tables are separate from the Foxpro .exe.

I know it sounds weird - I have checked that correct files are being used by Installshield, with the right dates and sizes.

 

[grahamrhind]

To illustrate, please find attached an image of the same records, before and after.

This is only happening to tables I've strconv'ed with

strconv(fieldname,14,1033)

Tables encrypted with Cryptor didn't have this issue.

 

[Dan Freeman]

This sounds like a good question for an Installshield support forum.

 

[DSummZZZ]

Question; do you get the same behavior if you don't use the '1033' parameter?
I'm curious because I am using a statement similar to this one for an encryp/decrypt routine, but it is in-house and not distributed.

cEncrypted = STRCONV(STRCONV(STRCONV(m.SomeVariable, 13), 13), 13) 

cDecrypted = STRCONV(STRCONV(STRCONV(m.cEncrypted, 14), 14), 14)

However, I do have an app I distribute using cryptor and Installshield Express generated on a W7 box, and have seen no issues with it.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Graham,

How exactly are you using STRCONV()? If you are using an option that relies on the current locale ID, surely that would go wrong if you decrypt on a system in a different locale.

I'm not saying that's the cause of your problem, but it might be something to keep in mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[grahamrhind]

Dave,

Interesting .... it works fine without the 1033 parameter.

My concern is that, without that parameter, the data will unencode differently when used in different parts of the world. Any way around that?

By the way, I'm on Windows 7 64 bit, which won't allow the rather old Cryptor dll to be hooked into the install file. It does still work on an old XP box, but that is on its last leg, which is why I want to switch encryption systems.

 

[grahamrhind]

Mike,

I'm specifying English as a locale (1033) in both the encryption and decryption parts of the process, because I want it to always work in the same way, regardless of where the user happens to be .....

 

[Olaf Doschke]

If you want easy en/decryption without being OS version dependant, then use craig boyds vfpencryption FLL:

http://www.sweetpotatosoftware.com/SPSBlog/2009/08/09/MajorVFPEncryptionUpdate.aspx

base64 encoding is not locale specific at all and the regionalidentifier parameter is not meant for that kind of stringconversion.

base64 is taking the input as a simple ascii string, no matter how it's encoded, which codepage or other charset this is, bae64 is taking in the pure bytes. It is only chopping 3 bytes = 24 bits into 4 times 6 bits, generating 4 chars out of 3, so only 64 characters are needed per character of the base64 "encoded" message.

But indeed this is NO encryption at all, it's simply a spreading of the bits of the original message. It's what all mail programs are doing with attachments because of the limited allowed cahracter set for eMail transfer. Many more languages than VFP can decrypt a base64 encoded message.

Also you MUST use strconv(value,13) to encrypt and strconv(value,14) to decode in that order, as decoding only is done on the base64 subset of 64 characters. Eg: strconv(strconv('|',13),14) is '|' again, but strconv(strconv('|',14),13) is empty, as strconv(x,14) is decoding base64 and base64 only allows a certain set of chars, which include letters, but not even all punctuation characters. For chars you can decode, see "The Base64 index table:" in

http://en.wikipedia.org/wiki/Base64.

'|' is not one of them.

Repeat: You can encode any string with all 256 ascii chars in the encode direction, the result will only have chars in the base64 index table and only those 64 chars are decoded back to the original. Any other char is by definition not base64 encoded and causes rubbish in decoding, as it is skipped.

If that kind of encryption is enough for you simply take care about the en-/decoding order and don't use the regionalidentifier. That parameter is not at all meant for usage with base64 en/decoding, it's meant for conversion of Unicode or UTF-8 to codepages.

Bye, Olaf.

 

[grahamrhind]

Thanks Olaf. That's helpful.

Craig Boyd's FLL: encrypt() works great, decrypt() gives an "API call caused an exception" error - don't know if that's due to me being on a 64 bit machine.

The encoding doesn't have to be complex - it's to stop the casual browser and not anybody with a technical background. Thanks for the Base64 explanation - that might be a problem because it changes the length of the field contents within the field, which I presume could mean long strings being truncated.

Do you have any suggestions for another (simple) encryption which will alow a one-to one character encryption?

 

[DSummZZZ]

By the way, I'm on Windows 7 64 bit, which won't allow the rather old Cryptor dll to be hooked into the install file.

Ah, I see. I'm running W7 32 bit.

As for the API error, you may have to email Craig and see if he has a 64 bit version or a solution.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

Hi Graham,

Yes, the length will be a problem for Base64 encoded data. So an encoding resulting in the same length is preferable.

An easy wa to en/decrypt is using CHRTRAN(), eg

encoded = CHARTRAN(value,"abc","bca") will encrypt each a with an b, b with c and c with a and decoded = CHRTRAN(encoded,"bca","abc") will decode that back.

Of course the two conversion constants "abc" and "bca" should cover all characters and map to a randomly scrambled string of the same charaters.

Define a constant ccInitial with all characters you want to encode, define a constant ccFinal as a scrambled version. Each char must be present exactly once in both string constants ccInitil, ccFinal, then de-/encoding can be done with:

encoded = chrtran(value,ccInitial,ccFinal)
value = chrtran(encoded,ccFinal,ccInitial)

In a special case with ccFinal just being a rotated version of ccInitial this is like

http://de.wikipedia.org/wiki/ROT13

#DEFINE ccInitial "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
#DEFINE ccFinal   "NOPQRSTUVWXYZABCDEFGHIJKLM"
value = "HELLO"
encoded = chrtran(value,ccInitial,ccFinal)
? encoded
value = chrtran(encoded,ccFinal,ccInitial)
? value

Bye, Olaf.

 

[Olaf Doschke]

Sorry, the English version of ROT13 is of course:

http://en.wikipedia.org/wiki/ROT13

Bye, Olaf.

 

[grahamrhind]

Thanks Olaf! I was looking at CHRTRAN() but couldn't think of a way of using it which would result in an accurate translation back into an unencoded version - I think you've hit on the answer for my purposes!

 

[grahamrhind]

Some further information about using CHRTRAN() to encrypt.

I found out (too late ...) that double letters within words are not both transformed so that the "unencrypted" version is no longer correct. Thus, for example:

chrtran('Street','ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba','ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz')

produces "Hgiwg" instead of "Hgiwwg", and the reverse:

chrtran('Hgiwg','ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz', 'ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba')

Produces "Strdt".

So, back to the drawing board. I think now my best bet would be a series of strtran() of common letters to high ASCII values ...

Sigh ...

 

[Olaf Doschke]

Nope, neverever

chrtran does translate repeated letters with the repeated translation:

? chrtran("aaa","a","b") && results in "bbb", mot b only.

the inverse operation translates back to aaa:
? chrtran("bbb","b","a") && results in "aaa"

You are simply misreading the ouptut of Street as Hgiwg while it us Hgivvg!!!

Double v, not double u.

Bye, Olaf.

 

[grahamrhind]

Mea culpa, and silly me. Thanks Olaf. I'll have to dig deeper as to why I'm getting other weird results back ....

 

[Olaf Doschke]

The encryption/decryption is quite failsafe. The only thing you need to make sure is you use the inverse pair of conversion strings (param2+3) in decrption as was used in encryption.

Bye, Olaf.

 

[Olaf Doschke]

OK, here's one thing that can be problematic, if you don't remain in the range of chars you encrypt:

? chrtran(chrtran("abcd","abc","def"),"def","abc")

The error is, you're not encrypting "d" in the inner chrtran, a "d" in the initial string remains a "d", while the inverse operation does decrpyt "d" as an "a", so you end with abca instead of abcd.

So you need to make sure, that every char you have in param2 also is in param3. Eg "abc" and "def" are no valid pair of encryption parameters, as the value range does not match each other, so you can get bad inverse values.

If you don't have that problem then the only reason you dont get correct decrypted data is something changed in the encrypted data oin the way. You best store encrypted values in binary fields - char (binary) or memo (binary), not in codepaged fields, as that may do some conversions of nonreadable chars you may have put into the en/decryption parameters.

Bye, Olaf.