App > Encrypt "App" ? How to encrypt built .exe source?

[Thom_McGrath]

Oh in that case, the solution is pretty simple. Base64, as @Douglas_Handy mentioned, is simple enough. However somebody looking through your exe would likely recognize that.

Another option is The ZAZ: Xojo String Obfuscator. Put your cipher key into that, and it’ll give you a Xojo function to add to your app. For the sake of clarity, yes key would be submitted to my server, but no it doesn’t get stored anywhere. I don’t log the inputs, I don’t use nginx logging, I don’t use Google Analytics. I’ll never know what you put in there. You don’t have to use it, but it’s safe if you want to.

[Ben_D]

Tough, I would not use Base64 directly, but probably a derivative of that with some arbitrary random salt to make it directly non-decodable in case somebody peeking at the binary in NotePad recognizes the Base64 encoding and decides to copy/paste it in an online Base64 decoder

@Douglas_Handy

Better yet also/alternatively encrypt it using a string that will appear in your app anyway (e.g. the application name) so they will not realize that is also part of a key. And use multiple pieces of string data to create the cipher key, making it even less obvious.

This I like a lot! Very clever and that string has to appear in the binary code somewhere anyway, so it’s less obvious, indeed.

[Ben_D]

@Thom_McGrath

Another option is The ZAZ: Xojo String Obfuscator .

Thanks for suggesting something. Tough, I hope it’s not open source like your ARK tool is, because otherwise, it would be really easy for anyone to reverse it. Also, I tried with a 200K string and your PHP script crashed with a fatal memory exhaustion error. Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 33554440 bytes) in /home/thommcgrath/thezaz.com/live/public/php/classes/XojoSyntaxColorizer.php on line 348

128MB of RAM exhausted just for encoding a 200K string? Not the lightest solution around that’s for sure

But I like the idea that you’re shuffling characters around to make the Base64 non-decodable. That’s almost what I’m doing, except my solution is to arbitrarily inject additional, garbage characters in the Base64 string before storing it and simply ignoring (stripping) those characters before decoding it.

[Thom_McGrath]

Well 200K is a bit more than I expected anybody to throw at it. The error you’re seeing comes from the coloring class: GitHub - thommcgrath/XojoSyntaxColorizer: PHP library for converting Xojo code into colored HTML. Probably lots of lookups thanks to all the characters. The resulting method would probably crush even the Xojo IDE too, given the length of the line.

Regardless, even if it was open source - I’ll post it here to prove a point - it doesn’t really matter. The point is it’s supposed to be reversed. It just hides the string from showing up in notepad. The compiler still has to be able to put it together. Security through obscuring isn’t security at all.

Here’s the PHP code:

if (array_key_exists('input',$_POST)) {
	$input = stripslashes($_POST['input']);
	$encoded = base64_encode($input);
	$encoded_chars = str_split($encoded);
	$chars = array();
	foreach ($encoded_chars as $char) {
		if (in_array($char,$chars) == false) {
			$chars[] = $char;
		}
	}
	shuffle($chars);
	
	$decoder_parts = array();
	foreach ($encoded_chars as $char) {
		$decoder_parts[] = 'Chars.Middle(' . array_search($char,$chars,true) . ', 1)';
	}
	
	$lines = array();
	$lines[] = 'Function ObfuscatedString () As String';
	$lines[] = '  // Obfuscated string output';
	$lines[] = '  // Output: "' . $input . '"';
	$lines[] = '  ';
	$lines[] = '  Const Chars = "' . implode('',$chars) . '"';
	$lines[] = '  Return DefineEncoding(DecodeBase64(' . implode(' + ',$decoder_parts) . '),Encodings.UTF8)';
	$lines[] = 'End Function';
	
	$rbcode = implode("\n",$lines);
	$colorizer = new XojoSyntaxColorizer($rbcode);
	$htmlcode = $colorizer->GetHTML();
	
	echo '<p>Xojo Source:</p>';
	echo '<pre class="xojo_code">' . $htmlcode . '</pre>';
	echo '<p>Process some more:</p>';
}

Not really that complicated.

[Gilles_Plante]

@Thom_McGrath

Security through obscuring isn’t security at all.

+1000

[Ben_D]

@Thom_McGrath

Probably lots of lookups thanks to all the characters. The resulting method would probably crush even the Xojo IDE too, given the length of the line.

If you’d like to fix the crash and allow strings of much, much larger size (perhaps up to approx 100MB or more?) you could limit the number of iterations you’re doing (you do not need 1000 iterations to invalidate Base64) and you could echo directly to the browser instead of storing all the lines in an array, which is what seemingly causes your code to crash with big strings.

[Thom_McGrath]

Thanks, but it’s not really a huge concern. The class is one that I ported ages ago. It should have no problem handling huge methods, but the extremely long lines seems to throw it off. Being open source, if somebody wanted to fork it to make it more efficient, I wouldn’t complain. But it’s been up there for over 10 years without complaint, so it’s not something I’m going to spend a bunch of time on. Hell, even the last Xojo forum used the class without issue.

[Ben_D]

I don’t mean to be mean or anything, but is there a way to close threads? Otherwise I’ll just mute my own thread.