Rybka 1.0 source code

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 4:27 pm

Re: Rybka 1.0 source code

Post by Don »

rvida wrote:
Rebel wrote: Without much doubt it also explains how the Rybka 3 hackers created Ippolit as the original Ippolit source code came in one long C-file created by the Hex-rays decompiler, like the source code of Rybka 1.0 Beta offered on this page comes as one long C-code file.
lol, really "scientific" reasoning :roll:

If program XX is single long C-file, and hexrays produces one long C-file => conclusion: program XX was for sure produced by hexrays... Sure there is no other way to have a long C-file...

copy *.c bigfile.c
regards
When I first saw that single long file for ippolit, it was pretty obvious that much of it was computer generated. It was really bizarre looking and I had never seen code written like that before.

I found the piece square table code which is generated by the program and inserted some print statements to display them. I called Larry and we compared them to Rybka, which he had access to. The tables were very nearly identical - he had several versions to compare against and tried to find a version that was 100% identical but we found ones that had only 1 or 2 squares with different values in them. It was proof to us that at least the piece square tables were copied from Rybka. There was also huge similarities in the search style which was much different from any other program at the time. None of this was absolute proof of anything that you could put together as a scientific proof (without a lot of work) but it is like seeing someone you know quite well and recognizing them - you cannot in a court of law explain how you know it's them but you just do and it cannot be scientifically "measured" or explained how you know it's them, you just know them.

I know that some programmers write their programs as one long source file, presumably because it will compile slightly better or at least they think it will. Komodo consists of 11 different source files not counting the .h files that go with that.

When I wrote the Khet program I decided to try that - and it was to be a reference implementation anyway even though it ended up being more than that. I was pleasantly surprised that it's fine to write a program that way - especially since it was not very long - being only about 2500 lines of code even counting blank lines and such.

After a few months the ippolit code started appearing in different formats, version translated to use english names and code being separated in separate source files and so on.
User avatar
JuLieN
Posts: 2949
Joined: Mon May 05, 2008 12:16 pm
Location: Bordeaux (France)
Full name: Julien Marcel

Re: Rybka 1.0 source code

Post by JuLieN »

Don wrote: I know that some programmers write their programs as one long source file, presumably because it will compile slightly better or at least they think it will. Komodo consists of 11 different source files not counting the .h files that go with that.
My engine is a 4000+ lines single pascal source file, because I find it easier to use: I know at which line number I can find which function (besides most of them are sorted alphabetically), plus it's easier for me to launch a search in a single file.

