How can I determine which libraries are used in a Delphi program I don't have the source for?

Question

I have a windows .exe file, but the source code for it is missing. The developer was not responsible and left our company. I think it was a delphi/pascal program. The developer used many libraries but I am not sure which ones. Is there a tool that can tell me which libraries were used to make this exe?

@Andreas Rejbrand: he didn't ask which libraries were in use, but if there is a tool to discover what libraries are used. So the question can be answered. Unfortunately the answer is afaik no.. — The_Fox, Feb 18 '11 at 16:00
The 'packageinfo' resource in a Delphi executable/library contains all the units' name that are linked. That may (or may not) give a hint about possible used libraries. — Sertac Akyuz, Feb 18 '11 at 16:49
Also, if it's a vcl forms application, looking the class name of a visual control with Spy++ or similar, may (or may not) reveal the originating library of that control. — Sertac Akyuz, Feb 18 '11 at 16:56
Exactly. There are names of used units in the PACKAGEINFO resource. And, Delphi's packaging system mandates what unit name *must* be unique. Voila, valuable information collected. Also, examining form resources yields component class names (again, unique). So, this problem isnt that hopeless. Tool, most probably, will be DeDe — Free Consulting, Feb 18 '11 at 18:26
+1; I also vote for reopen; though there are not of-the-shelve tools doing this, the comments give quite a bit of information on finding out what libraries are being used, and an answer telling it is a costly process doing reverse engineering. — Jeroen Wiert Pluimers, Feb 18 '11 at 20:22
Comments here indicate that the question is *not* unanswerable. Although it will probably be fruitless to pursue, it's still a valid question. Voted to re-open. — Rob Kennedy, Feb 18 '11 at 21:25

score 6 · Answer 1 · answered Feb 19 '11 at 00:32

how some users as recommended, you can use the info stored in the PACKAGEINFO resource which is included in each exe, dll or bpl generated by delphi.

you can use the GetPackageInfo function to obtain the data in the package's information table.

check this sample code to see how use this function.

program ResPACKAGEINFO;

{$APPTYPE CONSOLE}

uses
  Windows,
  Classes,
  SysUtils;


function GetUnitFlagInfo(Flags: Byte):string;
begin

  { PackageUnitFlags:
    bit      meaning
    -----------------------------------------------------------------------------------------
    0      | main unit
    1      | package unit (dpk source)
    2      | $WEAKPACKAGEUNIT unit
    3      | original containment of $WEAKPACKAGEUNIT (package into which it was compiled)
    4      | implicitly imported
    5..7   | reserved
  }

  Result:='';
  if (Flags and ufMainUnit<>0) then
  Result:='[Main Unit] ';

  if (Flags and ufPackageUnit<>0) then
  Result:=Result+'[Package Unit] ';

  if (Flags and ufWeakUnit<>0) then
  Result:=Result+'[Weak Unit] ';

  if (Flags and ufImplicitUnit<>0) then
  Result:=Result+'[implicitly imported] ';

  if (Flags and ufWeakPackageUnit<>0) then
  Result:=Result+'[$WEAKPACKAGEUNIT unit] ';

  if (Flags and ufOrgWeakUnit<>0) then
  Result:=Result+'[original containment of $WEAKPACKAGEUNIT]';
end;


procedure GetInfoPackageFlags(Flags:Cardinal);
begin

        { Package flags:
          bit     meaning
          -----------------------------------------------------------------------------------------
          0     | 1: never-build                  0: always build
          1     | 1: design-time only             0: not design-time only      on => bit 2 = off
          2     | 1: run-time only                0: not run-time only         on => bit 1 = off
          3     | 1: do not check for dup units   0: perform normal dup unit check
          4..25 | reserved
          26..27| (producer) 0: pre-V4, 1: undefined, 2: c++, 3: Pascal
          28..29| reserved
          30..31| 0: EXE, 1: Package DLL, 2: Library DLL, 3: undefined
        }


        if  (Flags and pfModuleTypeMask = pfExeModule) then
         Writeln('Type Exe')
        else
        if  (Flags and pfModuleTypeMask = pfPackageModule) then
         Writeln('Type Package')
        else
        if  (Flags and pfModuleTypeMask = pfLibraryModule) then
         Writeln('Type Library');

        if  (Flags and pfNeverBuild = 0) then
         Writeln('Build with runtime packages')
        else
         Writeln('Build without runtime packages');

        if  (Flags and pfIgnoreDupUnits = 0) then
         Writeln('perform normal dup unit check')
        else
         Writeln('Ignore Dup Units');

        if  (Flags and pfProducerMask = pfDelphi4Produced) then
         Writeln('Producer Pascal');

        if  (Flags and pfProducerMask = pfV3Produced) then
         Writeln('Producer pre-V4');

        if  (Flags and pfProducerMask = pfProducerUndefined) then
         Writeln('Producer undefined');

        if  (Flags and pfProducerMask = pfBCB4Produced) then
         Writeln('Producer c++');

        if  (Flags and pfConsumerMask = pfConsumerCompat) then
         Writeln('Consumer Compatible')
        else
        if  (Flags and pfConsumerMask = pfConsumerDelphi) then
         Writeln('Consumer Delphi')
        else
        if  (Flags and pfConsumerMask = pfConsumerBCB) then
         Writeln('Consumer BCB');
