Decompiler Project and Mailing List

Decompiler Project and Mailing List

[Lynn Winebarger]

   Please note I'm crossposting this announcement to the developers' lists
I think contain the people most likely to be interested in this project.

   My little decompiler project (a sub-project of the Free Expression
Project) now has a mailing list, decompiler@free-expression.org.
Subscribe by mailing to majordomo@free-expression.org a message containing
the line:
subscribe decompiler

   I also have put the current code in my CVS repository, which you can
reach with
cvs -d :pserver:guest@se232.math.indiana.edu:/usr/local/cvsroot login
password is "freeguest", and you just need to checkout the decompiler
directory.

   The current state of the code is that I can translate a i386 executable
into a Scheme representation (tagged lists, mainly because it was easy to
implement and guaranteed to be portable to any scheme you want - I'm using
GUILE) of its symbols, data, and disassembled code (using the objdump code
as a base for the disassembling logic).  Then I have a converter from i386
assembler to an RTL like representation (main difference - machine modes
are replaced with a more precise typing system), which works for a
reasonable subset of i386 assembly (integer math, control flow, regular
bitwise operations - basically no floating point/MMX/SIMD conversion).

    I'm now working on an abstract interpreter to build a control flow
graph (allowing for bizarre jumps between function contexts), derived from
the compiler theory used for functional languages, since they have the
same problem as assembler that code is easily treated as data.  After
that, there will be loop detection, and any goto's that are left will be
translated into a letrec structure (where tail-recursion optimization is 
assumed) and then an attempt to "de-tailize" them will be made.  Also,
stack frames won't be explicitly recognized by the analysis, instead
frames will be treated as a structure passed to function through the bp
register.  I hope (assuming this works) that putting in place this general
kind of analysis will allow the detection of explicit stack constructs
(for example, look at the bison.simple parser) without any extra work.

Lynn

PS My apologies to those who've read this before.

Re: Decompiler Project and Mailing List

[Joe Buck]

>    Please note I'm crossposting this announcement to the developers' lists
> I think contain the people most likely to be interested in this project.
> 
>    My little decompiler project (a sub-project of the Free Expression
> Project) now has a mailing list, decompiler@free-expression.org.
> Subscribe by mailing to majordomo@free-expression.org a message containing
> the line:
> subscribe decompiler

While a decompiler is certainly a useful tool, producing copylefted
streaming tools by reverse-engineering proprietary codecs, as the
free-expression.org website advocates, is the wrong approach.  The problem
is patents; you can't use a patented technique without licensing the
patent, or you put yourself at considerable financial risk.

Furthermore, you can hardly later claim accidental infringement when the
big boys come with their lawyers when you've made clear that you've
obtained your tools by reverse engineering.

The only way to produce free streaming media is to use algorithms not
covered by patents.  This is a difficult job, but far from impossible.
Alternatively, all development could be done in countries that don't
legally honor software patents, but the result would be tools that
people in the US and a number of other countries cannot legally use.

Now that the free software movement has companies in its camp with
billions of dollars of market capitalization, it should hopefully be
possible to get enough funding and support to do this right.  Get some
EE grad student volunteers to help with algorithms, get some legal
assistance (paid or unpaid) to do patent searches.

Re: Decompiler Project and Mailing List

[Lynn Winebarger]

   My apologies to the lists for an unwanted thread.  I don't know which
list Joe is reading from, or I'd winnow the cc: list.  Unfortunately, I
can't let this pass without comment.

On Wed, 17 Nov 1999, Joe Buck wrote:
> 
> While a decompiler is certainly a useful tool, producing copylefted
> streaming tools by reverse-engineering proprietary codecs, as the
> free-expression.org website advocates, is the wrong approach.  The problem
> is patents; you can't use a patented technique without licensing the
> patent, or you put yourself at considerable financial risk.
> 
> Furthermore, you can hardly later claim accidental infringement when the
> big boys come with their lawyers when you've made clear that you've
> obtained your tools by reverse engineering.
> 
    You are correct that there will likely be a lawsuit.  However, I think
you would be assuming too much if you think a software patent holder will
necessarily when.  The argument is on 2 grounds: (1) there is a conflict
between patent law and the 1st amendment when it prevents me from
expressing ideas in computer languages (see the Bernstein case), and (2)
restraining free software (GNU sense, not zero-cost) in favor of patents
might not serve the public interest in the way that the constitutional
clause granting Congress the power to establish patents demands (i.e. to
advance the useful arts and sciences).  
     While the idea of a prolonged legal battle is not my idea of a good
time, the idea that I should give up my civil liberties to write (in
whatever language I want, and whatever type of ideas I want) and help
others with that writing just so some companies can turn a profit is
a lot worse.

> The only way to produce free streaming media is to use algorithms not
> covered by patents.  This is a difficult job, but far from impossible.
> Alternatively, all development could be done in countries that don't
> legally honor software patents, but the result would be tools that
> people in the US and a number of other countries cannot legally use.
> 
     This will be done as well.  Actually, it's much more interesting than
the reverse engineering parts (well, writing a decompiler is a very
interesting problem itself), which I'm mainly doing because of the large
amount of content that people already have in these proprietary formats.

Lynn

Re: Decompiler Project and Mailing List

[Joe Buck]

>    My apologies to the lists for an unwanted thread.  I don't know which
> list Joe is reading from, or I'd winnow the cc: list.  Unfortunately, I
> can't let this pass without comment.

I've answered Lynn in detail by private mail, since the topic isn't
relevant to these mailing lists.  Summary: if anyone wants to put every
asset they own at legal risk to challenge software patents for the sake of
principle, I can respect that, but I'd recommend avoiding it if possible.
In the past, GNU project policy as I understand it has been to work around
patents by producing better free algorithms (e.g. gzip vs. compress) and
to get volunteers to do certain tasks (e.g. reverse engineering) in
countries where it is clearly legal.