Hide literal strings in compiled exe

[MachineCode]

Quite often I find myself wanting to hide my strings in the final compiled executable, such as web addresses and such. I think it would be good if PureBasic would encrypt or hide them when creating the executable, so prying eyes with a hex editor can't take a peek around your app.

[c4s]

You could create encrypted strings yourself in a data section and decode/use them as needed. Remember that this is just a really basic hiding mechanism. Everyone with advanced knowledge knows how to retrieve any string out of your executable...

[STARGÅTE]

Hide ?
String which is to use the EXE must be in the EXE, where else?

encrypt ?
see post from c4s

[MachineCode]

I know I can encrypt strings in my app's code, but I'm talking about NO changes to my source code. I did actually write a pre-processor that does it, but natively would be nicer. Using my pre-processor, if I compile the following single command to an exe, the word "HIDDEN" can't be found in the exe with a hex editor. I'm not interested in stopping real crackers from finding the strings; I just want to stop people using a hex editor to take a look and to stop them modifying it with the hex editor (it's happened to me in the past).

Code: Select all

MessageRequester("","HIDDEN")

[c4s]

I just want to stop people using a hex editor to take a look and to stop them modifying it with the hex editor (it's happened to me in the past).

Happend to me as well. Actually it was a kind chinese guy who translated my freeware program into chinese by just replacing the english strings using an hex editor. At least he asked me afterwards if I allow him to release it...
Well, this was quite a "shock" to me so I created a little preprocessor that stores all strings in an encrypted file which I'm decrypting into my string array at program start-up. Anyway, I don't think PureBasic should do this.

[Didelphodon]

As a quick shot you can pack your executables with UPX. Though that's the most easiest hurdle to take for crackers (UPX is easily revertable by UPX itself) this step would prevent hex-viewers of finding your strings and you further won't have to change your sourcecode.

Cheers, Didel.

[MachineCode]

It's easy to stop UPX being reversed (just replace "UPX" in the exe with random bytes), but as you said, it doesn't stop real crackers. Maybe PureBasic could have some sort of "secure compilation" mode, where it encrypts such strings and has some other basic protections. Not to stop crackers, but to stop casual users from exploring the exe and ripping stuff out of it. I guess I know the answer already, though. Would anyone here be interested if I updated my pre-processor to do that sort of thing?

[Shield]

Sounds interesting to hide a string from the average user's eyes.
But keep in mind that such methods shouldn't be used for sensitive data such as passwords.
As soon as your application starts working with those strings after decrypting them, the data can be read
form memory without any problems.

[MachineCode]

such methods shouldn't be used for sensitive data such as passwords

No, of course not. In my case, I'm more concerned about someone changing the URL of my website in my exe, to a different URL of their choice, and getting payment from my app instead of me. It's happened to me before!

[Tenaja]

such methods shouldn't be used for sensitive data such as passwords

No, of course not. In my case, I'm more concerned about someone changing the URL of my website in my exe, to a different URL of their choice, and getting payment from my app instead of me. It's happened to me before!

The "simplest" way is just "encrypt" it yourself with xors and/or adds & shifts. That will prevent a simple hex editor, but not a debugger. Someone else also suggested zipping the text string file into the exe so you have to unzip them to use it, but I didn't bookmark it.

[Tenaja]

This works for short & minimal text:
; set up a chart with all characters. I had to add 'my' because pb has some single-character constants predefined.

#myH = 'h' ! '1'
#myE = 'e' ! '1'
#myY = 'y' ! '1'


#Test = Chr(#myH ) + Chr(#myE ) + Chr(#myY) ;test string

Procedure.s ReXor(s.s)
x.i = 1
y.i = Len(s)
new.s = ""
Repeat
new = new + Chr(Asc(Mid(s, x, 1)) ! '1')
y-1
x+1
Until y = 0
ProcedureReturn new
EndProcedure

Debug ReXor(#Test)

I know there's a better way, but I just tossed this together as a starting point. Better would be to use a rolling key.

[kenmo]

I know this is an ugly workaround, BUT...

You could use something like this (NOT within your app)

Code: Select all

Procedure.s HideString(Input.s)
  Protected *C.Character
  Protected Output.s
  Protected n.i
  Protected Columns.i = 2
  
  *C = @Input
  While (*C\c)
    If (n % Columns = 0)
      Output + #LF$ + "    Data.a"
    EndIf
    Output + " $" + RSet(Hex(*C\c ! $FF), 2, "0")
    If (n % Columns < Columns - 1)
      Output + ","
    EndIf
    n + 1
    *C + 1
  Wend
  If (n % Columns = 0)
    Output + ", $FF"
  Else
    Output + " $FF"
  EndIf
  
  Output = ";DataSection" + #LF$ + "  StringLabel:" + Output + #LF$ + ";EndDataSection"
  
  ProcedureReturn Output
EndProcedure

SetClipboardText(HideString("Hello World!"))

to generate some "hidden" text like this

Code: Select all

DataSection
  StringLabel:
    Data.a $B7, $9A ; note this is garbage when viewed in a hex editor
    Data.a $93, $93
    Data.a $90, $DF
    Data.a $A8, $90
    Data.a $8D, $93
    Data.a $9B, $DE, $FF
EndDataSection

which can be included in your app, along with the Unhide function

Code: Select all

Procedure.s UnhideString(*Address.Character)
  Protected Output.s
  
  While (*Address\c <> $FF)
    Output + Chr(*Address\c ! $FF)
    *Address + 1
  Wend
  
  ProcedureReturn Output
EndProcedure

Debug UnhideString(?StringLabel)

It's a tedious way to do it, but the nice thing is it takes up no more space than the original string (except for the small Unhide function). Also, the terminating nulls are also "hidden" which might prevent obvious string boundaries when viewed.

It could easily be adapted for Unicode, for a variable "key" (rather than $FF), or some real encryption rather than XOR.

[skywalk]

Interesting topic.

But, since encrypting sensitive strings in a DataSection is already available, what would the PB native approach do?

How would PB know what you want to encrypt?

Side note: I actually edit strings in the exe for small apps to save user state changes.

[kenmo]

But, since encrypting sensitive strings in a DataSection is already available, what would the PB native approach do?

How would PB know what you want to encrypt?

It can be done many ways, but I think MachineCode is asking for a clean, native way. Maybe something like:

Code: Select all

EncryptSection
  Data.s "Secret String One"
  Data.s "Secret String Two"
EndEncryptSection

Then the question is, (a) what encryption does it use and (b) what syntax do you use to retrieve it?

Hmmm..... makes me want to write a pre-processor tool.......

[MachineCode]

I think MachineCode is asking for a clean, native way

Yes, just like I said in my second post. No datasections, no extra work. Just type a string as normal, as in my example, but when compiled, it's hidden. My pre-processor does it, but an option to encrypt natively like that would be great.