On-line engine blitz tourney July

[op12no2]

p19: 'tell 49 Lozza vs. Nemeton a game in tourney #1 just ended. Lozza checkmated 0-1'
p3: 'tell 49 Nemeton vs. Lozza a game in tourney #1 just ended. Lozza checkmated 1-0'

Let me know if I need to tweak Lozza's output. But AFAIK it has not changed since previous events.

[Joost Buijs]

The server is still off-line, is it clear yet what causes the time-seal decoder to crash?

Since the algorithm and the (secret) key is known, it shouldn't be too difficult to incorporate the decoder directly in the Capablanca executable instead of running it in an external buggy process.

[hgm]

Indeed, the decrypting is quite easy. But as I am traveling with only my laptop with the broken VM on it, I have no ftp or ssh access to winboard.nl, and there really isn't anything I can do before I get back home.

[Joost Buijs]

Understandable, we just have to wait until you have some time for it.

[hgm]

Well, I am back home now, so I have again access to the winboard.nl server.

But for reasons I don't fathom I seem utterly incapable of making any changes in the ICS. That is, I can change the source code, rebuild through 'make', verify that the changed .c file indeed compiled without errors and produced a .o file, verify that the chessd executable and chessd.so library have the new 'last modified' date, and then restart those. But that never seems to change what the ICS does. If I add printf statements, nothing gets printed. If I change messages it does print (which, according to 'grep', occur only once in the code), it continues printing the old messages which no longer occur in the code at all.

[Sven]

Then the ICS does not use your chessd executable? Different path names perhaps? Or ICS restart required?

Or a "make install"?

[flok]

Well, I am back home now, so I have again access to the winboard.nl server.

But for reasons I don't fathom I seem utterly incapable of making any changes in the ICS. That is, I can change the source code, rebuild through 'make', verify that the changed .c file indeed compiled without errors and produced a .o file, verify that the chessd executable and chessd.so library have the new 'last modified' date, and then restart those. But that never seems to change what the ICS does. If I add printf statements, nothing gets printed. If I change messages it does print (which, according to 'grep', occur only once in the code), it continues printing the old messages which no longer occur in the code at all.

compare the output of
which chessd
with where you expected it is to be

oh and did you do make install?

[jdart]

If modifying the library you can also use ldd on the executable to verify where its dependencies are loaded from. If it is not loading the correct .so you can set LD_LIBRARY_PATH to the correct location.

--Jon

[hgm]

OK, the problem was indeed that the .so file was not sought in the expected (by me) location, although there was one in the expected location (which I then naively replaced).

Unfortunately the decrypting is not as easy as I thought. It is easy to decrypt what openseal produces, because it restarts the encryption process for every new line. Unfortunately it appears the 'official' timeseal does not do that, and seems to encrypt lines in a way that depends on how the previous line was encrypted. In particular, it does not use the encryption key starting at the beginning, but starts somewhere in the middle of it.

The official decoder must thus be smarter than a decpder that just inverts what openseal does: it must know where to start using the key for each new line it receives, rather than just start at the beginning. That it nevertheless is able to decode what openseal produces means that the encryption must have some way to explicitly 'reset' the key, forcing the decryption to start using it from the beginning.

So it seems there are two options: either program the ICS to decrypt what openseal produces (which is trivial), and accepting that the official timeseal (which most people have) can no longer be used to connect to it. Or figure out how exactly the official timeseal encrypts things, and let the ICS invert that.

Code: Select all

Mon Aug  6, 14:56 CEST 2018 received: 72,75,60,6c,71,a1,a9,87,88,82,92,a8,a1,77,b0,af,b1,a1,ac,a1,71,73,6e,66,ca,60,6c,6c,64,65,a1,63,78,a1,89,64,63,a2,9b,be,ce,df,cb,b2,95,7d,64,bb,84,0a,
Mon Aug  6, 14:56 CEST 2018 XOR-ed:  F|mib5(JXTfq7}o!3#&rckvd,n}%	fzbs;
on Aug  6, 14:56 CEST 2018 decoded: |iJ5(bXmF&T3fo7}q!fr%knd,v}c	:bZ;9
Mon Aug  6, 14:56 CEST 2018 command: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Mon Aug  6, 14:56 CEST 2018 Command not found [aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]
Mon Aug  6, 14:56 CEST 2018 command: ping_687254276
Mon Aug  6, 14:56 CEST 2018 Command not found [ping_687254276]
Mon Aug  6, 14:56 CEST 2018 received: 87,92,81,8d,8d,85,84,c0,82,99,c0,68,85,8e,92,89,8b,c0,67,92,81,8d,ce,74,89,8d,85,93,94,81,8d,90,c0,c8,66,69,82,73,7f,98,a3,63,7b,62,78,cd,99,90,9b,0a,
RHNlma  6, 14:56 CEST 2018 XOR-ed:  s[LH^QE
QE^RLHs4m6, 14:56 CEST 2018 decoded: N[H
Mon Aug  6, 14:56 CEST 2018 command: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Above is some debug output from the server, showing what it receives (as a list of hex codes, where the trailing 0a (=LF) was actually appended by me), my miserably failing attempts to decode it with the inverted openseal algorithm, and what the official (closed-source) decoder makes of it. (Which is indeed what I typed in the client.) By feeding it a long string of @ (ascii code 0x40) it becomes relatively easy to reconstruct the key with which it was XOR-er, as the preceding permutation of the message have no effect when all characters are equal. From this I concluded that the key used to encrypt the string of @ was

"grammed by Henrik Gram.Timestamp (FI"

while in case of encrypting by openseal it should have been

"Timestamp (FICS) v1.0 - programmed by Henrik Gram."

Assuming the key simply wraps, I should be able to derive what exactly was appended to the string of @ before the encryption.

[Joost Buijs]

There is an article from the people who reverse engineered it, I didn't read it, maybe it contains some useful info, probably you already read it.

https://eprint.iacr.org/2004/203.pdf

After the heatwave when the temperature on my attic goes to normal, I will also take a look at it, maybe it is possible to disassemble or decompile it with IDA-Pro.

Edit: After reading the article they seem to talk about ICC and not FICS (time-seal?).