Reverse engineering drivers

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Reverse engineering drivers

armedblowfish
I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
binary-only drivers that OpenBSD does not yet have and no one is working on,
and if so, which ones are they?

If so, would it be perfectly legal to reverse assemble them and use that as
a guideline for writing C code to eventually distribute with OpenBSD?

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Nick Guenther
On 5/1/06, [hidden email] <[hidden email]> wrote:
> I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
> binary-only drivers that OpenBSD does not yet have and no one is working on,
> and if so, which ones are they?
>
> If so, would it be perfectly legal to reverse assemble them and use that as
> a guideline for writing C code to eventually distribute with OpenBSD?
>
> Thanks!
>

From what I know you can't do that. What you can do is prod it from
the outside and write down what it does, and then mimic that, but
reading it's code and using that could be like plagarising; even when
porting from GNU projects you have to do a 'clean room' set up--with
one group writing down the internals of the driver and the other
taking the specs and redoing it from scratch--to be sure. I don't know
if assembly counts as source code in this sense though.

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
On 4/30/06, [hidden email] <[hidden email]> wrote:

> On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
> > binary-only drivers that OpenBSD does not yet have and no one is working on,
> > and if so, which ones are they?
> >
> > If so, would it be perfectly legal to reverse assemble them and use that as
> > a guideline for writing C code to eventually distribute with OpenBSD?
> >
> > Thanks!
> >
>
> From what I know you can't do that. What you can do is prod it from
> the outside and write down what it does, and then mimic that, but
> reading it's code and using that could be like plagarising; even when
> porting from GNU projects you have to do a 'clean room' set up--with
> one group writing down the internals of the driver and the other
> taking the specs and redoing it from scratch--to be sure. I don't know
> if assembly counts as source code in this sense though.
>
> -Nick
>

Assembly and binary generally have a 1-to-1 conversion ratio. So
assembly is just binary converted into a slightly more human-readable
form. And when you convert binary into assembly, you don't get
comments or even variable names to help you figure out what is going
on. Maybe you are right about the Linux ones, but wouldn't at least
the FreeBSD drivers be liscenced in a BSD way?

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
In reply to this post by Nick Guenther
On 4/30/06, [hidden email] <[hidden email]> wrote:

> On 4/30/06, Nick Guenther <[hidden email]> wrote:
> On 5/1/06, [hidden email] <[hidden email]> wrote:
> > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
> > > > binary-only drivers that OpenBSD does not yet have and no one is working on,
> > > > and if so, which ones are they?
> > > >
> > > > If so, would it be perfectly legal to reverse assemble them and use that as
> > > > a guideline for writing C code to eventually distribute with OpenBSD?
> > > >
> > > > Thanks!
> > > >
> > >
> > > From what I know you can't do that. What you can do is prod it from
> > > the outside and write down what it does, and then mimic that, but
> > > reading it's code and using that could be like plagarising; even when
> > > porting from GNU projects you have to do a 'clean room' set up--with
> > > one group writing down the internals of the driver and the other
> > > taking the specs and redoing it from scratch--to be sure. I don't know
> > > if assembly counts as source code in this sense though.
> > >
> > > -Nick
> > >
> >
> > Assembly and binary generally have a 1-to-1 conversion ratio. So
> > assembly is just binary converted into a slightly more human-readable
> > form. And when you convert binary into assembly, you don't get
> > comments or even variable names to help you figure out what is going
> > on. Maybe you are right about the Linux ones, but wouldn't at least
> > the FreeBSD drivers be liscenced in a BSD way?
>
> What are you talking about then? FreeBSD drivers are regularly looked
> over and brought into the OpenBSD tree if the devs like them. I
> suspect you are thinking of the binary blobs that FreeBSD ships. Read
> the article Dave just linked [1] to understand them.
>
> :)
> -Nick
>
> [1] http://www.onlamp.com/lpt/a/6557
>