I guess that both ways have their pros and cons. And maybe if it was a 30000+ lines program I would have to cut it into several source files...
"The only good bug is a dead bug." (Don Dailey)
[Blog: http://tinyurl.com/predateur ] [Facebook: http://tinyurl.com/fbpredateur ] [MacEngines: http://tinyurl.com/macengines ]
Terry McCracken
Posts: 16465
Joined: Wed Aug 01, 2007 4:16 am
Location: Canada

Re: Rybka 1.0 source code

Post by Terry McCracken »

bob wrote:
Terry McCracken wrote:Nope, no one is safe anymore. This problem could have been averted if the computer chess community hadn't been asleep and caught with their pawns down.
I don't think it is a matter of "sleeping" or "getting caught". This has been inevitable for many years. And has been possible for a few years...
It was inevitable that someone would try and when someone did, it was ignored until they gave critical information away.

Maybe it couldn't have been stopped but it could have been handled better and faster, before it became a nightmare.

Had Rybka been dealt with earlier and more quickly then the Ippo/Robbo monstrosity would have never evolved.

Maybe it's too involved and complex now to just close the box?
Terry McCracken
User avatar
Rebel
Posts: 6995
Joined: Thu Aug 18, 2011 12:04 pm

Re: Rybka 1.0 source code

Post by Rebel »

rvida wrote:
Rebel wrote: Without much doubt it also explains how the Rybka 3 hackers created Ippolit as the original Ippolit source code came in one long C-file created by the Hex-rays decompiler, like the source code of Rybka 1.0 Beta offered on this page comes as one long C-code file.
lol, really "scientific" reasoning :roll:

If program XX is single long C-file, and hexrays produces one long C-file => conclusion: program XX was for sure produced by hexrays... Sure there is no other way to have a long C-file...

copy *.c bigfile.c
regards
You conveniently snipped: It confirms what many already noticed, parts of the Ippolit source code are computer generated and indeed the Hex-rays decompiler does exactly that.

The page is not meant to bore people with Ippolit's computer generated (not typed) code, such as:

Code: Select all

static const SINT32 passed_pawn_dry_value[8] = {
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;10&#41; << 16&#41; + &#40;10&#41;), ((&#40;20&#41; << 16&#41; + &#40;25&#41;), ((&#40;40&#41; << 16&#41; + &#40;50&#41;), ((&#40;60&#41; << 16&#41; + &#40;75&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
static const SINT32 passed_pawn_outside_value&#91;8&#93; = &#123;
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;2&#41; << 16&#41; + &#40;5&#41;), ((&#40;5&#41; << 16&#41; + &#40;10&#41;), ((&#40;10&#41; << 16&#41; + &#40;20&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
static const SINT32 passed_pawn_protected_value&#91;8&#93; = &#123;
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;5&#41; << 16&#41; + &#40;10&#41;), ((&#40;10&#41; << 16&#41; + &#40;15&#41;), ((&#40;15&#41; << 16&#41; + &#40;25&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
etc.
User avatar
Rebel
Posts: 6995
Joined: Thu Aug 18, 2011 12:04 pm

Re: Rybka 1.0 source code

Post by Rebel »

Don wrote:
rvida wrote:
Rebel wrote: Without much doubt it also explains how the Rybka 3 hackers created Ippolit as the original Ippolit source code came in one long C-file created by the Hex-rays decompiler, like the source code of Rybka 1.0 Beta offered on this page comes as one long C-code file.
lol, really "scientific" reasoning :roll:

If program XX is single long C-file, and hexrays produces one long C-file => conclusion: program XX was for sure produced by hexrays... Sure there is no other way to have a long C-file...

copy *.c bigfile.c
regards
When I first saw that single long file for ippolit, it was pretty obvious that much of it was computer generated. It was really bizarre looking and I had never seen code written like that before.
Precisely.
User avatar
rvida
Posts: 481
Joined: Thu Apr 16, 2009 12:00 pm
Location: Slovakia, EU

Re: Rybka 1.0 source code

Post by rvida »

Rebel wrote:
rvida wrote:
Rebel wrote: Without much doubt it also explains how the Rybka 3 hackers created Ippolit as the original Ippolit source code came in one long C-file created by the Hex-rays decompiler, like the source code of Rybka 1.0 Beta offered on this page comes as one long C-code file.
lol, really "scientific" reasoning :roll:

If program XX is single long C-file, and hexrays produces one long C-file => conclusion: program XX was for sure produced by hexrays... Sure there is no other way to have a long C-file...

copy *.c bigfile.c
regards
You conveniently snipped: It confirms what many already noticed, parts of the Ippolit source code are computer generated and indeed the Hex-rays decompiler does exactly that.

The page is not meant to bore people with Ippolit's computer generated (not typed) code, such as:

Code: Select all

static const SINT32 passed_pawn_dry_value&#91;8&#93; = &#123;
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;10&#41; << 16&#41; + &#40;10&#41;), ((&#40;20&#41; << 16&#41; + &#40;25&#41;), ((&#40;40&#41; << 16&#41; + &#40;50&#41;), ((&#40;60&#41; << 16&#41; + &#40;75&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
static const SINT32 passed_pawn_outside_value&#91;8&#93; = &#123;
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;2&#41; << 16&#41; + &#40;5&#41;), ((&#40;5&#41; << 16&#41; + &#40;10&#41;), ((&#40;10&#41; << 16&#41; + &#40;20&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
static const SINT32 passed_pawn_protected_value&#91;8&#93; = &#123;
  ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;), ((&#40;5&#41; << 16&#41; + &#40;10&#41;), ((&#40;10&#41; << 16&#41; + &#40;15&#41;), ((&#40;15&#41; << 16&#41; + &#40;25&#41;), ((&#40;0&#41; << 16&#41; + &#40;0&#41;)
&#125;;
etc.
The code above was 100% not produced by hexrays. It looks more like a macro expansion.
ernest
Posts: 2041
Joined: Wed Mar 08, 2006 8:30 pm

Re: Rybka 1.0 source code

Post by ernest »

bob wrote:Would be fun to take something known, compile it and then decompile it, to see how close it looks...
Why not Fruit 2.1?...
mjlef
Posts: 1494
Joined: Thu Mar 30, 2006 2:08 pm

Re: Rybka 1.0 source code

Post by mjlef »

Terry McCracken wrote:Nope, no one is safe anymore. This problem could have been averted if the computer chess community hadn't been asleep and caught with their pawns down.
I imagine it would be quite uncomfortable to sleep with your pants down.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Rybka 1.0 source code

Post by bob »

ernest wrote:
bob wrote:Would be fun to take something known, compile it and then decompile it, to see how close it looks...
Why not Fruit 2.1?...
Good idea. However, Hexrays is FAR from perfect:

Last line of the "rybka.c source" ed published:

#error "There were 5 decompilation failure(s) on 73 function(s)"

So this is not going to compile and run.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Rybka 1.0 source code

Post by bob »

Don wrote:
rvida wrote:
Rebel wrote: Without much doubt it also explains how the Rybka 3 hackers created Ippolit as the original Ippolit source code came in one long C-file created by the Hex-rays decompiler, like the source code of Rybka 1.0 Beta offered on this page comes as one long C-code file.
lol, really "scientific" reasoning :roll:

If program XX is single long C-file, and hexrays produces one long C-file => conclusion: program XX was for sure produced by hexrays... Sure there is no other way to have a long C-file...

copy *.c bigfile.c
regards
When I first saw that single long file for ippolit, it was pretty obvious that much of it was computer generated. It was really bizarre looking and I had never seen code written like that before.

I found the piece square table code which is generated by the program and inserted some print statements to display them. I called Larry and we compared them to Rybka, which he had access to. The tables were very nearly identical - he had several versions to compare against and tried to find a version that was 100% identical but we found ones that had only 1 or 2 squares with different values in them. It was proof to us that at least the piece square tables were copied from Rybka. There was also huge similarities in the search style which was much different from any other program at the time. None of this was absolute proof of anything that you could put together as a scientific proof (without a lot of work) but it is like seeing someone you know quite well and recognizing them - you cannot in a court of law explain how you know it's them but you just do and it cannot be scientifically "measured" or explained how you know it's them, you just know them.

I know that some programmers write their programs as one long source file, presumably because it will compile slightly better or at least they think it will. Komodo consists of 11 different source files not counting the .h files that go with that.

When I wrote the Khet program I decided to try that - and it was to be a reference implementation anyway even though it ended up being more than that. I was pleasantly surprised that it's fine to write a program that way - especially since it was not very long - being only about 2500 lines of code even counting blank lines and such.

After a few months the ippolit code started appearing in different formats, version translated to use english names and code being separated in separate source files and so on.
There is a simple solution that I use.

crafty.c:

#include "source1.c"
#include "source2.c"
etc...

Then when you compile crafty.c, the preprocessor stuffs it all together so that unrolling and interprocedural optimizations can be done...