Adventures in Encryption Breaking

Background

Well over twenty years, when I owned Quality Software Solutions, I cracked the hardest encryption, obfuscation scheme, or whatever you want to call it. I have always considered reverse engineering completely ethical under two conditions — if the sole purpose was fixing a broken system or extracting data for its true owner.

So, I contracted to perform (what I call a ‘hostile extraction’) for the customer of one of my dealers. I considered a hostile extraction one that was performed with the developer placing unreasonable barriers to their paying customer gaining access to their data.

Remember that I am thinking back without the benefit of notes. But, as best as I remember, this was the scheme they used to obscure their customer’s data.

The Scheme

The files were fixed-length binary files. The numbers, such as incremental patient ID and Unix epoch number, were not encrypted. The text, however, was encrypted.

The text was stored in 3 characters per 16-bit space. Each character took 6-bits. I found a character table in one of the binary libraries of program files. I determined an algebraic function that the first six bits could be plugged into to yield an intermediary number. Let’s call it f(x). You could then take (size of table) modulus x and it would yield the vector into the character table. There was another algebraic function, let’s call it g(y), that you could take the next 6 bits and perform a similar procedure to determine the second character. The third character was the nightmare: the function, let’s call it h(z), dynamically changed based on the values of x and y for that particular 3-character set.

Hints and The Real Help

So, how was I able to crack the scheme? First, having access to paper copies of a lot of the records was critical. Picking up on the 6-bit first character was a lucky wild guess that made everything after it possible. The data files being fixed length helped. Finding records with repeated groups of three characters was extremely helpful as that allowed me to reverse engineer the two stock functions and finally the creation method of the dynamic one. Now, although my atheistic friends may disagree, let me tell you what I believe. I finally gave up and knelt down in my office and admitted to God Almighty that I couldn’t do this one myself. I needed Him to help. In my opinion, His help is the only reason I finally cracked the code.

Passing Thoughts and Lessons Learned

  • I never again did a hostile extraction. I did not sleep for many days. Working around the clock for days is not healthy and I vowed to never do it again.
  • The most important lesson — I am not as smart as I would like to think. However, other evidence has reinforced that over the years. My one encryption patent application, 12/942138, METHOD AND APPARATUS FOR DATA ENCRYPTION, was was marked abandoned at the patent office 11/6/2014 because my former employer judged it not worth the continued investment. My big money maker, when I owned my company, TimeClock Lyte, had an encrypted software key. It was my big money maker until several folks cracked my encryption scheme. You could find sites all over the world that would give you a free key to my software. I did not know it until I had already initiated shutting down my company. The thousands and thousands of dollars missing from my bank account is proof positive that I am not as smart as I thought. BTW, you can still see some of the hackers work by searching Google for TimeClock Lyte. I guess nearly bankrupting me personally gives them such a sense of satisfaction that they still want to brag.
  • I still strongly believe that it is ethically wrong for software engineers to restrict access to a customer’s data from that very customer that has paid for that data with their money and hard work. If you, or your company, is blocking them from their data — STOP IT.
  • Here is a parting general data science observation. It does not matter why the original developers of that antiquated practice management software encrypted the data nor does it matter if they used the same scheme that I used when I broke it. All that matters is finding relationship that works and using it. Causal relationships are for the research paper. Working the observed relationships for a solution is what matters.

Leave a Reply

Your email address will not be published. Required fields are marked *

Adventures in Encryption Breaking


Background

Well over twenty years, when I owned Quality Software Solutions, I cracked the hardest encryption, obfuscation scheme, or whatever you want to call it. I have always considered reverse engineering completely ethical under two conditions — if the sole purpose was fixing a broken system or extracting data for its true owner.

So, I contracted to perform (what I call a ‘hostile extraction’) for the customer of one of my dealers. I considered a hostile extraction one that was performed with the developer placing unreasonable barriers to their paying customer gaining access to their data.

Remember that I am thinking back without the benefit of notes. But, as best as I remember, this was the scheme they used to obscure their customer’s data.

The Scheme

The files were fixed-length binary files. The numbers, such as incremental patient ID and Unix epoch number, were not encrypted. The text, however, was encrypted.

The text was stored in 3 characters per 16-bit space. Each character took 6-bits. I found a character table in one of the binary libraries of program files. I determined an algebraic function that the first six bits could be plugged into to yield an intermediary number. Let’s call it f(x). You could then take (size of table) modulus x and it would yield the vector into the character table. There was another algebraic function, let’s call it g(y), that you could take the next 6 bits and perform a similar procedure to determine the second character. The third character was the nightmare: the function, let’s call it h(z), dynamically changed based on the values of x and y for that particular 3-character set.

Hints and The Real Help

So, how was I able to crack the scheme? First, having access to paper copies of a lot of the records was critical. Picking up on the 6-bit first character was a lucky wild guess that made everything after it possible. The data files being fixed length helped. Finding records with repeated groups of three characters was extremely helpful as that allowed me to reverse engineer the two stock functions and finally the creation method of the dynamic one. Now, although my atheistic friends may disagree, let me tell you what I believe. I finally gave up and knelt down in my office and admitted to God Almighty that I couldn’t do this one myself. I needed Him to help. In my opinion, His help is the only reason I finally cracked the code.

Passing Thoughts and Lessons Learned

  • I never again did a hostile extraction. I did not sleep for many days. Working around the clock for days is not healthy and I vowed to never do it again.
  • The most important lesson — I am not as smart as I would like to think. However, other evidence has reinforced that over the years. My one encryption patent application, 12/942138, METHOD AND APPARATUS FOR DATA ENCRYPTION, was was marked abandoned at the patent office 11/6/2014 because my former employer judged it not worth the continued investment. My big money maker, when I owned my company, TimeClock Lyte, had an encrypted software key. It was my big money maker until several folks cracked my encryption scheme. You could find sites all over the world that would give you a free key to my software. I did not know it until I had already initiated shutting down my company. The thousands and thousands of dollars missing from my bank account is proof positive that I am not as smart as I thought. BTW, you can still see some of the hackers work by searching Google for TimeClock Lyte. I guess nearly bankrupting me personally gives them such a sense of satisfaction that they still want to brag.
  • I still strongly believe that it is ethically wrong for software engineers to restrict access to a customer’s data from that very customer that has paid for that data with their money and hard work. If you, or your company, is blocking them from their data — STOP IT.
  • Here is a parting general data science observation. It does not matter why the original developers of that antiquated practice management software encrypted the data nor does it matter if they used the same scheme that I used when I broke it. All that matters is finding relationship that works and using it. Causal relationships are for the research paper. Working the observed relationships for a solution is what matters.

Leave a Reply

Your email address will not be published. Required fields are marked *