I mean I want to help OpenBSD by reverse-engineering a binary driver.
But if OpenBSD already has it, or someone is already working on it, or
it could never be reworked into a piece of code that could be legally
distributed under the BSD liscense, then of course it would be
pointless.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Steven Shockley
In reply to this post by armedblowfish
Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Tobias Weingartner-2
In reply to this post by armedblowfish
On Sunday, April 30, [hidden email] wrote:
>
> I mean I want to help OpenBSD by reverse-engineering a binary driver.
> But if OpenBSD already has it, or someone is already working on it, or
> it could never be reworked into a piece of code that could be legally
> distributed under the BSD liscense, then of course it would be
> pointless.

Reverse-engineering and de-compiling/de-assembling are two very
different things.  The de-compile/de-assembly of a stub of code is only
one part of the reverse-engineering portion.  It is usually the easiest
portion.  It does not impart knowledge, and does not let you know why
certain things are done in certain ways.  Knowing what you must do is
not enough, in order to write a reasonable driver, and be able to debug
it later when things go wrong, you also need to know the why.

I'm not going to discourage you..  go to it.  :)

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Nick Guenther
In reply to this post by armedblowfish
On 5/1/06, [hidden email] <[hidden email]> wrote:

> On 4/30/06, [hidden email] <[hidden email]> wrote:
> > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > > I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
> > > > > binary-only drivers that OpenBSD does not yet have and no one is working on,
> > > > > and if so, which ones are they?
> > > > >
> > > > > If so, would it be perfectly legal to reverse assemble them and use that as
> > > > > a guideline for writing C code to eventually distribute with OpenBSD?
> > > > >
> > > > > Thanks!
> > > > >
> > > >
> > > > From what I know you can't do that. What you can do is prod it from
> > > > the outside and write down what it does, and then mimic that, but
> > > > reading it's code and using that could be like plagarising; even when
> > > > porting from GNU projects you have to do a 'clean room' set up--with
> > > > one group writing down the internals of the driver and the other
> > > > taking the specs and redoing it from scratch--to be sure. I don't know
> > > > if assembly counts as source code in this sense though.
> > > >
> > > > -Nick
> > > >
> > >
> > > Assembly and binary generally have a 1-to-1 conversion ratio. So
> > > assembly is just binary converted into a slightly more human-readable
> > > form. And when you convert binary into assembly, you don't get
> > > comments or even variable names to help you figure out what is going
> > > on. Maybe you are right about the Linux ones, but wouldn't at least
> > > the FreeBSD drivers be liscenced in a BSD way?
> >
> > What are you talking about then? FreeBSD drivers are regularly looked
> > over and brought into the OpenBSD tree if the devs like them. I
> > suspect you are thinking of the binary blobs that FreeBSD ships. Read
> > the article Dave just linked [1] to understand them.
> >
> > :)
> > -Nick
> >
> > [1] http://www.onlamp.com/lpt/a/6557
> >
>
> I mean I want to help OpenBSD by reverse-engineering a binary driver.
> But if OpenBSD already has it, or someone is already working on it, or
> it could never be reworked into a piece of code that could be legally
> distributed under the BSD liscense, then of course it would be
> pointless.
>

Well of course you can reverse engineer things. The legality of doing
it depends on how you do it.

-Nick

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
In reply to this post by Tobias Weingartner-2
On 4/30/06, Tobias Weingartner <[hidden email]> wrote:

> On Sunday, April 30, [hidden email] wrote:
> >
> > I mean I want to help OpenBSD by reverse-engineering a binary driver.
> > But if OpenBSD already has it, or someone is already working on it, or
> > it could never be reworked into a piece of code that could be legally
> > distributed under the BSD liscense, then of course it would be
> > pointless.
>
> Reverse-engineering and de-compiling/de-assembling are two very
> different things.  The de-compile/de-assembly of a stub of code is only
> one part of the reverse-engineering portion.  It is usually the easiest
> portion.  It does not impart knowledge, and does not let you know why
> certain things are done in certain ways.  Knowing what you must do is
> not enough, in order to write a reasonable driver, and be able to debug
> it later when things go wrong, you also need to know the why.
>
> I'm not going to discourage you..  go to it.  :)
>
> --Toby.
>

It may not be enough, but it's a start. What driver can I work on that
would be useful/legal/everything?

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
In reply to this post by Nick Guenther
On 4/30/06, Nick Guenther <[hidden email]> wrote:

