[argyllcms] Re: dtp22 not working with Argyll
- From: Alan Rockwood <alanrockwood2000@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sat, 13 Dec 2008 11:38:16 -0800 (PST)
--- On Thu, 12/11/08, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
> For the DTP22 it's more than a password, it's a
> challenge/response using
> an algorithm. There are too many combinations to simply
> iterate
> through possibilities, so the main practical way of
> discovering it
> is to dis-assemble a working driver for that particular
> instrument.
> I suppose another way would be to capture the coms for
> between the
> working driver and instrument, and then try all reasonable
> combination
> purely in software, but even this may take too long.
>
> Graeme Gill.
Using Graeme's hints and a serial port logger when running ColorPort or
spotread I have figured out a little more about the dtp22 password system. It
seems to work something like this:
After some preliminary data exchange the computer sends: GP
DTP22 responds with: xxxxxxxxxx, where xxxxxxxxxx is an apparently random
sequence of ten lower-case alphanumeric characters representing a hex number.
The computer then responds with an upper-case string of up to six alphanumeric
characters. The last two characters are always VD, and the first few characters
(as many as four characters) are a hex number. Any leading zeros are stripped
from the number. In most cases there are four hex characters preceding the VD
code.
If all is well the DTP22 responds with the four-character sequence PASS.
Each time a spectrum read is requested above sequence is repeated prior to the
sending of the read command to the DTP22. Each time the sequence is repeated it
is associated with a different ten-character number sent from the DTP22 as well
as different response string from the computer.
I hypothesize that when the computer receives the random sequence it must
calculate a new sequence for response, possibly by some kind of encryption
algorithm.
There must be at least one public key provided by the DTP22. In the case of my
instrument this could be one of the following numbers:
Serial Number: 4744
OEM Serial #: 009
Cal Plaque Serial #: 4744
BOOT version: 5B15-B
Software version: 8428
Of these numbers the most likely one(s) in my opinion are the BOOT version or
the Software version. ColorPort requests this information at the beginning of a
session. So does spotread.
Encryption is done on both sides of the link, and when the PC software sends
its computed result back to the DTP22, the DTP22 compares the number it
received to the value it calculated in order to see if it matches. If so it
will return a PASS code to the PC.
The algorithm for generating the random number is probably irrelevant. However,
the encryption algorithm is important. It is known by the software on-board the
DTP22. The PC software must also know the encryption algorithm if it is to
unlock the DTP22 to enable the DTP22 to send spectral data to the computer. If
there are any private keys they must be known by both the DTP22 and the PC
software.
My guess is that the encryption algorithm is probably not very special. It my
be something as simple as a parity calculation, or maybe it is a readily
available algorithm, such as one might find in the book "Numerical Recipes."
The reasons are: 1) The programmers of the DTP22 were probably very busy and
behind schedule when they did the project. (This is always the case with
software projects.) They probably therefore took the easy path in coming up
with the encryption scheme. 2) They probably did not want to tax the on-board
computer in the DTP22 with a heavy algorithm. 3) The likelyhood that someone
would try to break the encryption scheme is relatively low, and the
consequences of someone breaking the encryption scheme are not very dire.
Therefore, it seem unlikely that the DTP22 would have a very strong encryption
scheme. However, if there is a private key in the scheme the whole thing is a
little harder.
By the way, ColorPort is free software from X-rite that can generate and read
color charts. It is capable of saving chart data, including spectral data, in a
number of data formats. I believe that Argyll has a utility to convert
ColorPort data to Argyll data. Is there a utility to convert Argyll color
target charts to ColorPort color target charts? This would be good because it
would enable one to use Agyll to generate a chart, and then, after conversion,
read it using ColorPort. The results could then be converted back for use by
Argyll.
Other related posts:
