Database Reference
In-Depth Information
What I am suggesting here is code obfuscation. The logic is hidden in plain sight. It is hard to know
whether this produces much of an obstacle to reading our code, but it would require several conversion
steps—the same steps we take to obfuscate our code, in reverse.
Obfuscate the Logic
One of my favorite aspects of Java code is its readability. I do compress my code with stacked method
calls, and there is the object-oriented aspect to Java code that must be comprehended, but in all it is very
readable. What if we make it our goal to make it less readable? The first step we can take is to use our hex
encoding rather than the standard Base64. The rest of the ideas here are intended to give you an idea of
what can be done to obfuscate code. Be aware that what makes your code harder for a hacker to
understand will also make your code harder for you to understand and to maintain. For that reason,
keep a copy of your original code in a secure location for your own reference.
We have a calculated field called
eTLength
, which is the length of our initial connection string, but
we don't need a method member if we are willing to get the length of the string each time it's needed.
We can add complexity by concatenating
Strings
rather than using a
StringBuffer
. It is not as
efficient—in fact, it clutters memory with transient strings, but the logic is less obvious. Let's also
convert the
for
loop to an eternal
do while true
loop. We will break the loop by breaking to a label,
GT
:
we are creating the Java equivalent of a
GOTO
statement. We have a bit of inside knowledge about the
expected input/output; the encoded string (using our padded hex encoding) will be twice as long as the
connection string. Using that knowledge, we will break out of our loop when the encoded string is long
enough; that is, twice the length of the connection string, modulus the length of the connection string
equals 0. We know the next position in our original byte array that we need to deal with is the one at half
the length of our encoded string as it is being concatenated together. There may be insufficient
characters in our other byte array to XOR with the connection string bytes, so let's wrap around to the
front of the “other” byte array by using modulus. We do that instead of concatenating
location
to itself
until long enough. So far our obfuscated code is as shown in Listing 11-5.
Listing 11-5.
Obfuscated Logic, Step 1
static String encode( String encodeThis ) {
byte[] eTBytes = encodeThis.getBytes();
byte[] xBytes = OracleJavaSecure.location.getBytes();
String decodeThis = "";
String oneByte;
GT: do {
oneByte = Integer.toHexString(
(int)eTBytes[decodeThis.length()/2] ^
(int)xBytes[( decodeThis.length()/2 ) % xBytes.length] );
if( oneByte.length() == 1 )
decodeThis += "0"
;
decodeThis += oneByte
;
if(
( ( decodeThis.length()/2 ) % eTBytes.length ) == 0
)
break GT
;
} while( true )
;
return decodeThis;
}
Looking at our code, we see a number of hard-coded integers, most of them equal to 2. Let's create a
member integer that by complex calculation works out to be 2 and use it in pace of those integers. We