> On 5/1/06, [hidden email] <[hidden email]> wrote:
> > On 4/30/06, [hidden email] <[hidden email]> wrote:
> > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > > > I was wondering if there are any FreeBSD (or Linux, but preferably BSD)
> > > > > > binary-only drivers that OpenBSD does not yet have and no one is working on,
> > > > > > and if so, which ones are they?
> > > > > >
> > > > > > If so, would it be perfectly legal to reverse assemble them and use that as
> > > > > > a guideline for writing C code to eventually distribute with OpenBSD?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > >
> > > > > From what I know you can't do that. What you can do is prod it from
> > > > > the outside and write down what it does, and then mimic that, but
> > > > > reading it's code and using that could be like plagarising; even when
> > > > > porting from GNU projects you have to do a 'clean room' set up--with
> > > > > one group writing down the internals of the driver and the other
> > > > > taking the specs and redoing it from scratch--to be sure. I don't know
> > > > > if assembly counts as source code in this sense though.
> > > > >
> > > > > -Nick
> > > > >
> > > >
> > > > Assembly and binary generally have a 1-to-1 conversion ratio. So
> > > > assembly is just binary converted into a slightly more human-readable
> > > > form. And when you convert binary into assembly, you don't get
> > > > comments or even variable names to help you figure out what is going
> > > > on. Maybe you are right about the Linux ones, but wouldn't at least
> > > > the FreeBSD drivers be liscenced in a BSD way?
> > >
> > > What are you talking about then? FreeBSD drivers are regularly looked
> > > over and brought into the OpenBSD tree if the devs like them. I
> > > suspect you are thinking of the binary blobs that FreeBSD ships. Read
> > > the article Dave just linked [1] to understand them.
> > >
> > > :)
> > > -Nick
> > >
> > > [1] http://www.onlamp.com/lpt/a/6557
> > >
> >
> > I mean I want to help OpenBSD by reverse-engineering a binary driver.
> > But if OpenBSD already has it, or someone is already working on it, or
> > it could never be reworked into a piece of code that could be legally
> > distributed under the BSD liscense, then of course it would be
> > pointless.
> >
>
> Well of course you can reverse engineer things. The legality of doing
> it depends on how you do it.
>
> -Nick

The methodology would be reverse assembling the binary and rewriting
that in C, which may not be permitted by some licenses. Because I do
not have the hardware and have no experience writing drivers from
scratch anyways.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Tobias Weingartner-2
In reply to this post by armedblowfish
On Sunday, April 30, [hidden email] wrote:
>
> It may not be enough, but it's a start. What driver can I work on that
> would be useful/legal/everything?

Ugh... I would say that depends entirely on where your interests lie.

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Tobias Weingartner-2
In reply to this post by armedblowfish
On Sunday, April 30, [hidden email] wrote:
>
> The methodology would be reverse assembling the binary and rewriting
> that in C, which may not be permitted by some licenses. Because I do
> not have the hardware and have no experience writing drivers from
> scratch anyways.

You're cutting yourself a large chunk.  You may wish to start with
something smaller, a driver that is present in netbsd and/or freebsd,
and not in openbsd, but has documentation.  Personally I'm not aware
of any, but I'm sure there must be some.

At least that will get you practice writing device drivers, documented
drivers.  :)

--Toby.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
In reply to this post by Tobias Weingartner-2
Well, I'm new at this, so something relatively simple would probably
be good, but I'm not picky....

On 5/1/06, Tobias Weingartner <[hidden email]> wrote:
> On Sunday, April 30, [hidden email] wrote:
> >
> > It may not be enough, but it's a start. What driver can I work on that
> > would be useful/legal/everything?
>
> Ugh... I would say that depends entirely on where your interests lie.
>
> --Toby.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
In reply to this post by Tobias Weingartner-2
On 5/1/06, Tobias Weingartner <[hidden email]> wrote:

