Help me decode what looks like base64

Have you considered, instead of solving this problem by talking to the database, automating the program through its interface with something like http://sikuli.org/? It's not as robust a solution, but if you don't need it to run without supervision and can work within Sikuli's limitations, you might be able to avoid the whole reverse-engineering project.

So what you/we know so far: * The output is almost certainly base64-encoded; the two equals signs at the end give that away. * Given that, the input into the base64-encoding process is 16 bytes long; a 16-byte input generates a base64-encoded string of the length that you're seeing with the two equals signs padding the end of it. * Given that your inputs are of variable length, there's another process, likely a hash function, that's turning what you put in into the 16-byte input to the base64 encoding process. * Given that you see the same output for "a" and " a ", you know that that the input has spaces stripped from it before being hashed, or the hash function itself strips spaces. * Given that "Base64??" and "base64??" produce different output, you know that the hash function is case-sensitive and that the input is NOT case-normalized before being hashed. * Given that you see the same output for "a" and " a ", you know that if there is a salt involved in the hash function, it's not a random salt but rather a fixed one. I just did a simple test which took "metafilter", created a straight MD5 hash of it (which outputs a 16-byte digest), and then base64-encoded that digest; the output ("TPc3tK3+eXqXTeyOGZ0Tcg==") does not match your known value, so that's not it. There aren't many more common hash functions that output 16-byte digests -- SHA-1 is 20 bytes, SHA-256 is 32 bytes, SHA-512 is 64 bytes. So either this is a rare or novel hash function, or the app is salting the input string with a static value, hashing it with MD5, and then encoding it to base64. That's my bet.

Thanks for the offer, jkaczor, but it looks like that's a different company. I'm still working on using some disassemblers, but it's slow going right now. I'm hoping that as I continue to pick apart other aspects of this programs, I might luck into finding something to point me in the right direction.

Well - I suggest going another way... If the company is truly defunct (and the software un-supported), then it wouldn't hurt to try contacting some people who used to work there, no? Was this "iCode Systems Ltd." in the UK? Within my extended network, it turns out I can possibly contact up-to 7 different people who have purported to work there in the past (one even as "founder/owner"). It may cost a couple $$$, but it is worth it, rather than trying to go down "rabbit-hole" after "rabbit-hole" - especially if as above, it appears to have quite a few encryption algorithms in-built. Could try using a "strings" utility on the executable to see if they stupidly left the key in a resource string somewhere... ;-) (doubtful)

OK, so I bet it's either doing a salted MD5 hash that's then getting base64-encoded, or it's doing AES encryption. (AES encryption uses a block size of 128 bits, or 16 bytes, so encrypting input that's less than or equal to 16 bytes would produce a 16-byte output.) If it's the former, then you'd have to find the salt in the source somewhere in order to replicate what it's doing. If it's the latter, you'd have to find the key.

And for those playing along at home, here's the output from http://ask.metafilter.com/218270/Help-me-decode-what-looks-like-base64#3152179: - start signatures scanning: offset num description [bits.endian.size] -------------------------------------------- 01b279f4 165 AES Rijndael S / ARIA S1 [..256] 01b27af4 166 AES Rijndael Si / ARIA X1 [..256] 01b27c2c 168 Rijndael Te0 (0xc66363a5U) [32.be.1024] 01b2802c 170 Rijndael Te1 (0xa5c66363U) [32.be.1024] 01b2842c 172 Rijndael Te2 (0x63a5c663U) [32.be.1024] 01b2882c 174 Rijndael Te3 (0x6363a5c6U) [32.be.1024] 01b27bf4 186 Rijndael rcon [32.be.40] 01b278e4 191 Blowfish bfp table [32.be.72] 01b3235c 289 MD5 digest [32.le.272&] 01b2a58b 309 padding used in hashing algorithms (0x80 0 ... 0) [..64] 01b27904 326 Haval hash pass2 [32.be.128&] 01b214d7 357 Zlib dist_code [..512] 01b216d7 358 Zlib length_code [..256] 01b2139c 360 Zlib base_length [32.le.116] 01b21410 362 Zlib base_dist [32.le.120] 01b2d398 371 LZ Huffman (lzhuf/lha) decoding table [..256] 01b2d358 372 LZ Huffman (lzhuf/lha) encoding table [..64] 01b266f0 384 Jpeg dct 14 bit aanscales [16.le.128] 01b26770 388 Jpeg dct AA&N scale factor [double.le.64] 00042366 564 TEA encryption/decryption (0xc6ef3720 0x9e3779b9) [32.le.8&] 008b27e0 1228 rfc3548 Base 64 Encoding with URL and Filename Safe Alphabet [..62] 008c31b8 1234 UUEncodeTable [..64] 008b27e0 1237 B64EncodeTable [..64] 008c2f24 1240 XXEncodeTable [..64] 008c1590 1243 BHEncodeTable [..64] 01b278e4 1300 Haval init [32.be.32&] 000422e1 1483 TEA1_DS [32.le.4] 01b20d6c 1525 zinflate_lengthExtraBits [32.le.116] 01b20de0 1529 zinflate_distanceExtraBits [32.le.120] 01b20ddd 1530 zinflate_distanceExtraBits [32.be.120] 01b3235c 1626 Lucifer (outerbridge) DFLTKY [..16] 01b3236c 1639 Misty md5const [32.le.256] 01b2d318 1646 Huffman LZH p_len [..64] 01b2d498 1647 Huffman LZH d_len [..256] 0004be14 1767 anti-debug: IsDebuggerPresent [..17] 0248712e 1887 libavformat gif_clut [..648] 01b26b3b 2094 libavcodec ff_mjpeg_val_ac_luminance [..162] 01b26bee 2095 libavcodec ff_mjpeg_val_ac_chrominance [..162] 01ce54ad 2272 compression algorithm seen in the game DreamKiller [32.be.12&] - 39 signatures found in the file

(At some point, we might learn what DB this is, what app it is, etc...) It's MS SQL Server, but like I said, tracing the DB indicates that this is all being done within the application. This is a legacy piece of inventory/accounting software written by a now-defunct company called iCode.

(At some point, we might learn what DB this is, what app it is, etc...)

Disregard my previous post. I didn't read clearly enough and forgot how base64 encoding worked. delfuego's analysis is most likely correct.