Database Reference
In-Depth Information
Listing 11-3.
Base64 Encoding
String decodeThis = (new BASE64Encoder()).encode( code );
Oracle has included Base64 encoding in the JVM; however, it is a bother to use. We can call upon
sun.misc.
BASE64Encoder
to do our encoding, but look at the package it is in. This is a part of the JVM, but
is proprietary. When we compile code that uses that class, we get this warning message:
sun.misc.BASE64Encoder is Sun proprietary API and may be removed in a future release
We can acquire the Base64 algorithm form many free sources, if we want. But fortunately, Base64
encoding is not the only game in town. We can create our own printable encoding. Look at Listing 11-4.
Let's take every
int
resulting from the XOR and get the
String
representation in hex format by calling
Integer.toHexString()
. Our hex strings will be either one or two characters in length, ranging from
0
(0x00) to
fe
(0xfe) in hexadecimal (0 to 254 in decimal). When the number is less than 0x10, it will have
only one character, but we want to know how to break up our encoded string, so we will prepend those
hex strings with a “0” character. That way each byte is represented by two characters, and we know how
to parse and decode each character. We might call this Padded Hex XOR Coding.
Listing 11-4.
Padded Hex XOR Encoding
StringBuffer sBuf = new StringBuffer();
String oneByte;
for( int i = 0; i < eTLength ; i++ ) {
oneByte =
Integer.toHexString
( (int)eTBytes[i] ^ (int)xBytes[i] );
if( oneByte.length() == 1 ) sBuf.append( "0" + oneByte );
else sBuf.append( oneByte );
}
String decodeThis = sBuf.toString();
Decoding this
OJSCode
'ed connection string is just the same process, in reverse. We call
Integer.parseInt()
on each pair of characters, using a
radix
of 16, so we convert from hex to decimal.
Then we XOR the integer with the same other byte from our “location” string that we had used before.
This gets us back to the original characters from which we rebuild our connection string.
Using Base64 encoding, the coded string is shorter. Here is an example (notice the telltale “=” sign
padding at the end):
IE5DEgtTNVAUOUUGKw4aQkUnFR8KQA==
Our own encoding creates longer strings. This is the same string encoded with our algorithm.
204e43120b533550143945062b0e1a424527151f0a40
Obfuscating the Algorithm/Code
Our plan for
OJSCode
is to encode our
appver
password. In this case, our Java code is analogous to an
encryption key. With a key, what we encrypt can be decrypted. With
OJSCode
, our encoded password can
be decoded and read by anyone who has access to the
OJSCode
class.
If a hacker has this class but cannot see the
OJSCode
Java code, then she won't be able to reproduce
the logic, and there is one hidden aspect that he won't be able to duplicate: we call out of the class to get
the
location
string in the
OracleJavaSecure
class. That isn't much of a security feature, but if we hide it,
it will be a major hindrance to the hacker.