end;

procedure PackageInfoCallback(const Name: string; NameType: TNameType; Flags: Byte; Param: Pointer);
begin
    case NameType of
      ntContainsUnit   :  Writeln(Format('Contains %s  %s',[Name+#13#10,GetUnitFlagInfo(Flags)]));
      ntRequiresPackage:  Writeln(Format('Requires %s  %s',[Name+#13#10,GetUnitFlagInfo(Flags)]));
    end;
end;


procedure GetPackageResInfo(const FileName:string);
const
 ResPACKAGEINFO='PACKAGEINFO';
var
  FModule    : Cardinal;
  Flags      : Integer;
begin
  FModule := LoadLibraryEx(PChar(FileName), 0, LOAD_LIBRARY_AS_DATAFILE);
  try
    SysUtils.GetPackageInfo(FModule, nil, Flags, PackageInfoCallback);
    GetInfoPackageFlags(Flags);
    Writeln(GetPackageDescription(PChar(FileName)));
  finally
    FreeLibrary(FModule);
  end;
end;

begin
  try
     GetPackageResInfo('yourApp.exe');
     Readln;
  except
    on E:Exception do
      Writeln(E.Classname, ': ', E.Message);
  end;
end.

score 6 · Accepted Answer · edited May 23 '17 at 12:30

One application that lists the used units in a delphi binary (similar to RRUZ's demonstration), is XN Resource Editor. Latest version is here AFAIK. The below sample screen shot for instance (by luck :)), points to a particular 3rd party library:

As 'Worm Regards' suggested in the comments to the question, the application also displays 'dfm' contents, hence one can see the class names of used components. But for that, I'd suggest DFM Editor, because this application displays the used components in a tree structure, much like the 'structure pane' in the Delphi IDE:

XN or any other resource editor can be used to export a dfm resource to a file, to be examined with DFM Editor.

JosephStyons · Answer 3 · 2011-02-19T03:51:55.867

You mentioned that you "think" it was written in Delphi. If you are not sure, then you can use this small utility. It is just a command line tool- the usage is "IsDelphi.exe ".

If it is indeed written in Delphi, then the Interactive Delphi Reconstructor can do amazing things. Here are step-by-step instructions for using it:

Go to that link
Download three files:

a) The exe

b) The support dll

c) The 'dictionary' for the version of Delphi your former coworker used
Extract all three

(use 7-zip if you don't already have a rar file extractor)
Open IDK.exe
Choose File->Load->Autodetect version
Pick your EXE in the dialog box
Start poking around the Code Viewer and Class Viewer.

Finally, you can find some more general guidelines as well as links to additional tools at this page.

Good luck!

score 1 · Answer 4 · answered Feb 18 '11 at 14:48

1

No, It's practically impossible to reverse engineer a Delphi application. If you do, you got only a bunch of assembly. It's practically impossible to reconstruct which VCL functions are called, let alone which libraries are used.

Unless this program contains some very genious and irreproducable logic it is best to start from scratch and write it all over.

answered Feb 18 '11 at 14:48

GolezTrol

114,394
18
182
210

Why *shouldn't* someone vote this down? The question asks how to get the libraries used. You answer something about reverse-engineering, which is a much different task. And even then, you don't actually mention any tools or techniques someone could use to accomplish the task; you just say it will "practically impossible," even though it really wouldn't be. This is not a helpful answer. – Rob Kennedy Feb 18 '11 at 23:13
Fair enough, but at least say so instead of anonymously voting down. I talk about reverse engineering, because checking for used libraries can only be achieved by inspecting the code and (less reliably) the resource in the application. But since you seem to know more than me, please tell us about those tools that you can use to check which libraries are used. – GolezTrol Feb 18 '11 at 23:36
1

@Rob I think Golez wasn't necessarily objecting to the downvote, he just wanted some commentary to go along with it. I always appreciate it when someone tells me that I'm in the wrong, which sadly happens more than it should!! – David Heffernan Feb 19 '11 at 00:10
1

Indeed I do. I'm rather right than wrong, but if I'm wrong, I'd like to know why. :) – GolezTrol Feb 19 '11 at 00:32
Note that the original question mentions libraries, but some answers seem to read that as designtime components. If you don't make that step, answers like this are more logical. – Marco van de Voort Feb 20 '11 at 19:01

How can I determine which libraries are used in a Delphi program I don't have the source for?

4 Answers4

Linked