Word Virus

Spent a lot of time with the girls this weekend, which of course, means lots of pictures. Various photos from Saturday and Sunday playing and excursions.

My Top 10 Artists (Week Ending 2010-03-14)

1. She Wants Revenge (52)
2. Smart Went Crazy (40)
3. KMFDM (38)
4. Madvillain (33)
5. The Sisters of Mercy (31)
6. Circle Jerks (28)
7. Slayer (21)
8. Social Distortion (19)
9. Les Savy Fav (19)
10. Casiotone for the Painfully Alone (18)

last.fm profile page: gabrielingram

Ada’s first practice was inside, because of the rain yesterday. Hard to get any good shots, but here’s the potato practicing.

Things that make me happy: This is not a moon.

Here’s a few shots, only the iPhone ones, from Anais’ first soccer practice. Ada has her first practice on Thursday.

Early childhood development is really fascinating, especially in relation to philosophy, and how we understand the world. This morning, Anais, 3 years old, was sitting on the bed with her sister. Both of them had on “footie” jams. She put her legs over her sister’s and said, “We’re the same.” Then she looked at the pajamas, she had on Buzz Lightyear and Ada had on Disney Princesses, and said, “But they’re not the same.” She then gave me this really confused look, and said, “Daddy, our footie jams are the same, but they’re not the same.” In that brief moment, she stumbled upon one of the most fundamental questions that have plagued philosophy since the beginning. Then again, perhaps I’ve just been reading too much Heidegger of late.

Some iPhone pictures of the girls from this past weekend. Took them out to practice a little soccer, which starts today.

My Top 10 Artists (Week Ending 2010-03-07)

1. Pantera (62)
2. Casiotone for the Painfully Alone (54)
3. Slipknot (47)
4. Mudvayne (35)
5. Slayer (34)
6. Nine Inch Nails (32)
7. Arcade Fire (26)
8. Gorillaz (26)
9. Ween (25)
10. KMFDM (25)

last.fm profile page: gabrielingram

Since ColdFusion 3, there have been a set of undocumented tags, most of which control functionality in the ColdFusion Administrator interface. Two of these functions, cfusion_encrypt() and cfusion_decrypt(), were used all the way through CFMX 6/6.1 for securing the Administrator password and for RDS connections. Unlike the default encrypt/decrypt functions, cfusion_encrypt() returns back numbers between 0-9 and letters between A-F. When trying to encrypt data to pass through URLs, the default encrypt function can return non-friendly URL characters, and URLEncodedFormat is not useful for data that is already URLEncoded.


If we take a simple URL, http://someurl.com, and run it through the cfusion_encrypt(), we get back a string similar to this: 0502173B5F5642050C26000C1F1A4D280A14. As you can see, there are no strange characters, and it’s easily passed as a URL variable. For our purposes, this has less to do with security, and everything to do with transferring data. Since we need to decrypt this string in order to use it again, a hash function is not useful.


Obviously, these functions, discontinued in CFMX 6/6.1, are not available in BlueDragon .NET. After searching, we found, what appeared to be, a workable solution. However, when we started passing real data to these new functions, we received random errors. After some investigation, we determined that characters outside of the 255 character ASCII table were unsupported. It was at this point, that we started looking at the cfusion_encrypt() function in more detail. We assumed that cfusion_encrypt() was handing these characters correctly, since we never received an error when decrypting the data. However, upon closer examination, we saw that the non-ASCII characters were not being decrypted back to their original value. An error was not being produced, but cfusion_encrypt() was doing something that the supposed replacement tag was not. We all agreed that these characters should never exist in a URL, but we did not want to produce system errors because someone put in an invalid character. At this point, I started to reverse engineer exactly how the cfusion_encrypt()/decrypt() functions worked.

A basic overview of the cfusion_encrypt() function:

