Delphi exe to Pas/Dpr program..and it works...
Shane
which I haven't even glanced at yet) which actually works.
I ran it on one of my own Delphi 4 exe's and it churned out all of the dfms,
pas and even the dpr file. I then loaded up the dpr and from what I could
tell, everything was there. How is this possible?!?!?! This seems very
BAD. How can I avoid my programs from being disassembled in this manner?
Currently my only option is to use ASpack which compresses the exe and
prevents it from working.
Any comments?
Thanks,
Shane Bridges
Andrew Baylis
I wonder if it's looking at the extensive DEBUG info in the EXE. Maybe you
could try turning off the compiler options that generate such stuff,
compile, then try this prog.
Cheers,
Andrew
Shane wrote in message ...
Michael Friedl
thanx
Michael Friedl
But exe2dpr doesn't decompile the EXE! It only get's all ressources out of
the exe! The ressources like dfm and so on had never been secrets! You can
get them out with just some lines of code!
Try it with ObjectResourceToText! It's a Delphi procedure!
So You don't have to argue! Your sources should be secure at the moment!
greetings, Michael
Zarko Gajic
EXE2DPR (http://www.ems.ru/~gold/exe2dpr.html)
If you lose your Delphi 2.0-4.0 project sources, but have an executable
file, then this tool can rescue part of lost sources.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zarko Gajic
TMC, Delphi Programming guide
http://delphi.miningco.com
delphi...@miningco.com
"We mine the net so you don't have to"
Stefan Hoffmeister
>How is this possible?!?!?!
...
>Any comments?
Because it is not possible and the tool does NOT work. I know this
tool; it **appears** to be working well, but all it does are trivial
things. It will fail the very moment you ask it to reverse your "real"
source code. Getting that one is just that necessary little bit harder
to do programmatically.
Delphi is not Visual Basic.
Delphi does compile to real machine code. This machine code is next to
impossible to recover correctly.
Oh, and - FYI - that tool probably would work on a C++ compiler -
Borland C++ Builder; and if it does not, a reverser like EXE2DPR can
be written as EXE2BPR for C++ Builder in a matter of minutes.
Again: this toy does only trivial things and is no threat. It is a
fake, but an amusing one.
If you want to learn more about reverse-engineering Delphi-compiled
binaries (but no actual techniques), search DejaNews for "Delphi
decompil*".
--
Stefan Hoffmeister (http://www.econos.de/)
No private email, please, unless expressly invited.
Stefan Hoffmeister
>EXE2DPR (http://www.ems.ru/~gold/exe2dpr.html)
>If you lose your Delphi 2.0-4.0 project sources, but have an executable
>file, then this tool can rescue part of lost sources.
This tool does **not** "recover" even a single line of source code.
All it does is to extract RCDATA forms from the EXE and then makes an
half-educated guess what the .DPR might have been looking like and
builds it this way.
Stefan Hoffmeister
>I wonder if it's looking at the extensive DEBUG info in the EXE.
There is no such thing as extensive DEBUG info in the EXE. Unless you
turn on generation of TD32 (or TDW or whatever they call it in the
various IDEs) information. And that you will hardly ever do.
Shane
that all my functions weren't IN it....just function addresses :) I guess
it's harmless.
My apologies...still an interesting program for a newbie to be able to
recover resources.
Thanks,
Shane.
VBDis
Im Artikel <36b562e...@news.rz.uni-passau.de>,
no....@address.in.signature (Stefan Hoffmeister) schreibt:
>Delphi is not Visual Basic.
>Delphi does compile to real machine code. This machine code is next to
>impossible to recover correctly.
Perhaps you should be informed, that the newer VB versions also can create
native code, and that p-code was "invented" or at least used by Wirth in his
Pascal project.
Thanks for the decompiler hint, I'll check the links for usability in my
decompiler project.
DoDi
Markku Nevalainen
>
> Thanks for the decompiler hint, I'll check the links for usability in my
> decompiler project.
>
Ehhh... you aren't going to release any such product we delphians would
not like, are you?:)
Markku Nevalainen
Stefan Hoffmeister
>
>Im Artikel <36b562e...@news.rz.uni-passau.de>,
>no....@address.in.signature (Stefan Hoffmeister) schreibt:
>
>>Delphi is not Visual Basic.
>>Delphi does compile to real machine code. This machine code is next to
>>impossible to recover correctly.
>
>Perhaps you should be informed, that the newer VB versions
v5+. I know.
Stefan Hoffmeister
Not him. Me.
If I have enough spare time, I will do it out of academic interest.
jo...@lindgren.pp.se
Finding ENOUGH spare time would be a treat!
I have been suggesting 30 hour days, with 6 hour sleep, 12 hour work and 12 hour spare time. Maybe that would make it possible to keep up with things to do at work
and at home.
johan
VBDis
Im Artikel <36B80D...@iki.fi>, Markku Nevalainen <m...@iki.fi> schreibt:
>Ehhh... you aren't going to release any such product we delphians would
>not like, are you?:)
I never released tools that programmers wouldn't like. I'm writing programs
myself, you see. None of my C decompilers for 68K processors was ever
published, nor the decompiler for GFA Basic, all working very well for me.
There must exist substancial reasons, why I should publish tools, that might be
used for software piracy. The release of the VB3 decompiler was necessary, to
force MS to remove decompiler support from the VB executables. I published that
decompiler only after MS didn't respond to my according requests, to alert all
VB users of that inacceptable behaviour of MS and VB.
Perhaps I should ask for opinions, before releasing future decompilers? Ten
years ago I had to answer such questions to me alone, but nowadays an according
public discussion is possible.
DoDi
Stefan Hoffmeister
>Perhaps I should ask for opinions, before releasing future decompilers?
What for?
The base technology is available on the net (Cristina Cifuentes -
Ph.D. thesis in PS; even with an x86 DOS C reverser).
There are plenty of disassemblers, free ones, some with source.
I see absolutely no point in not releasing or selling implementations
of these to the general public. If people are not aware of the threats
imposed by reverse-engineering, they don't deserve any better.
Also those people who have trust in
"An anti-debug unit, just add it to uses and no one can trace or
dis-assemble your code."
[Recently uploaded to DSP as antidbg4.zip and antidbg3.zip]
really don't deserve any better. The above-mentioned "thing" is a
joke, since the author compiled the code *with* debug information.
Thanks to that I had it reversed within 5 minutes (just for a laugh).
There are a few viable techniques that protect reasonably well against
reversing - e.g. PE encryptors (even PE packers will hinder a bit).
Markku Nevalainen
>
> Perhaps I should ask for opinions, before releasing future decompilers? Ten
> years ago I had to answer such questions to me alone, but nowadays an according
> public discussion is possible.
>
I see no reason why someone should ask permission to publish any legal
software.
If you can get out a Delphi decompiler that is, let's say by 70%, as good
as the VB3-decompiler, then you'll have your first customer right here.
I believe all my EXE-compressed Delphi executables would still be under
quite a good shelter.
Markku Nevalainen
Sundial Services
> >Perhaps I should ask for opinions, before releasing future decompilers?
>
>
> The base technology is available on the net (Cristina Cifuentes -
> Ph.D. thesis in PS; even with an x86 DOS C reverser).
>
> There are plenty of disassemblers, free ones, some with source.
>
> I see absolutely no point in not releasing or selling implementations
> of these to the general public. If people are not aware of the threats
> imposed by reverse-engineering, they don't deserve any better.
Reverse engineering can be very useful. When you buy a software product
there are rarely any serious secrets about how it works -- you are
buying the fact that someone ELSE wrote it and debugged it for you!
Stefan Hoffmeister
>I see no reason why someone should ask permission to publish any legal
>software.
>If you can get out a Delphi decompiler that is, let's say by 70%, as good
>as the VB3-decompiler, then you'll have your first customer right here.
Well, at this stage, if you give me the TD32 information - either
stripped or added to the binary - I think I *can* score 80 per cent by
rebuilding everything by hand.
I don't have the time at hand to work full-scale on a reverser, but I
should have all the bits and pieces at hand plus the knowledge and
analysis of the Delphi code generator to write a reasonably good
reverser.
>I believe all my EXE-compressed Delphi executables would still be under
>quite a good shelter.
Nope. Ever looked at ReadProcessMemory? I have a ring 3 debugger
running here where the only slightly unusual feature is that it is my
own creation. I can get a perfect snapshot of your EXE-compressed
binary any time.
Of course, if your compressor has some anti-debugging tricks the game
is a wee bit harder, since I need to attach at a later stage (which I
have not bothered to implement yet), but basically no problem.
Now if your compressor played a couple of tricks which I am currently
inventing and designing myself, matters could be a lot worse... These
tricks I am designing should make reversing quite an expensive thing
to do - but all that is at a very basic design stage and while I have
the ideas, I do not even know whether it will work out in practice.
Some tricks are pretty generic (as far as processors are concerned),
some tricks are Win32 specifics. And there are many, many unknown
variables.
Markku Nevalainen
>
> Well, at this stage, if you give me the TD32 information - either
> stripped or added to the binary - I think I *can* score 80 per cent by
> rebuilding everything by hand.
What does this 'stripped or added' mean exactly? When I hand out some final
EXE app, then I always turn off all the debug information switches before
the final compilation. I believe most do it this way.
> Now if your compressor played a couple of tricks which I am currently
> inventing and designing myself, matters could be a lot worse... These
> tricks I am designing should make reversing quite an expensive thing
> to do -
I hope I had invented and would be able to carry out that business idea.
First release a good decompiler to make sure everybody is awake and eyes
wide open. Then tell, that by the way, there's also some decompiler protect
tools available:-)
Markku Nevalainen
VBDis
Im Artikel <36ba8fe...@news.rz.uni-passau.de>,
no....@address.in.signature (Stefan Hoffmeister) schreibt:
>There are a few viable techniques that protect reasonably well against
>reversing - e.g. PE encryptors (even PE packers will hinder a bit).
IMO we agree, that all programs are subject to copyright law. Therefore most
attempts to decompile executables are simply illegal, not justified by any
legal option.
But laws never have been able to extinguish crime. Therefore the only viable
technique is, to not offer tools for possible criminal abuse. Otherwise the
legal user has to pay for all efforts, that the authors must take in order to
preserve their rights. We should have learned what effect weapons,
anti-weapons, anti-anti-weapons asf. will have in practice. The same for virus
and anti-virus...
Therefore I suggested a public discussion, what can be done to prevent abuse of
such tools, and that these preventions should be built into the tools
themselves, not into every single application, that will not be prepared
against any attack by some future tools.
Even if the theory of decompilers and nuclear bombs are published, only a few
people are capable to make use of that knowledge. Using the same things
requires no special skills and reasons.
DoDi
Stefan Hoffmeister
>Stefan Hoffmeister wrote:
>>
>> Well, at this stage, if you give me the TD32 information - either
>> stripped or added to the binary - I think I *can* score 80 per cent by
>> rebuilding everything by hand.
>
>What does this 'stripped or added' mean exactly? When I hand out some final
>EXE app, then I always turn off all the debug information switches before
>the final compilation. I believe most do it this way.
The only option that matters here is
Project | Options -> Linker: Include Turbo Debugger information
If checked, Delphi adds Turbo Debugger information to the binary which
then is a wonderful source of reversing information ("added").
Borland C++ and Borland C++ Builder produce the same information - but
there it is not added to the binary itself, but can be found
"stripped" in a separate file: <your application>.TDS.
You can strip Turbo Debugger information (if it is there <g>) from a
Delphi binary by using a tool coming ONLY with Borland C++ -
TDSTRP32.EXE, I believe (I have my own set of tools).
To make this clear: If you ship a built, linked binary - i.e. a DLL or
EXE - and NOT DCUs or DCPs, then the *compiler* switch $D- ($DEBUGINFO
OFF) - Compiler page in the Project Options dialog - does not add or
remove *anything* from your application. This compiler switch only has
an effect on your DCUs and DCPs. You *never* should turn off this
switch unless you ship DCUs, because if you do, Delphi 4 source code
browsing will simply stop working (as well as the Object Browser in
any version of Delphi).
VBDis
Im Artikel <36BB71...@iki.fi>, Markku Nevalainen <m...@iki.fi> schreibt:
>First release a good decompiler to make sure everybody is awake and eyes
>wide open. Then tell, that by the way, there's also some decompiler protect
>tools available:-)
Better create a virus first, then offer anti-virus support, it's more
profitable and can be exercised ad infinitum :-(
DoDi
VBDis
Im Artikel <36BB00...@iki.fi>, Markku Nevalainen <m...@iki.fi> schreibt:
>I see no reason why someone should ask permission to publish any legal
>software.
What's legal in one country, can be illegal in another one.
Releasing a decompiler is not only a legal matter, but also a matter of ethics.
>If you can get out a Delphi decompiler that is, let's say by 70%, as good
>as the VB3-decompiler, then you'll have your first customer right here.
The VB3 decompiler demonstrates and uses the source code, built into VB3
executables. A decompiler for other applications will need similar (e.g. debug)
information for similar results. Thus it's not (only) a matter of the
decompiler, but also of the application, that shall be decompiled.
>I believe all my EXE-compressed Delphi executables would still be under
>quite a good shelter.
My published decompilers will always refuse to deal with modified executables.
But when someone offers a tool to uncompress your EXE files...
DoDi
Markku Nevalainen
>
> What's legal in one country, can be illegal in another one.
> Releasing a decompiler is not only a legal matter, but also a matter of ethics.
I have heard it's illegal to use efficient crypting algorigms when for instance
e-mailing something from France. Also USA tries to restrict the export of
those 64+ bit decrypting software tools.
I still don't think it's the software writers legal, or even ethical problem
when he releases some 128 bit crypting tools for instance in UK or Germany.
It's like manufacturing cigarettes. It's not very ethical, when you know
there are always some 10 year old kids making their first acuaintance with
smoking.
But as long as national parlaments, and international organizaions (UN,
GATT etc.) say it's all legal, then why not make one's living for instance
by producing cigarettes.
Ok, I admit it's a clear ethical question for an individual who is the only
one that currently has some new (decompiling?) technology available. But
sooner or later twenty more people have developed the same technology.
Then it's usually very ineffective to talk any more just about ethics, but
make the parliaments to write new laws for it as soon as possible.
Markku Nevalainen
VBDis
Im Artikel <36BD93...@iki.fi>, Markku Nevalainen <m...@iki.fi> schreibt:
>sooner or later twenty more people have developed the same technology.
>Then it's usually very ineffective to talk any more just about ethics, but
>make the parliaments to write new laws for it as soon as possible.
Once something has become available, laws and controls are of no special use.
It's illegal to kill people, but did that law stop murder? In contrast, laws
document what *is* possible, but *should* not be done.
With regards to decompilers or cryptography, theory alone is of little
practical use. Only when the theory is implemented in an application, it
becomes usable to other people. We cannot prevent such implementations, it's
*only* a matter of the ethics of those (few) people, that are able to
understand, improve and implement the theory.
DoDi