UBE98 is an encryption program by CIPHERTech at:
CIPHERTech

The site is in England so the chap who designed the program isn't encumbered by the United States' EAR (Export Administration Regulations).

The UBE98 author describes the program:

255 Byte RC4 Algorithm - The strongest encryption algorithm in the world! Automatic Encryption - Self extracting Encrypted file creation - QuickView encrypted pictures - Win98 style caption bars and menus - Seamless windows 95/98/NT integration - Transparent use - UBE 98 has to be the choice for you. Download it now for free!

You might notice that the BBC refers to a 2,048-bit key while the author says the key is 2,040 bits. The time needed to brute-force such a key, of course, is wrong, too. There are other errors in the report, too, that I'll let you enjoy (or cringe at) at your leisure. UBE98's problems are bigger than just a reporting error over the real size of the key, and the time it would take to brute-force the key. The British government likely isn't worried about having to crack UBE98 if it needs to. In this paper, I'll describe three ways to break UBE98.

I was first reminded of UBE98 in sci.crypt when I saw a mention of the program's file wiping capability. Later, I noticed Mike Stay commenting in coderpunks on UBE98's encryption capability. Some experts responded to the initial mention of UBE98's large RC4 key as quite possible, and asked why they thought the original poster considered the program snake-oil. I am sure had those experts looked at the program they would have determined quickly the worthlessness of UBE98 as an encryption program.

Stay soon described his attack in coderpunks:

I downloaded the thing. It asks for a bunch of information (like e-mail address, name, address, 25 random keystrokes). I wrote Peter about how he created the key and he says it's MD5 and SHA plus some "random bytes from various places in the computer." The key is stored somewhere and protected with a password. It's always the same key. I encrypted a file of zeros and another file, XORed the two and got the original. A known plaintext attack will break every file you ever encrypt with this (because it only generates one key, ever.)

So I set about finding a couple more attacks on this dubious symmetric cipher.

UBE98 does typical symmetric encryption and lets you create self-extracting encrypted executables. In order to access the content of either encryption you need to enter a password. Since, as Stay pointed out, the key is always the same, I theorized the program's check of the correct password might be subverted in a way less conventional than typical cryptanalytic attacks.

Let's consider a typical encryption first. We'll assume that we have access to the victim's machine. We are going to try Stay's attack on UBE98, but we'll bring with us a few of floppy disks for copying *.ube files. One of our disks will be home to a file (500k or so) of 00s of known-plaintext and a hex editor such as HIEW. First, we'll copy all of the encrypted .ube files to floppy disk. Next, we'll need to encrypt our known-plaintext (the 00 file) with the victim's key. We'll assume that he hasn't left the password in memory, even though UBE98 has that capability.

So we'll need to bypass the password. Naturally, we have figured out a way to bypass it.

A file called hook32.exe is the program's executable. Upon previously disassembling the .exe we found an interesting JE instruction in the code prior to the error message string: "You have entered an incorrect password."

:0044A026

7458

je

0044A080

In our hex editor, we change the JE instruction to JNE by changing 74 to 75 at offset 00049426h and run UBE98 with our slightly modified executable. The result: UBE98 accepts an incorrect password or no password at all and decrypts any encrypted file.

Armed with that knowledge, we attack the victim's UBE98 installation and either hex edit the UBE98 executable or run a patch to change the instruction. Now we can either XOR at our leisure on our own system, or decrypt while at the victim's system.

Self-extracting encrypted files are intended to provide a way to send encrypted email. It's not a bad idea, but normally you still need to find a way to securely transmit the key. Finding a secure way to transmit the key, unfortunately, in UBE98's case makes little difference since a self-extracting encrypted file can be cracked in the same way as hook32.exe.

We can assume either we have access to the sender's machine or that we have the capability of intercepting the sender's and recipient's email. In either case, we are in possession of encryptedfile.exe. We guess that the password is likely checked as it is in hook32.exe and look for a JE instruction in the disassembly.

In the disassembly, we find the string "You have not entered the password with which this file was encrypted. Please try again."

We find this instruction prior to the error message string:

:0042D13E

0F84A0000000

je

0042D1E4

In our hex editor we change JE to JNE (84 to 85). When we execute the self-extracting encrypted file we find that, like hook32.exe, an incorrect password or no password at all decrypts the file. UBE98 is even worse than I thought.

On August 29, emrul Islam wrote to sci.crypt:

From: emrul Islam 
Newsgroups: sci.crypt
Date: Sat, 29 Aug 1998 18:34:54 +0100
Organization: Virgin News Service
Lines: 8
Message-ID: <35E83BBE.3F9C7934@virgin.net>
NNTP-Posting-Host: 194.168.69.127
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.05 [en] (Win95; I)


1. In UBE '98 make an .exe of any file with any password.
2. Decrypt it without typing in anything for the password.

3. It decrypts without any password - the best crypto product I'd say.

-Emrul

Mail Joe Peschel

Copyright Joe Peschel

August 1998