> On Sunday, April 30, [hidden email] wrote:
> >
> > The methodology would be reverse assembling the binary and rewriting
> > that in C, which may not be permitted by some licenses. Because I do
> > not have the hardware and have no experience writing drivers from
> > scratch anyways.
>
> You're cutting yourself a large chunk.  You may wish to start with
> something smaller, a driver that is present in netbsd and/or freebsd,
> and not in openbsd, but has documentation.  Personally I'm not aware
> of any, but I'm sure there must be some.
>
> At least that will get you practice writing device drivers, documented
> drivers.  :)
>
> --Toby.
>

Maybe. On the other hand, while I don't really know much about
drivers, at least I know some C and assembly.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

armedblowfish
On 5/1/06, Bram Dumolin <[hidden email]> wrote:
> Maybe some webcam drivers might be a good idea?
> Like the quickcam or spca drivers?
>
> Probably too big for starters.
>
> --
> Bram Dumolin

Thanks for the suggestions.

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Helio Leonardo Mota
In reply to this post by Nick Guenther
On Monday 01 May 2006 00:20, Nick Guenther wrote:

> On 5/1/06, [hidden email] <[hidden email]> wrote:
> > On 4/30/06, [hidden email] <[hidden email]> wrote:
> > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > >
> > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > > > I was wondering if there are any FreeBSD (or Linux, but
> > > > > > preferably BSD) binary-only drivers that OpenBSD does not yet
> > > > > > have and no one is working on, and if so, which ones are they?
> > > > > >
> > > > > > If so, would it be perfectly legal to reverse assemble them and
> > > > > > use that as a guideline for writing C code to eventually
> > > > > > distribute with OpenBSD?
> > > > > >
> > > > > > Thanks!
> > > > >
> > > > > From what I know you can't do that. What you can do is prod it from
> > > > > the outside and write down what it does, and then mimic that, but
> > > > > reading it's code and using that could be like plagarising; even
> > > > > when porting from GNU projects you have to do a 'clean room' set
> > > > > up--with one group writing down the internals of the driver and the
> > > > > other taking the specs and redoing it from scratch--to be sure. I
> > > > > don't know if assembly counts as source code in this sense though.
> > > > >
> > > > > -Nick
> > > >
> > > > Assembly and binary generally have a 1-to-1 conversion ratio. So
> > > > assembly is just binary converted into a slightly more human-readable
> > > > form. And when you convert binary into assembly, you don't get
> > > > comments or even variable names to help you figure out what is going
> > > > on. Maybe you are right about the Linux ones, but wouldn't at least
> > > > the FreeBSD drivers be liscenced in a BSD way?
> > >
> > > What are you talking about then? FreeBSD drivers are regularly looked
> > > over and brought into the OpenBSD tree if the devs like them. I
> > > suspect you are thinking of the binary blobs that FreeBSD ships. Read
> > > the article Dave just linked [1] to understand them.
> > >
> > > :)
> > >
> > > -Nick
> > >
> > > [1] http://www.onlamp.com/lpt/a/6557
> >
> > I mean I want to help OpenBSD by reverse-engineering a binary driver.
> > But if OpenBSD already has it, or someone is already working on it, or
> > it could never be reworked into a piece of code that could be legally
> > distributed under the BSD liscense, then of course it would be
> > pointless.
>
> Well of course you can reverse engineer things. The legality of doing
> it depends on how you do it.
>
> -Nick
Greetings gentlemen,

        Reverse engineering is a quite a controversial subject, one can easily draw a
parallel line betweeing RE and some other polemical arguments like illegal
drugs legalization and censorship policy which might diminishes a citzen
feeling of freedom. At a technical level, no enormous effort is necessary to
understand the nuts and bolts of a certain piece of software either with a
black-box methodology, and at some cases, disassembling code. The problem,
imho, lives not within the boundaries of techinques and methodologies,
instead, it falls into a quite political, legal and ethical scope. Ianal, but
doing some superficial research one can come up with this:

http://www.google.com/search?q=ethics+reverse+engineering

        It is important to have in mind, the map of the territory -- and creatures :)
-- you might be encontering when engaging on your quest, in plain common
sense fellowship advice, be careful, so you will not be surprised by drifts
from outside the challenge you're expecting to face.
 
hth,
hlm

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

