Tweet
Sometimes we need to hide certain sensitive strings in our programs to slow crackers down a bit as well as prevent casual viewing (in a hex editor for example). We could use advanced encryption algorithms for this purpose, and thanks to the work of several people - most notably Greg Turgeon - there are many powerful algorithms ready for us to "plug'n'play", including all three AES final candidates.
However, seeing as encrypted strings can be intercepted at the time of decryption regardless of the algorithm used that is often overkill. Or perhaps we're just creating a simple program and we just want to scramble a couple of strings ... again, using a strong encryption algorithm would be overkill.
Sometimes a simple scramble is all that's needed.
One thing with scrambling or encrypting strings is that you need to write a separate program to encrypt the strings, regardless of whether you use an advanced encryption algorithm or a simple REPLACE$() statement.
There is a very simple alternative that I often use in these situations which doesn't require any scrambling/encrypting, or a second program ... building the strings one character at a time, at run-time. The plaintext strings can be intercepted at the point where they've been put together, but actually from a cracking perspective that is no different to intercepting strings at the point where they've been decrypted, regardless of what encryption algorithm was used.
First lets consider a simple program with a string that we want to protect ...
Here's how the string looks inside the compiled executable when seen through the eyes of a hex editor:
Lets say we just want to hide "ADMIN" part of the string - we'll leave the rest alone for comparison. I'll simply break that part of the string up into individual characters: "A"&"D"&"M"&"I"&"N", which - in the eyes of the compiler - is 5 separate strings. However that on its own still isn't quite enough to obfuscate the text:
Now before we go on there are just two points that should be made in regards to how the compiler stores strings...
1 - Only one instance of each string is stored. The string "a"&"a"&"a" - which actually consists of three strings - is stored simply as one "a", with the code referencing that one string three times consecutively.
2 - The compiler scans through source files and stores strings in a top-to-bottom manner.
So now, keeping those two points in mind, lets see what happens when we add a dummy alphabet to the TOP of our source file (that is, before any other strings) ... here is the code:
And voila, our "ADMIN" string is now gone ...
If you're worried about overhead, don't be ... the PB compilers are quite optimised remember?
Each single character only adds 15 bytes to your code.
So for example, MSGBOX "The key is ADMIN" compiles to this:
Whereas MSGBOX "The key is " & "A"&"D"&"M"&"I"&"N" compiles to this:
However, seeing as encrypted strings can be intercepted at the time of decryption regardless of the algorithm used that is often overkill. Or perhaps we're just creating a simple program and we just want to scramble a couple of strings ... again, using a strong encryption algorithm would be overkill.
Sometimes a simple scramble is all that's needed.
One thing with scrambling or encrypting strings is that you need to write a separate program to encrypt the strings, regardless of whether you use an advanced encryption algorithm or a simple REPLACE$() statement.
There is a very simple alternative that I often use in these situations which doesn't require any scrambling/encrypting, or a second program ... building the strings one character at a time, at run-time. The plaintext strings can be intercepted at the point where they've been put together, but actually from a cracking perspective that is no different to intercepting strings at the point where they've been decrypted, regardless of what encryption algorithm was used.
First lets consider a simple program with a string that we want to protect ...
Code:
#COMPILE EXE FUNCTION PBMAIN () AS LONG MSGBOX "The key is: ADMIN" END FUNCTION
Lets say we just want to hide "ADMIN" part of the string - we'll leave the rest alone for comparison. I'll simply break that part of the string up into individual characters: "A"&"D"&"M"&"I"&"N", which - in the eyes of the compiler - is 5 separate strings. However that on its own still isn't quite enough to obfuscate the text:
Now before we go on there are just two points that should be made in regards to how the compiler stores strings...
1 - Only one instance of each string is stored. The string "a"&"a"&"a" - which actually consists of three strings - is stored simply as one "a", with the code referencing that one string three times consecutively.
2 - The compiler scans through source files and stores strings in a top-to-bottom manner.
So now, keeping those two points in mind, lets see what happens when we add a dummy alphabet to the TOP of our source file (that is, before any other strings) ... here is the code:
Code:
#COMPILE EXE SUB Alphabet LOCAL alpha AS STRING alpha="A"&"B"&"C"&"D"&"E"&"F"&"G"&"H"&"I"&"J"&"K"&"L"&"M"&"N"&"O"&"P"&"Q"&"R"&"S"&"T"&"U"&"V"&"W"&"X"&"Y"&"Z" END SUB FUNCTION PBMAIN () AS LONG MSGBOX "The key is: " & "A"&"D"&"M"&"I"&"N" END FUNCTION
If you're worried about overhead, don't be ... the PB compilers are quite optimised remember?
Each single character only adds 15 bytes to your code.So for example, MSGBOX "The key is ADMIN" compiles to this:
Code:
BA 04264000 mov edx, 00402604 // "The key is: ADMIN" E8 2C080000 call 00401AD3 31C0 xor eax, eax E8 39080000 call 00401AE7 E8 22050000 call 004017D5
Code:
BA 04264000 mov edx, 00402604 // "The key is: " E8 6C080000 call 00401B13 // Load string BA 34254000 mov edx, 00402534 // "A" E8 62080000 call 00401B13 // Load string E8 24070000 call 004019DA // Append string BA 4C254000 mov edx, 0040254C // "D" E8 53080000 call 00401B13 E8 15070000 call 004019DA BA 94254000 mov edx, 00402594 // "M" E8 44080000 call 00401B13 E8 06070000 call 004019DA BA 74254000 mov edx, 00402574 // "I" E8 35080000 call 00401B13 E8 F7060000 call 004019DA BA 9C254000 mov edx, 0040259C // "N" E8 26080000 call 00401B13 E8 E8060000 call 004019DA 31C0 xor eax, eax E8 2E080000 call 00401B27 E8 17050000 call 00401815
Attached Files
Comment