This is a mirror of the elboxdecrypt,
GPL
licensed application.
You can get it here: elboxdecrypt-1.2-bin.lha, elboxdecrypt-1.2-src.lha (NOTE: this is
AmigaOS source code!)
The original (temporarily down) home page of elboxdecrypt is at
http://isuq.selfhost.com/.
The text below is README file from the elboxdecrypt-1.2-src.lha, copyright by Qwe, released under GPL license.
elboxdecrypt 1.2
================
This is a update to original elboxdecrypt program. It can now decrypt the
latest pci.library 6.2 and MediatorNET.device.
It appears the pci.library 6.2 no longer contain the RDB trashing routine.
Elboxdecrypt was updated so that anyone can check the library by themselves.
Naturally anyone with some experience can check the drivers for anti-E3B
code, too. ("New Elbox drivers (e.g. for Mediator) do not work when you
have any USB card from E3B (subway, highway, algor) installed in your
computer.")
Elbox drivers contain harddisk trashing code
============================================
History
=======
As a Mediator owner, I always wondered why elbox encrypt their drivers. While
fiddling with their usb.device to know what was the difference between the
Spider USB card they sell and a standard NEC USB card I discovered some
suspicious code that would get triggered if someone attempted to modify the
driver to look for the NEC USB pci subvendor ID (which is the only difference
with the Spider USB card, oh, and a sticker on the chip).
This code trashes block 0 of the harddisk the system booted from, which
usually contains the RDB which has the partition informations. Trashing this
block means that the system doesn't boot anymore and all the partition are
lost. This is very serious!
Even worse. The code is also present in pci.library and might run if someone
is running a decrypted/modified library. Besides, given that AmigaOS has no
memory protection, the code could be triggered accidentaly. I'll explain later
what the code does exactly.
Finding out
===========
Since it seems some people don't believe me, I provide here a small program
that decrypts the library (pci.library version 5.6). As you can see it's
not too complicated and the result can be disassembled easily. Anyone with
some basic C and m68k assembly experience can do the check.
1: compiling elboxdecrypt
=========================
Just type smake if you use SAS/C or the make if you use GCC.
It should also compile fine with other compilers without modifications.
2: unencrypting pci.library
===========================
Run the following command:
1.> elboxdecrypt pci.library pci_clear
found resident structure at offset 2 (0x2)
found elbox' "cipher"
code size: 0x8204 (0x200C) bytes
decrypted
wrote "pci_clear"
3: disassemble the code
=======================
Ok, if you don't know assembly you can still check for the string 'RDSK'. This
string is used to check if block 0 is really a RDB and means RidigDiSkBlock.
You'll see that this string is present, isn't it suspicious? Well, to be sure,
let's disassemble the RDB trashing part.
For that, go to aminet and download dev/asm/ira102.lha which is a fine
disassembler. Run it with the following command:
1.> ira -a pci_clear pci_disasm
680x0 - ReAssembler V1.02 (Sep 6 1993) (C)1993 Tim Ruehsen
Source : pci_clear
Target : pci_disasm
MACHINE: MC68000
OFFSET : $00000000
CACHE : 10 Kb
Pass 1: 100%
Pass 2: correcting labels
Pass 2: writing mnemonics
100%
4: read the code
================
Now, the interesting part is at offset $1e40 (ira prints the offsets on the
right, after the colon) which is the beginning of the RDB trashing code. At offset
$1e4c they take the value of the low byte part of the CIAA chip timer B and if
the 4 lower bits are 0, the RDB trashing is not triggered. This adds some
randomness so that the RDB is not trashed every time and someone who uncrypted
the library will perhaps not notify it immediately and think his system is
screwed up as the RDB will be trashed "from time to time".
At $1e60 "dos.library" is opened and DOSBase examination started at $1e6a.
They get dl_Root->rn_Info which points (BPTR) to a di_DevInfo which contains
the device list of the system. At $1e80 they look for DLT_DIRECTORY which is
an assign.
LAB_013E is the loop that searches for the 'SYS:' assign. $1e8c checks if the
type is really an assign and $1e9a compares if the string is 'SYS' (BSTR). If
found, the device name is kept in regiter a1 at $1eaa.
Then the DosList is scanned again to find the DeviceNode of 'SYS:'. Same stuff
as before except they look for DLT_DEVICE at $1ebe. Type is checked at $1eca
and the device's dl_Name is copied at $1ed4. Device is compared with the
device name found before at $1ee0. At $1ef6 they get the FileSystemStartupMsg
which is used to send commands to a device. They CreateMsgPort() at $1efe and
create an IORequest at $1f0e. Everything is ready fo the OpenDevice() at
$1f2a.
Now they need some temporary storage. They allocate 512 bytes of memory at
$1f3a and fill it in by sending a CMD_READ [$1f46] to the device. Two
interesting things to note here: first, the call to DoIO() is "hidden" by
moving a6 to a0 [$1f5c] and doing a jsr (a0) [$1f64]. This is a technique
mostly used by viruses to hide themself from scanners searching for a
jsr -456(a6) in the code. The other interesting bit is that their routine only
scans block 0 but the RDB can be stored in any of the first 16 blocks. RDB is
at 0 most of the time though. Elbox will happily fix that for their next
drivers update ;)
Ok, let's continue. After issuing a read command, they compare the string
'RDSK' with the first 4 bytes of the block [$1f66] to make sure it's a RDB. If
this is the case, they issue a CMD_WRITE [$1f72] with random data [$1f78] and
overwrite the RDB [$1f90]!
The code is triggered if the library detects that it's unencrypted. Usually
the Resident's structure InitCode is run, which decrypts the driver and
decrements a counter. The decrypted part of the code checks if the counter is
0 and if it isn't it triggers the RDB killing code (which, as I mentioned
earlier is not triggered every time to add confusion). The elboxdecrypt
program does NOT produce a fully working unencrypted executable because
I didn't bother fixing the Resident structure relocation. You can do that
pretty easily though.
So, why did I publish that? Well, I was pissed enough to have a RDB destroyed
just because I tried to find out if a standard NEC USB card would work with my
mediator. This kind of code is dangerous and illegal. If you still don't
believe that the code is there, ask a friend who knows about programming and
he'll confirm that the above is true (or just try looking for the RDSK
string).
This archive was all made by me and contains code written by me. Nothing from
Elbox.
-Qwe