Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Jack Ryan
  Where is Jack Ryan?
 New Zealand
 Jack Ryan
Subject: Protecting VFP apps
Thread ID: 268683 Message ID: 268683 # Views: 83 # Ratings: 0
Version: Visual FoxPro 9 Category: Security and Application Protection
Date: Wednesday, July 14, 2010 12:31:26 AM         

Further to recent threads about VFP protection:

Vendors are continuing to improve their offerings. I understand that a new version of Refox has some internal obfuscation and dbc exploit-blocking, which is good.

Leonid has posted some optional internal code for Defox that makes it much harder to peel code.

VFP compiler, which splits an app into an exe and a dll so there is no longer any project to peel, has just released a new version with 2 new features:

1) A compiler flag that adds anti-disassembly code in the dll.
2) A new compiler directive to allow insertion of C++ or assembly at a defined point in the dll.

The first feature creates a barrier for all but the most capable hackers out there. The second feature lets a developer insert antihacker code wherever it matters. For example, =[INCLUDE ANTIHACK.C] in your VFP code will automatically insert a C++ code block at that point- in this case hack-checking code for 42 exploits including the arcane Tier 1 techniques used by elite hackers. I've found some assembly that may be even better. The directive can be added in VFP code immediately prior to accessing passwords for encryption/decryption or before a SQLConnect() or before access to a secure site or any other VFP code using sensitive information. I'm thinking that if debug or eavesdropping is in use, the app will be quietly diverted into demo mode and the sensitive part simply won't run. Now the hacker has to disassemble the low-level routines in the dll to figure out why they can't get the password or sensitive code, which is a huge task even for the most adept hacker especially if the antidisassembly feature was used. Because C++ source is just text it's also possible to create the inserted codeblock dynamically so there's no byte signature that makes it easier to disable.

FWIW these sorts of protection features also are used by Molebox and similar, but they do not insert multiple checks at the precise point where it matters. Nor do they allow the app to quietly divert so it seems to be running correctly but simply never connects to the database or decrypts a file or whatever while somebody is trying to hack. They're also highly vulnerable to VFP dbc/strtofile etc exploits that are not detected by these sorts of techniques.


Protecting VFP apps Posted by Jack Ryan @ 7/14/2010 12:31:26 AM