VFP Encryption question 4

[TinyNinja]

Hey VFP Community,

I found on VFP Project info this checkbox option. Does this encrypted option do anything? I am using VFP 9.2.

I also have another question. I have seen VFPA 32 bit & 64 bit (

http://www.baiyujia.com/vfpcompiler/en/default.asp)

options have an encryption option made into the compile program. Has anyone used that and if so does it do a good job at protecting your code?
I'm interested in buying the advanced version for some future projects and want to know if this encryption will prevent the de-compilers from working and is a good purchase.

 

[GriffMG]

Sounds like a question for someone more intimate with the exe structure than me!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Just been doing a bit more hacking. I noticed the following (after building the EXE with Debug Info ticked and Encrypted clear):

1. I can see the actual code from forms and classes, but not from the PRGs.

2. If I modify the actual code (in the hex editor), the modification does NOT have any effect at run time.

This sort of makes sense. The Build process takes the code from the FXP, not the PRG. But SCXs and VCXs store both the source code and the compiled code. Modifying the source code without recompiling the form or class (which is what I did) doesn't affect the compiled code.

So it is unlikely that anyone will be able to modify the behaviour of an app just by hacking the EXE - unless they can interpret the p-code, of course, and even then it would be difficult.

There is an exception to the above. The p-code contains the code of the application in tokenised form. But it also includes, in clear view, any literal strings in the program, such as user messages. If you can locate these within the EXE, you will be able to modify those string (provided you don't change their length), which would allow a malicious hacker to give misleading information to a user. The solution is to tick the Encrypted box, in which case neither the tokenised code or the literal strings will be visible.

None of this answers the original question, but I thought it was worth sharing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve Meyerson]

Mike, I think your explanation DOES answer one of the original questions ("Does this encrypted option do anything?")

What it tells me is IF the hacker could extract enough meaningful code and IF the hacker has VFP on hand and IF he/she has a buyer with the same requirement, it's theoretically possible to do some damage. I think it's highly improbable, and as you have said, it would not be worth the effort.

Steve

 

[Mike Lewis]

Good points, Steve.

So, TinyNinja, if you are still worried about this issue, then, yes, tick the Encrypted box.

Personally, I don't tick Encrypted, but I do tick Debug Info, for the single reason that it allows my error routine to report a bit more information regarding run-time errors. For the reasons that Steve mentioned, for me that outweighs any security issue.

(But be aware that including the debug info increases the size of the EXE file.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

be aware that including the debug info increases the size of the EXE file

And just to quantify that - and because I find myself in an idle moment - here is the size of an EXE file of a small-to-medium application (approx. 20 forms and 12 reports):

Without Debug Info: 669 KB

With Debug Info: 952 KB

So, a noticeable difference. (Ticking Encrypted made only a small difference. You should definitely NOT tick both Encrypted and Debug Info, as this increases the size of the file as above, but without the debugging benefit.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[vernpace]

Koen,

"... I would than start with encrytpting that something entry, you dont need to encrypt your complete code."

Is there a way to encrypt a section of code (eg a particular prg function) and then compilie normally?

 

[Koen Piller]

Hi.

Take a look at

https://www.levelextreme.com/Home/ShowHeader?Activator=17&ID=9527

or

https://www.berezniker.com/content/pages/visual-foxpro/vfp-implementation-cipher-encryption

or

https://www.sweetpotatosoftware.com/blog/index.php/category/visual-foxpro/

or

https://doughennig.com/papers/Pub/201103dhen.pdf

(Doug gives you the possibility to encrypt a string or a file)
Stay healty,
Koen

 

[TinyNinja]

Thank you everyone! This has been very helpful and I appreciate everyone's insight.

Koen or anyone else, I have looked at those encrypt solutions. My question is since these options were made years ago, are they still a good viable option for current or future encryption needs?

 

[Steve Meyerson]

FYI (and help I hope). These are a couple of simplified versions I've used for encode/decode. They use of VFP's random generator and use only built-in VFP commands & functions. I've expanded some lines for clarity.
Steve

PROCEDURE Encode
LPARAMETERS inString
nSeed = INT(100*(SECONDS()-INT(SECONDS()))) && Random seed
outString = TRANS(m.nSeed,'99') && Leave plain
=RAND(m.nSeed) && Initialize
FOR ii = 1 TO LEN(m.inString)
cChar = SUBSTR(m.inString,m.ii,1)
nShift = INT(256*RAND()) + 1
newAscii = ASC(m.cChar) + m.nShift
IF m.newAscii > 256
newAscii = m.newAscii - 256 && Wrap
ENDIF
outString = m.outString + CHR(m.newAscii)
ENDFOR
RETURN m.outString
ENDPROC

PROCEDURE Decode && Reverse encoded string
LPARAMETERS inString
nSeed = VAL(LEFT(m.inString,2)) && Plain text
outString = ''
=RAND(m.nSeed)
FOR ii = 3 TO LEN(m.inString)
cChar = SUBSTR(m.inString,m.ii,1)
nShift = INT(256*RAND()) + 1
newAscii = ASC(m.cChar) - m.nShift
IF m.newAscii < 0
newAscii = 256 + ASC(m.cChar) - m.nShift
ENDIF
outString = m.outString + CHR(m.newAscii)
ENDFOR
RETURN m.outString
ENDPROC

 

[Steve Meyerson]

Sorry the indentations didn't take.

 

[GriffMG]

For readability, pop them in code /code blocks

PROCEDURE ENCODE
	LPARAMETERS INSTRING
	NSEED = INT(100*(SECONDS()-INT(SECONDS()))) && Random seed
	OUTSTRING = TRANS(m.NSEED,'99') && Leave plain
	=RAND(m.NSEED) && Initialize
	FOR II = 1 TO LEN(m.INSTRING)
		CCHAR = SUBSTR(m.INSTRING,m.II,1)
		NSHIFT = INT(256*RAND()) + 1
		NEWASCII = ASC(m.CCHAR) + m.NSHIFT
		IF m.NEWASCII > 256
			NEWASCII = m.NEWASCII - 256 && Wrap
		ENDIF
		OUTSTRING = m.OUTSTRING + CHR(m.NEWASCII)
	ENDFOR
	RETURN m.OUTSTRING
ENDPROC

PROCEDURE DECODE && Reverse encoded string
	LPARAMETERS INSTRING
	NSEED = VAL(LEFT(m.INSTRING,2)) && Plain text
	OUTSTRING = ''
	=RAND(m.NSEED)
	FOR II = 3 TO LEN(m.INSTRING)
		CCHAR = SUBSTR(m.INSTRING,m.II,1)
		NSHIFT = INT(256*RAND()) + 1
		NEWASCII = ASC(m.CCHAR) - m.NSHIFT
		IF m.NEWASCII < 0
			NEWASCII = 256 + ASC(m.CCHAR) - m.NSHIFT
		ENDIF
		OUTSTRING = m.OUTSTRING + CHR(m.NEWASCII)
	ENDFOR
	RETURN m.OUTSTRING
ENDPROC

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Koen Piller]

Tinya,
Yes these solutions are still workable
Stay healthy,
Koen

 

[Steve Meyerson]

Thanks, Griff. Much better! It was indented on my copy but for some reason the copy/paste eliminated the leading spaces. I'll be more careful next time.

BTW the code is meant as a starter. There can be tons of variations (e.g. I use a 3-digit seed instead of 2-digit).
Steve

 

[GriffMG]

You could 'hide' the seed...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Steve, just checking that I have understood your code. The Encode routine is using the time of day to get a seed that will always be a two-digit number, and it is storing that number as the first two characters of the encoded string. The decode routine is then picking up that same number, and using it as the seed for decoding. If I've understood that right, it would mean that anyone who knows your method would be able to decode any string.

Presumably that's what Griff was referring to when he suggested "hiding" the seed - although I must admit I can't off hand think of a good way of doing that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Sorry Mike, I was only really saying that using the first characters as the seed is a bit obvious - if, as you say, any one knows your method
then there is no 'hiding' the seed - at best obfuscating it a bit.

I think the only way to do this is to not publish your method on a public forum....

B-)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[TinyNinja]

Hey Koen,
That's good to hear. I will take a deeper look at those options.

Steve, Thanks for the starter option on encoding & decoding. Since it is an easy thing best to make it much harder if I do something like this in the future.

 

[Steve Meyerson]

True. But as I said, there' a ton of variations to this. You can use a 3 or 4-byte seed (e.g. 1-999). The seed could be hidden at the end or inside the text. Actually I encrypt the seed using another seed known only by me. Dummy text is added. Of course if someone can extract your obfuscated code, it can be cracked. I just hope the user has no NSA contacts (lol).

As I'm sure you know (others may not) the whole thing depends on the fact that the sequence of the random numbers generated is always identical if the same seed is used. Therefore the encryption seed is extracted in the decryption.

Steve

 

[Chris Miller]

Hi, and hello to everyone,

I registered here because I wanted to add to this discussion, as it's about very fundamental topic I was already confronted with several times. There once was KONxISE that compressed and encrypted executables, but nothing you do, not even Refox protection, protects the p-code all the way.

Because you can always run something, go into task manager, details tab, right click a process and use "create dump file". No matter if you use this native encryption function or Refox or KONxISE, the only way any executable can run is to be decrypted p-code when it's in memory. And so this decryption is done when your executable runs. And the dump option may not be as known as the task manager is known o kill a process, but it's there, i's a native option, not even a hacker tool from the dark web.

So what's the protection really worth? I'd mainly agree with Mike Lewis, the best part of your software is you and your knowledge about it, your ability to maintain and extend it, to know it as good as no other and understand it. For source protection it's already the best option to not add debug info in that sense, as then you really need a decompiler and can't just see source code within the EXE or dump file.

Mike says there is a quality of error handling that's missing, if you don't include debug info. That's somewhat true, it can become a nightmare to orient yourself with a line number only, but if you write error handling including your software version and maintain source code versions with a source versioning system, you can find the code in your project, too. The debug info does not add much more than that and you put all your source code in there, including comments, that can blows up the executable size extremely and adds a bit of documentation, too.

What you also don't achieve at all is protection against software theft, usage by more users than are licensed, etc. There are other mechanisms for that aspect anyway.

We share this overall problem with the whole industr. The only good ties in that aspect where in C/C++ tims, when compilation really meant that, ie transforming C code to assembly code and compiling that to machine code, really. So you needed decompilers that were reconstructing C by knowing what assembly macros certain C compilers used. In the end there never was full protection, since you can always extract the final executable code anyway, today getting back somehing you may even try to exend and maintain on your own is an achievale goal, but if someone is actually interested in selling stolen software, taking own control of it is rarely the goal anyway, so the major issue isn't even stealing your sources. As Mike also said, if you're as genius as cracking that and extracting the sources, then you could also write something yourself. So the question is: How much value actually is in the feature of our software you're most proud of? Is it really something revolutionary that you're fraid someone would steal?

If your major interest would be proteting data/privacy, as lso already said that's more a job for data encryption and then also never including such things in source code anyway, so that's a very separate topic.

Chriss

 

[Mike Lewis]

Hello Chris, and thank you for your very useful comments. And welcome to the forum. Now that you have found us, I hope you will stick around.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads