ocx ole sub names in readable format (exe files)

[Roger Cabo]

Hi, thanks X for this great thread on gfa_vars.

The executable code of a compiled GB32 program contains all Sub_ names in a format that's readable to humans. I find this rather concerning due to security implications. For instance, if you name your Subs as sub_login, sub_enter_password, sub_connect2server, and so on, everything becomes transparently readable. A while ago, I tried obfuscating the GFA code and managed to detect all human-readable strings embedded in the code successfully.

The task here is to distinguish strings from code and comments. Interestingly, GFA32 also recognizes the French (axondegue or grave?) as a quotation mark. Not to mention, the single ' and """ as well as a combination of "'"''"'"'" also function as quotation marks, though I haven't fully tested them yet.

While utilizing your own executable isn't an issue for personal use, it becomes potentially risky when sharing this executable with an official company, especially when it's distributed for free to assist people. It could be extremely harmful if data were to leak.

My question is, why should OCX subs be presented in a human-readable format in the executable?

[(X)]

It seems you want to obfuscate the readable text in your executable files for security. This is an excellent idea!

It seems you have found a way to change variable names & comments and now you are having difficulty with text related to OCX's.

For example, if you have an OCX Button called: 'btn_Login' with a caption of: "LOGIN", you don't want an 'exe snooper' to easily read the OCX's event called 'btn_Login_Click()'?

3 things come to mind:

1) Create your OCX's 'in code' instead of the form editor, then, you can rename the OCX names before compiling...
2) Use the Window Messages to handle the events instead of creating event subs.
3) You can use literal hex code format instead of Constants (if they appear in text form in the exe).

I hope our group can come up with a solid solution!

I took a quick look around for Encrypting 'executables' and found something called VeraCrypt though they say it is not 100% secure it may give us some good ideas.

[(X)]

What does full optimization do?

I wonder if it has anything to do with replacing variable, sub, proc & func names with handles.

[dragonjim]

Full Optimization for Exe, Gll & Lg32 - The time consuming process of optimizing the branch statements can be enabled for the creation of stand-alone EXEs only. Compiling in memory in the IDE will not result in branch optimization. Suggestion: Disable

This does not do what you hope.

The best way to disguise OCXs is to call them txt for textbox, cbx for combobox, etc. If you want to add identifiers, try something like this:

Global Enum Btn_Login, Btn_Cancel
OpenW 1
Ocx Command cmd(Btn_Login) = "Login", 10, 80, 100, 25
Ocx Command cmd(Btn_Cancel) = "Cancel", 120, 80, 100, 25
Do : Sleep : Until Win_1 Is Nothing

Sub cmd_Click(Index%)
 Select Index%
 Case Btn_Login
   Message "Logging in..."
   CloseW 1
 Case Btn_Cancel
   CloseW 1
 EndSelect
EndSub

[Roger Cabo]

Working with code and creating forms is very time consumptive.

I thought about another solution to convert a Editor Form into pure code.

When running through every object inside a form, you can generate new code by the GFA_ commands.
Each Ocx.name must be absolutely unique! That is a great property in Gb32.

Not sure if this works with GFA_ commands:

+ SourceCompile$ = Save complete original code into any var
+ SourceEdit$ = SourceCompile$
+ Subs$(x) = Save all Sub names into an array
+ Read through all forms and save each control into code, excepting only changes are different than the defaults
+ Additionally set all converted forms into code, = Nothing
+ Add the new code into a Proc GFAFormConvert() into SourceCompile$
+ Set the new SourceCompile$ to each GFA_Line XXX
+ Compile to exe.
+ Reload SourceEdit$ into the editor.

I think that's possible ? But for sure is not a simple task..

[dragonjim]

Possibly a much easier solution would be to:

1. Compile the program normally
2. Compact and/or encrypt the program
3. Add the compacted/encrypted file "inline" into another shell program which will extract and run the program when called and then delete the file once the program has been terminated.
4. Compile the shell program.

You could take this further by creating a program which loads in the compiled executable, adds the shell program code and then produces the final compiled file.

[Roger Cabo]

Jul 20, 2023 22:26:21 GMT 1 dragonjim said:

Possibly a much easier solution would be to:

1. Compile the program normally
2. Compact and/or encrypt the program
3. Add the compacted/encrypted file "inline" into another shell program which will extract and run the program when called and then delete the file once the program has been terminated.
4. Compile the shell program.

You could take this further by creating a program which loads in the compiled executable, adds the shell program code and then produces the final compiled file.

Would it also possible to load the decrypted into memory and execute out of the memory?

Without save to the HDD?

[dragonjim]

Possibly, but I do not know of a way.

However, if you try this, you may have problems with you antivirus.

If you are worried about people snooping on the file while the program is running, have it saved to an unrelated folder with a random filename.

[dragonjim]

One last thing. It is possible to scan memory as well as file contents so there is only so much you can do to