VB6 Hiding Strings

Dear Experts,

What's the best way to hide strings used in an application (for various messages given to the user) to prevent them from being viewed within the exe file?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Luis PérezSoftware Architect in .NetCommented:
Well, a simple way is to have a pair of Encrypt/Decrypt global functions in a .bas file, so you can declare your string message variables with the encrypted text, not the real text. When you compile your project into an .exe file, the real message won't be visible.

Here's a simple encryption function for VB6:

Hope that helps.
ttobin333Author Commented:
Can strings stored in and loaded from a resource file be easily viewed?

More importantly, if a certain string from the resource file is loaded using the LoadResString command, could that particular string be used to identify a key portion of the code for hackers?
Ultimately, anything that can read can be hacked.  What you need to consider is how encrypted you want the data.  You could have a simple encryption when you write the data and reverse it when you read it.  But if you want anything more than something that goes through each character and changes it then you might as well go with the full encryption mentioned above.

As for resource files, I don't recall if they are encrypted, but even if they are, the algorithm is likely very accessible for anyone who wants to break it.

I guess it comes down to "how secure do you want your car?" You can leave the keys in the ignition and hope nobody takes it (unencoded text but people have to look for it). You can leave it unlocked but not leave the keys in and it will be hard to steal.  Lock the doors and it's harder.  Add a basic alarm and it might be harder.  Add an ignition cut-off and it's harder.  Add a code-enabled alarming system and it's harder, etc.
So how hard do you want it to be for people to break your code?
Get Blueprints for Increased Customer Retention

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

ttobin333Author Commented:
I appreciate the comments and general advice.

However, can someone specifically comment on the resource file text string question, as this may be the easiest compromise balancing practicality and security.

When a text string is loaded from a resource file (using LoadResString), is that string viewable at that location in the code, allowing a hacker to determine the location?

Not sure about VB6 (since I've been on .NET for 12+ years) but in .NET the contents of the resource file are encrypted in the .exe (but visible in the .resx file, which should not be delivered to customers)
Everything storing in resource section of PE can be easy read even from VB (see my sample at http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=25890&lngWId=1)
You can hide valuable strings in your app with smth like
Dim x As String
x = Chr(72) & Chr(101) & Chr(108) & Chr(108) & Chr(111) & Chr(32) & Chr(87) & Chr(111) & Chr(114) & Chr(108) & Chr(100)
MsgBox x

Open in new window

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ttobin333Author Commented:
Thanks Ark. That method sounds good.

Regarding viewing strings in a resource file: yes, I am able to see the strings and the reference numbers. But the most important question is, whether the reference numbers can somehow be used to find the location in the code where a particular string from the resource file is called. I am not worried about the strings being viewed inside the resource file, but I don't want anyone to be able to reference the "LoadResString(xxx)" statement calling a particular string. Some of the strings would give away critical locations in the code where hackers could potentially defeat piracy protection.
Actually it's not necessary LoadResString just before calling MsgBox(strYou_are_a_pirate) - you can load it anitime before. But I'm afraid if hacker can disasm your executable, then find FindResource/LoadResource API entries, read correctly eax pushes (params) and final pop (string address) - (s)hi is experienced enough to break your defence.

Chr(x) trick is quite well known to hide string in executables (ie protect against disassembly), but it cannot protect against debugging - memory dump immediately shows all your secrets. Actually, when debugging, hacker even don't need these strings - settings breaks on MessageBoxW would be enough.
ttobin333Author Commented:
So again, it is clear that nothing is bullet-proof…but it sounds like the Chr(x) method is the best balance of effort/protection perhaps?

How about encrypted strings in a resource file? Would that offer any advantage? Maybe the method mentioned earlier by Luis Pérez in this discussion could be used to encrypt/decrypt the resource file strings?
Actually, the best option is to remove the text from the project entirely and put it in a web-based database, encrypted, with a decryption mechanism in your code.
If the text is in your code, there is always a way that a hacker can do what the code does and extract it.
At least with the web (or other server-based) option, you can limit the way the data is returned so people don't have access to it without proper permissions.
If you already have piracy protection in your software, the way to bypass it is to replace your checking routine with nop/jmp commands. In this case the bottle-neck for crackers is to find this checking routine. There are a number of methods to make this harder - you can display message not just after checking but with some delay, or degrade app without warning, or show a form with warning labeland tons of controls with Visible=False and numerous dummy math functions inside form which do nothing. Compile your app into P-Code - digging through  runtime dlls spagetty when debugging is a nightmare.
See more advices at http://www.woodmann.com/crackz/Tutorials/Protect.htm (though code is in asm, there are lot of practical advices and usefull links)
ttobin333Author Commented:
rspahitz, unless you care to share the details, that's way too complicated, and requires software to always be connected to the web.
t, you are correct that this will require a web connection (thought not necessarily always-on.)
However, if you deliver all the pieces in an .exe, then someone can always find a way to locate the parts they want.  Is it worth their while?  Probably not unless your product is going to make them hundreds of thousands of dollars.
This problem really comes down to risk-analysis.  If it's that valuable, you'll need to store the data outside of the customer's realm.  If it's less valuable, then a simple encryption routine may suffice.
Personally, I would probably store the info in an encrypted database (e.g. Access) with password permissions, then have the app pull the info as needed.  The DB can still be hacked, but if you do it right, it will be hard to figure out what the pieces mean.
AFAIK there are 2 ways to bypass protection:
1. Understand key-generation (or key checking) routine and create own with same logic (AKA keygen building). Require some valuable info (key-building algorithm, key - string, password etc. - can be protected if storing on server)
2. Find checking routine address and bypass it with asm code editing (AKA patching). In this case you can hide password on the Moon on switched-off computer - this doesn't help against patching. Instead you must hide your checking routine as deep as possible inside your code and check if known debuggers (like SoftIce/Olly/WinDbg) running - this makes patching not impossible but harder.
ttobin333Author Commented:
Thanks guys, for the valuable information!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.