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.

 

[Chris Miller]

Thank you Mike,

I think I don't always have to say something, but I'll look around.

There were some sessions on this topic and I think also FoxTalk had this issue. I don't know exactly what kind of encryption is even used, but it's quite pointless, when it's decrypted automatically anyway. I remember one more detail I think Rick Strahl once suggested on the topic of obfuscation of code. It can work like this with precompiler options:

#Define liCount dhfkjdshfkdsjhfkjshfdkhdshofshdkfhkdshuewhruhfvsosdfohjkhrewhr
#Define loForm dhfkjdshfkdsjhfkjshfdkhdshtfshdkfhkdshuewhruhfvsosdfohjkhrewhr

For liCount = 1 to _screen.Forms.Count
loForm = _screen.Forms[liCount]
* do something with the form
Next liCount

But I'm not even sure it works as intended. The idea is to change names of variables just at compilation time and make it quite hard to identify variables, because look very close: While it seems both liCount and loForm are replaced by the same name, these #defines differ in one place.

It's still quite cumbersome to add such defines for every variable, even if you do so in one generally included header file. But at least you don't change your existing code at all, you just need to watch out that you don't cause an exactly same replacement for different variables and sabotage your own code that way. That iss just one of several obfuscation ideas. But I don't remember where I saw this. I never implemented it because of the possible problems it might introduce, ie debugging.

Can we format code in some way here, as Griff did?

Chriss

 

[GriffMG]

Chris

You put a tag before and after the code block using square brackets around code and /code a bit like html, <code></code> but using [] instead

You can also do bold, italics, and other effects - look up TGML there is an icon for a code link on the bar above the typing area next to the gift box

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. ​

 

[vernpace]

Interesting discussion. I have often pondered a solution for this and came up with a crazy idea a few years ago that is "theoretically" possible:

1) Create a hidden system folder in AppData\Local\Temp
2) Compile an application as an APP and then encrypt it using AES-256(CBC mode) with a 256 bit password.
3) Create a stub EXE that calls a web service to get the password, then decrypts the APP to the hidden folder, then calls the APP

I think this would be hard to crack. Have not tried it yet, but on my list of thing to do.

 

[Steve Meyerson]

Hi,

On this subject, There are many different security approaches depending on your requirement(s). Here are a few I've experienced. I'm sure there are more.

1. Password encryption. Administrators normally don't have access to user passwords but can allow a user to reset his/her password.

2. Theft of the app. I use checksum(s) of a portion of data pecular to the user and not likely to change (e.g. a statement logo, address etc.).

3. Use of app after expiration date (e.g. monthly payment coding). To detect if a user set system date backward to bypass expiration, I record datetime on startup and compare to next startup. Of course if user never turns off computer, the detection may have to coccur more often.

4. Theft of code: Obfuscation of the code can help if the thief is not too sophisticated. Hopefully, he/she is not willing to spend the time and money or may not even have a copy of VFP (hard to get these days). It should be easier for the "sophisticated" thief to write the entire app in some (other?) language.

Steve

 

[Mike Lewis]

On the subject of obfuscation of variable names - that is, choosing names that are compleltely meaningless and likely to confuse anyone studying the code - this seeems to be a well-established practice among some programmers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve Meyerson]

Hi Mike,

I'm sure it was well established. I wasn't trying to imply I invented it. Actually, I've yet to try it.

If someone asked me to hack a program for their benefit, I would say "I could write it, but not steal it." And I believe everyone here would say the same.

Steve

 

[GriffMG]

Phew, I thought Mike was talking about my normal scrappy coding!

Where's Olaf when we need him?

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]

Griff,

I was. And where indeed?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

He he.

I think he may have stopped posting...

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. ​

 

[Chris Miller]

>put a tag before and after the code block

I think I got it, thanks Griff.

And trying that obfuscation the debugger still shows the code as is, but that doesn't really surprise me, if you do more usual defines of constants as some numbers the debugger also doesn't show these numbers placed inti the code. So this kind of obfuscation would only have an effect if you don't include the debug info = source code, I guess.

Chriss

 

[TinyNinja]

This has been great! I never expected to get such great feedback from the community on this topic. Everyone’s input has really helped me figure out a good option for my future project.

If others have more knowledge, I would love to hear about it.

I am in agreeance with Griff and wonder where Olaf is. I know he has deep knowledge of VFP and would be great to see him add to the discussion.

 

[Chris Miller]

Hi Vernspace,

You said:

3) Create a stub EXE that calls a web service to get the password, then decrypts the APP to the hidden folder, then calls the APP

Interesting idea. I gave this idea a shot (not with all bells and whistles) to test one aspect: How much does a dump file revel from the finally decrypted app, when the stub EXE decrypted and started it?

So I made this simple stub EXE:

LPARAM tcApp
DO (tcApp)

And an APP with a simple main prg

Messagebox("I'm the app")

I built both the stub EXE and the APP without debug info and encrypted and especially the app file does not show the text of the messagebox in its file.

Result: The dump of the stub EXE process includes the text "I'm the app." In multiple places. So that separation doesn't help, in principle the discoverable text shows you could also extract the p-code. There is still a hurdle: The dump file has a very blown up size in comparison to the EXE and APP files. You surely can't point ReFox to the DMP file and let it decompile. And I think this also is true if you don't even separate an APP from a loader EXE.

But in the end your idea would allow to use any encryption algorithm. And the step to use a web service could verify a license, update the app and see how frequent the app is used. So no reason to dump the idea.

Chriss

 

[vernpace]

Hi Chris,

Thanks for the proof of concept! I didn't expect that.

> And the step to use a web service could verify a license, update the app and see how frequent the app is used.

This is exactly what we are doing for a project. We have licensing tiers that need to be verified at logon. We also need "feature utilization" information for marketing and future upgrade plans.

I'm not too concerned about dump files. Basically, they are a snapshot (memory dump) of the current state of the process - like stopping at a breakpoint in the debugger. I don't think the source code of an entire application is revealed. A decompiler like ReFox is another story.

Jeff

 

[vernpace]

Another idea on obfuscation: Create a maze of BINDEVENT calls.

Jeff

 

[GriffMG]

I never thought of that
If you published that on a public website would that undermine it at all?

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. ​

 

[vernpace]

Griff,

I don't think so. In fact, a proper implementation of BINDEVENT obfuscation could actually lead to obfuscation for those who developed it - this is true for any type of obfuscation. Detailed external documentation would have to be created and maintained to make sense of it.

Jeff

 

[Chris Miller]

Hi vernspace,

I'm not too concerned about dump files. .... I don't think the source code of an entire application is revealed.

I'd not be so sure, because even a 10 MB exe is small in comparison to todays RAM. I don't think Windows does a lot of paging anymore, if it can load a full EXE and DLLs into the memory of a process, why shouldn't it? That could also explain why the dump file is so large.

I'd not be worried anyway, as even when an APP or EXE is fully loaded in the memory, the dump file needs a lot more processing than changing the extension to APP or EXE.

Chriss