Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Reverse Engineering of Windows Distribution

Reply
Thread Tools

Reverse Engineering of Windows Distribution

 
 
Markus Stenzel
Guest
Posts: n/a
 
      07-07-2003
I have a Python software for Windows, packed into a single exe file and
accompanied with a few dll and package files.

Is there any way to reverse engineer this packet by extracting the
source files so they can be used on Linux/Unix? I have checked the exe
but it seems to be compressed by zlib.

Some people on the mailing lists told my friend it's possible to get the
code once you can "unpack" the files from the exe.

Anyone?

Markus

 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      07-07-2003
Markus Stenzel wrote:
>
> I have a Python software for Windows, packed into a single exe file and
> accompanied with a few dll and package files.
>
> Is there any way to reverse engineer this packet by extracting the
> source files so they can be used on Linux/Unix? I have checked the exe
> but it seems to be compressed by zlib.
>
> Some people on the mailing lists told my friend it's possible to get the
> code once you can "unpack" the files from the exe.


It seems likely that the source to this program would be available
to you already, wouldn't it? It *is* open source, right?

If it is, you can probably find the source on the web, or just
contact the author for it.

If it is not, you are probably violating your license agreement in
trying to do this. Did it come with a license?

Technically it is possible, but it's not trivial, and seems like
a pretty bizarre thing to do if the author didn't intend it to
be used on Linux in the first place. (Which we can infer from the
choice of distribution method.)

-Peter
 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      07-07-2003
Markus Stenzel wrote:
>
> Product : Experimental BitTorrent Client (c)Bram Cohen
> Modified: Eike Frost http://ei.kefro.st/projects/btclient/
> License : MIT
> Source : Available (3.1-CVS-4, 3.2-1, 3.2.1b-1, 3.2.1b-2)
>
> The Experimental BitTorrent is a GUI upgrade of the well known
> BitTorrent file swarming application (c)Bram Cohen and released under
> the MIT license.
>
> Eike Frost modified the software to allow "bandwidth capping" to be
> selected from the GUI to allow ACK messages to pass the upstream during
> normal operation thus increasing overall efficiency.
>
> However all versions mentioned above in the line starting with "Source"
> _DO NOT_ run on Linux. 3.1-CVS-3, 3.2-1 and 3.2.1b-1 produce error
> messages due to a few bugs handling the command line parameters.
>
> The 3.2.1b-2 client DOES work on Linux but is running slowly and works
> for single files only. When working with "batch torrents" it routinely
> hangs during operation (even if it's not touched after it's launch)
>
> The author Eike Frost doesn't offer the pre-3.1-CVS-3 source.
>
> The windows version we have installed on Win32 is a pre 3-1-CVS-4
> version. Now guess what.. )
>
> > Technically it is possible, but it's not trivial, and seems like
> > a pretty bizarre thing to do if the author didn't intend it to
> > be used on Linux in the first place. (Which we can infer from the
> > choice of distribution method.)

>
> I hope the additional background info might make you giving a few little
> hints? *hopes*


So basically the problem is that the versions for which source is available
do not work, but you have a version which works, so you'd like to try getting
it running under Linux. (?)

If that's so, maybe you can isolate the problem to a single file? Extracting
a single .pyc file from the .exe might be relatively easy, even if you had
to basically do it manually.

The packaging process used might be useful to know: was it py2exe, or the
Macmillan Installer?

Note, in case you weren't aware, that you won't actually get back the
*source*, such that you could easily modify it and recompile. You'll
get back the compiled (bytecode) file, which you could put into a .pyc
file and run in place of the "bad" .py file which you have... at least
in theory.

Retrieving the source itself is even more involved. It requires
decompiling (see "decompyle"), although if you go that route you should
get back something very close to the original. Maybe even enough for you
to do a "diff" and patch the latest version to work again?

Sounds like a lot of work though. Wouldn't it be easier to work with
the author to fix the problem in the supported versions, and use them?

-Peter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Call for Papers: World Congress on Engineering WCE 2007 (IAENG conferences with Engineering Letters) imecs__2007@iaeng.org Java 0 12-19-2006 06:51 AM
CFP: Special Issue on Web Engineering (The journal Engineering Letters) imecs_2006@iaeng.org Java 0 01-07-2006 04:48 AM



Advertisments