Cfusion_encypt takes two inputs, a string to encrypt and a key. At its simplest level, cfusion_encrypt() takes the length of the string, it loops over the key (repeating when it reaches the end) and does an XOR of the two values at a base 10, and returns them as a base 2. However, this did not explain how the cfusion_decrypt() function didn’t produce errors when trying to decrypt the encrypted data. After comparing the encrypted data from the ne encryption function and cfusion_encrypt(), I determined that cfusion_encrypt() always only returned the right 2 characters of whatever character it encoded. Non-ASCII characters actually returned a 4 character result, but cfusion_encrypt() only returned the last two. Since we wanted to mimic this functionality exactly, I followed the same logic, and created the following new functions.

 ColdFusion | 
 copy code |
?
 
01
<!--- Author : Gabe Ingram, Date : 3/4/2010, Purpose : replacement encryption for cfusion_encrypt --->
02
<cffunction name="setEncryption" access="private" output="false" returntype="string">
03
 <cfargument name="rawString" type="string" required="true" />
04
 <cfargument name="encryptionKey" type="string" required="true" />
05
 <cfscript>
06
  var k = 0;
07
  var result = "";
08
  var newKey = repeatString(arguments.encryptionKey, ceiling(len(arguments.rawString) / len(arguments.encryptionKey)));
09
  for(k = 1; k lte len(arguments.rawString); k = k + 1){
10
   result = result & right(replace(ucase(rJustify(formatBaseN(bitXOR(asc(mid(arguments.rawString, k, 1)), asc(mid(newKey, k, 1))), 16), 2)), " ", 0), 2);
11
  }
12
 </cfscript>
13
 <cfreturn result/>
14
</cffunction>
15
 
16
<!--- Author : Gabe Ingram, Date : 3/4/2010, Purpose : replacement decryption for cfusion_decrypt --->
17
<cffunction name="getDecryption" access="private" output="false" returntype="string">
18
 <cfargument name="encryptedString" type="string" required="true" />
19
 <cfargument name="encryptionKey" type="string" required="true" />
20
 <cfscript>
21
  var k = 0;
22
  var result = "";
23
  var newKey = repeatString(arguments.encryptionKey, ceiling(len(arguments.encryptedString) / 2 / len(arguments.encryptionKey)));
24
  for(k = 2; k lte len(arguments.encryptedString); k = k + 2){
25
   result = result & chr(bitXOR(inputBaseN(mid(arguments.encryptedString, k - 1, 2), 16), asc(mid(newKey, k / 2, 1))));
26
  }
27
 </cfscript>
28
 <cfreturn result/>
29
</cffunction>

I’m not going to explain all the formatBaseN, inputBaseN and bitXOR logic, but I will explain how I got results that matched the original cfusion_encrypt() functions. After bitXOR returns the base 10 character, we need to rJustify the result by 2. This was throwing me for a loop to begin with, but after looking at some specific results it made a lot more sense. If the input string is the letter “a”, what I got back based on my key was the letter “c”. In order for the decrypt to work properly, every character returned needs to be 2 characters long. So, by using rJustify(2), every single character has a length of 2 characters, even if the first character is simply a space. In order to match the cfusion_encrypt() exactly, I then upper cased the characters, and replaced all spaces with a 0. When we issue the decrypt function, it will ignore the 0 if it’s the first character, because of the inputBaseN(16). The final missing piece was making sure that all results were only 2 characters long. When you use rJustify, it only extends a string by the number of characters requested; it doesn’t trim strings that are too long. By using right(2), I ensured that no resulting string could be longer than 2 characters. This process matches the functionality of cfusion_encrypt() exactly.

For our purposes, we wanted to ensure that no existing code or data produced an error. If you wanted to prevent non-ASCII characters completely, you could check that the asc() value of the character is never greater than 255. If it is, then return an error to the user about incorrect data type, etc.

The only reason I find this so funny, is that Sky and I have this discussion all the time. I’ll say a color, and she’ll correct me with some obscure color off a crayon. Damn designers.