Rybka 1.0 source code

[mar]

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.

AFAIK hexrays is still very buggy and doesn't produce good code at all. To be usable we still have to wait for some time. It sometimes produces code that won't even work, not mentioning that there's a lot missing from the "source", like tables etc. It can give a hint but I think that disassembly is still invetiable. Perhaps using both. Btw. I wonder why everyone is so excited about it. Hexrays is out for a pretty long time already...

Martin

[bob]

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.

AFAIK hexrays is still very buggy and doesn't produce good code at all. To be usable we still have to wait for some time. It sometimes produces code that won't even work, not mentioning that there's a lot missing from the "source", like tables etc. It can give a hint but I think that disassembly is still invetiable. Perhaps using both. Btw. I wonder why everyone is so excited about it. Hexrays is out for a pretty long time already...

Martin

Good question. For months, Ed and Chris said "disassembly can't be done". I suppose he "hopes" that something inside will help, since all the ASM code is highly damaging at the moment...

This will not help a bit since it most likely tracks the asm quite precisely, since it is a commercial product. I just can't bear to read through the nonsense and find the asm much easier to understand, particularly when one adds comments to help.

[bob]

...
The Java decompilers produce such a readable code I don't feel the need to store source code of my java projects anymore (the jar file will do).

I disagree. Java decompilers so far are (sometimes) unable to

1, decipher actual type from base type on method's arguments
2, correctly resolve local variables
3, correctly handle exceptions and finally clauses.

Even worse, sometimes they produce syntactically correct (i.e. compilable) code but semantically wrong code
(e.g. erroneous loops reconstruction when facing an irreducible control flow graph or even missing static initializations).

This is so for the venerable jad, jd, fernflower and the academic dava.

Furthermore, no one has been updated to Java7

I agree with you. If someone can use a de-compiler to recover source that is usable, the code is quite simple. Nothing like the largish projects I have worked on. The Rybka "source" is an example. Not even complete (errors reported during the decompilation process) and nearly impossible to read without having a pencil and paper type analysis done first...

[Alexander Schmidt]

Your text translated to german and back to english with babelfish. Completely different, still just a stolen copy

Assistance witch jets more decompiler you can download the C-Quellencode of Rybka 1,0, the beta are and now with the calm code of source of fruit, decide the Rybka source code right, what it were copied and which not. Witch jets more decompiler caused that surprisingly wohlen readable code, which is extracted indeed by the enforceable Rybka 1,0 or every other enforceable. Without much doubt it explains also, how the Rybka 3 Häcker came manufactured Ippolit as the original Ippolit source code into a long C-file, which was more decompiler manufactured by witch jets, as the source code of Rybka, which comes 1,0 beta offered on this side as long C-code a document. It confirms, what many, which are considered already, parts of the Ippolit source code, are indeed computer-produced and witch jets more decompiler exactly does. The bad messages are that any program can become the goal of the Häcker. I received decompiled versions from Hiarcs, from Rybka 4 and from others. Nobody is safe somehow longer. Since publishing the apart-built work of others, by European Union law one forbids, which I asked Vas for permission for publishing the Rybka 1,0 sources and he did not hesitate for one moment. Downloadverbindung on: http://www.top-5000.nl/sourcecode.htm OD

[Rebel]

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. It confirms what many already noticed, parts of the Ippolit source code are computer generated and indeed the Hex-rays decompiler does exactly that.

Update: I removed that sentence, it's worded too strong. A comparison between Ippo and Rybka 3 basic endgame knowledge showed too much fundamental differences. Besides, mentioning Ippo is a byroad and a subject of its own not related to the intention of the page to offer the decompiled Rybka 1 source code.

http://www.top-5000.nl/sourcecode.htm

[Rebel]

Good question. For months, Ed and Chris said "disassembly can't be done". I suppose he "hopes" that something inside will help, since all the ASM code is highly damaging at the moment...

Produce that sentence please.

What I have said is that reverse engineering is open to the wished result. And that happened. An undeniable fact. And we have given it a name, fruitification, inventing CODE that is not in RYBKA1.EXE making Rybka more fruity.

The Hex-rays decompiler produces source code without fruitification, without wishful thinking, without tunnel visions.

[bob]

Good question. For months, Ed and Chris said "disassembly can't be done". I suppose he "hopes" that something inside will help, since all the ASM code is highly damaging at the moment...

Produce that sentence please.

What I have said is that reverse engineering is open to the wished result. And that happened. An undeniable fact. And we have given it a name, fruitification, inventing CODE that is not in RYBKA1.EXE making Rybka more fruity.

The Hex-rays decompiler produces source code without fruitification, without wishful thinking, without tunnel visions.

Absolutely NO code that was not in Rybka 1.0 beta executable was produced. We took the asm code from that executable and proved that it was sematically equivalent to the Fruit 2.1 code, differing only in the chess board representation. If Hex-Rays allowed for a "matching template" type approach, it, too would be labelled a "fruitification generation" by you I am sure...

You say our de-compilation is no good. You claim yours DOES show something. That is a simple contradiction that most will recognize...

[Rebel]

Good question. For months, Ed and Chris said "disassembly can't be done".

I won't start a new R/F discussion with you, instead I like to thank you for your silent apology of that false accusation you made.

[bob]

Good question. For months, Ed and Chris said "disassembly can't be done".

I won't start a new R/F discussion with you, instead I like to thank you for your silent apology of that false accusation you made.

What "silent apology?" So many posts over there I may have missed something. Not that it is terribly important...

[wims]

...
Would be fun to take something known, compile it and then decompile it, to see how close it looks...

I once did that here at ccc and proved that totally different source code could decompile into identical code. You laughed at it.