Helio Leonardo Mota
In reply to this post by Nick Guenther
On Monday 01 May 2006 00:20, Nick Guenther wrote:

> On 5/1/06, [hidden email] <[hidden email]> wrote:
> > On 4/30/06, [hidden email] <[hidden email]> wrote:
> > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > >
> > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > On 4/30/06, Nick Guenther <[hidden email]> wrote:
> > > > > On 5/1/06, [hidden email] <[hidden email]> wrote:
> > > > > > I was wondering if there are any FreeBSD (or Linux, but
> > > > > > preferably BSD) binary-only drivers that OpenBSD does not yet
> > > > > > have and no one is working on, and if so, which ones are they?
> > > > > >
> > > > > > If so, would it be perfectly legal to reverse assemble them and
> > > > > > use that as a guideline for writing C code to eventually
> > > > > > distribute with OpenBSD?
> > > > > >
> > > > > > Thanks!
> > > > >
> > > > > From what I know you can't do that. What you can do is prod it from
> > > > > the outside and write down what it does, and then mimic that, but
> > > > > reading it's code and using that could be like plagarising; even
> > > > > when porting from GNU projects you have to do a 'clean room' set
> > > > > up--with one group writing down the internals of the driver and the
> > > > > other taking the specs and redoing it from scratch--to be sure. I
> > > > > don't know if assembly counts as source code in this sense though.
> > > > >
> > > > > -Nick
> > > >
> > > > Assembly and binary generally have a 1-to-1 conversion ratio. So
> > > > assembly is just binary converted into a slightly more human-readable
> > > > form. And when you convert binary into assembly, you don't get
> > > > comments or even variable names to help you figure out what is going
> > > > on. Maybe you are right about the Linux ones, but wouldn't at least
> > > > the FreeBSD drivers be liscenced in a BSD way?
> > >
> > > What are you talking about then? FreeBSD drivers are regularly looked
> > > over and brought into the OpenBSD tree if the devs like them. I
> > > suspect you are thinking of the binary blobs that FreeBSD ships. Read
> > > the article Dave just linked [1] to understand them.
> > >
> > > :)
> > >
> > > -Nick
> > >
> > > [1] http://www.onlamp.com/lpt/a/6557
> >
> > I mean I want to help OpenBSD by reverse-engineering a binary driver.
> > But if OpenBSD already has it, or someone is already working on it, or
> > it could never be reworked into a piece of code that could be legally
> > distributed under the BSD liscense, then of course it would be
> > pointless.
>
> Well of course you can reverse engineer things. The legality of doing
> it depends on how you do it.
>
> -Nick
Greetings gentlemen,

        Reverse engineering is a quite a controversial subject, one can easily draw a
parallel line betweeing RE and some other polemical arguments like illegal
drugs legalization and censorship policy which might diminishes a citzen
feeling of freedom. At a technical level, no enormous effort is necessary to
understand the nuts and bolts of a certain piece of software either with a
black-box methodology, and eventually, disassembling methodology. The problem,
imho, lives not within the boundaries of techinques and methodologies,
instead, it falls into a quite political, legal and ethical scope. Ianal, but
doing some superficial research one can come up with this:

http://www.google.com/search?q=ethics+reverse+engineering

        Also, it is important to have in mind, the map of the territory -- and
creatures :) -- you might be encountering when engaging on your quest. In a
plain common sense fellowship advice, be careful, so you will not be
surprised by drifts from outside the challenge you're expecting to face.
 
hth,
hlm

Reply | Threaded
Open this post in threaded view
|

Re: Reverse engineering drivers

L. V. Lammert
In reply to this post by Tobias Weingartner-2
On Sun, 30 Apr 2006, Tobias Weingartner wrote:

> On Sunday, April 30, [hidden email] wrote:
> >
> > It may not be enough, but it's a start. What driver can I work on that
> > would be useful/legal/everything?
>
> Ugh... I would say that depends entirely on where your interests lie.
>
> --Toby.
>
More imprtantly, .. a driver for wich you have test hardware.

        Lee

================================================
  Leland V. Lammert            [hidden email]
    Chief Scientist     Omnitec Corporation
 Network/Internet Consultants   www.omnitec.net
================================================