Using DisAsm32 by Russell Libby, disassembling a procedure/function/method is just a matter of passing a (consistent) Pointer to the procedure TDisAsm.Disassemble(Address: Pointer; Size: Cardinal = 0);.
So far, I have managed to disassemble any arbitrary procedure/method, even from a loaded external module (BPL/DLL) provided they are appropriately exported.
From the current process (The EXE image loaded by windows loader), I want to get a valid pointer to the entrypoint.
I want to come up with something akin to IDR (Interactive Delphi Compiler) provides through it's Code Viewer Tab but from the Exe running instance itself.
How can it be done? I'm not very comfortable with PE structures for the time being (but I am striving to, trust me) and wonder wether they are relevant for the purpose.
For PE structure reading/writing you can take a look at the open source JEDI library JCL, for example:
http://www.koders.com/delphi/fid38455E3CFDAF1F38C48DA3A295034E7015A4D01E.aspx?s=zip#L1810
The entrypoint of the running instance is "System.MainInstance"?
My own answer:
I came up with the working solution as follows
function TForm1.GetEntryPoint: Pointer;
var
DosHeader: PImageDosHeader;
NtHeaders : PImageNtHeaders;
OptionalHeader: PImageOptionalHeader;
begin
DosHeader := PImageDosHeader(HInstance + 0);
NtHeaders := PImageNtHeaders(HInstance + Cardinal(DosHeader^._lfanew));
OptionalHeader := PImageOptionalHeader(Cardinal(NtHeaders) + SizeOf(DWORD) + IMAGE_SIZEOF_FILE_HEADER);
//
Result := Pointer(HInstance + OptionalHeader^.AddressOfEntryPoint);
end;
Side Note:
SysInit.HInstance is the same as System.MainInstance: My preference goes for it as it sounds more C/C++ and find that more meaningfull for the case.
DisAsm32 goes beyond the call #Halt0 instruction when disassembling from the EntryPoint: It is designed to disassemble function/procedure/method and considers a ret instruction as the end.
The moral of it:
I will look for other more appealing disassembler such as BeaEngine and will keep the ball rolling.
Related
I have the following issue.
I'm using Glut openGL for drawing certain elements in my application written in Delphi. The library file I'm using is called glut32.dll (placed where the EXE file is standing)
Now I decided to compile my app in 64-bit as other libraries it is using are going to be updated only for 64-bit. All fine, but the one thing that stops me is the glut32.dll (it is 32-bit). As the Glut project is not supported for many years already I found the freeglut alternative which claim to be replacement for the original Glut: https://freeglut.sourceforge.net/, and downloaded the freeglut.dll from here: www.transmissionzero.co.uk/software/freeglut-devel/ for MSVC.
As I looked at the .h header files it seems more or less the same as my code translation is in the *.pas files.
So I tried to just load the freeglut.dll instead of glut32.dll (dll is set to the correct dll name in the function below)
procedure LoadGlut(const dll: String);
begin
FreeGlut;
hDLL := LoadLibrary(PChar(dll));
if hDLL = 0 then raise Exception.Create('Could not load Glut from ' + dll);
#glutInit := GetProcAddress(hDLL, 'glutInit');
#glutInitDisplayMode := GetProcAddress(hDLL, 'glutInitDisplayMode');
#glutCreateWindow := GetProcAddress(hDLL, 'glutCreateWindow');
#glutCreateSubWindow := GetProcAddress(hDLL, 'glutCreateSubWindow');
#glutDestroyWindow := GetProcAddress(hDLL, 'glutDestroyWindow');
#glutPostRedisplay := GetProcAddress(hDLL, 'glutPostRedisplay');
...
It is loading with no errors and so on, also the procedures in it, but when the application start and reach a point to use one of these functions it just stop the debugger with no error message (like pressing Ctrl+F2).
procedure DrawArrow(P1, P2: TRPoint; Color: TRGBAColor);
var
R : Real;
begin
DrawLine(P1, P2, Color);
glColor4fv(#Color[0]);
glPushMatrix;
SetZAxis(P2, P1);
R := VectorModulus(VectorDifference(P1,P2));
glTranslated(0, 0, R);
SetSymbolScale;
glTranslated(0, 0, -ARROW_L);
glutSolidCone(ARROW_W/2, ARROW_L, SOLID_SLICES, SOLID_STACKS);
glPopMatrix;
glPopMatrix;
end;
The debugger shut itself at glutSolidCone(ARROW_W/2, ARROW_L, SOLID_SLICES, SOLID_STACKS); This function is defined in freeglut as well.
EDIT: If I call other simple function like glutInitDisplayMode it doesn't stop, so it seems that the library is correctly loaded. But it still keeps shutting down at glutSolidCone or other drawing functions.
I don't have much experience of using these header files and dll that comes with it, but my Delphi code should be a good translation in this case? Or not? I don't know how to debug this.
What is the way to adapt my code in order to fit freeglut in it. It should be something small I think as most of the things should be the same.
Thank you for the help
It seems that just replacing glut32.dll with freeglut.dll won't do the job properly as I guess functions inside differs a bit (or simply renaming freeglut.dll --> glut32.dll also fails). However I found a workaround published by NVIDIA: NVIDIA Cg Toolkit
It is not supported since 2013, but when installed it brings the dll version of glut32 both for 32-bit and 64-bit development. Quickly try it and it seems to work and cover what I have as definition in Glut.pas.
So if you need 64-bit version and replacement of glut32.dll it can be downloaded from there.
Meanwhile if somebody convert the freeglut headers (.h) to Delphi code it would be great as at the end the Freeglut projecy is still maintained, up-to-date and add some more useful functions in addition to the original Glut. This conversion is still beyond my knowledge.
I've been Googling up and down, searching on the Free Pascal Wiki and even on some (obscure) mailing lists and have come completely empty on how to use ioctl() or fpioctl() on Free Pascal.
I have this bug report from Free Pascal's Bugtrack with code that enumerates the network interfaces.
The code does not compile since the libc unit has been deprecated.
A lot of similar questions about libc point to this wiki entry that talks about it's demise.
It does not give you any indication on where the SIOC*IF* stuff has gone.
Does that mean that most of ioctl functionality has gone?
Using find and grep, under /usr/share/fpcsrc/<fpc-version>/, I've been able to track some usage of fpioctl() in relation to terminals with the termios unit. Other stuff uses it but it looks like it's under other OSs.
Apart from that I'm unable to find anything of any use if you want to do something like:
if ioctl(sock, SIOCGIFCONF, #ifc)= 0 then begin
{...}
end;
So, can anyone from the Free Pascal Community give me a pointer to what's the current situation if one wants to do ioctl calls under Linux?
Does BaseUnix.FpIOCtl meet your use case? Have a look at the BaseUnix documentation. I found an example of using it here (reposted below).
program testrpi;
{$mode objfpc}{$H+}
uses
baseUnix,
classes,
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
sysutils;
const
I2C_SLAVE = 1795;
var
buf : packed array [0..1] of char;
c : char;
devPath : string = '/dev/i2c-1';
handle : Cint;
iDevAddr : Cint = $04;
begin
try
handle := fpopen(devPath,O_RDWR);
fpIOCtl(handle, I2C_SLAVE, pointer(iDevAddr));
except
writeln('Error initalizing i2c');
halt;
end;
while true do begin
write('Enter digit 1-9:');
readln(c);
if (not(c in ['1'..'9'])) then begin
writeln('oops - try again');
continue;
end;
buf[0] := chr(ord(c) - ord('0'));
try
fpwrite(handle, buf, 1);
except
writeln('Error writing');
halt;
end; //try
buf[0] := #99;
sleep(10);
try
fpread(handle, buf, 1);
except
writeln('Error reading');
halt;
end; //try
writeln('buf=', ord(buf[0]));
end; //while
fpclose(handle);
end.
The fpioctl bit has been answer by Mick and the FAQs. As for the constants, as the libc unit faq explains there is no clear cut solution, and thus for the more specialized constants there are no replacements.
OS specific constants should go in OS specific units (linux), and (somewhat) portable ones are usually grouped with the calls of the functionality they are for.
The old libc header was an rough header translation that was cleaned up somewhat, which was manageable for 32-bit Linux only, but unusable for a nix abstraction or even "just" multiplatform Linux. It was therefore abandoned.
In short it is best to either make a simple unit that abstracts the relevant parts or to just define the constants locally.
I have a "Find Files" function in my program that will find text files with the .ged suffix that my program reads. I display the found results in an explorer-like window that looks like this:
I use the standard FindFirst / FindNext methods, and this works very quickly. The 584 files shown above are found and displayed within a couple of seconds.
What I'd now like to do is add two columns to the display that shows the "Source" and "Version" that are contained in each of these files. This information is found usually within the first 10 lines of each file, on lines that look like:
1 SOUR FTM
2 VERS Family Tree Maker (20.0.0.368)
Now I have no problem parsing this very quickly myself, and that is not what I'm asking.
What I need help with is simply how to most quickly load the first 10 or so lines from these files so that I can parse them.
I have tried to do a StringList.LoadFromFile, but it takes too much time loading the large files, such at those above 1 MB.
Since I only need the first 10 lines or so, how would I best get them?
I'm using Delphi 2009, and my input files might or might not be Unicode, so this needs to work for any encoding.
Followup: Thanks Antonio,
I ended up doing this which works fine:
var
CurFileStream: TStream;
Buffer: TBytes;
Value: string;
Encoding: TEncoding;
try
CurFileStream := TFileStream.Create(folder + FileName, fmOpenRead);
SetLength(Buffer, 256);
CurFileStream.Read(Buffer[0], 256);
TEncoding.GetBufferEncoding(Buffer, Encoding);
Value := Encoding.GetString(Buffer);
...
(parse through Value to get what I want)
...
finally
CurFileStream.Free;
end;
Use TFileStream and with Read method read number of bytes needed. Here is the example of reading bitmap info that is also stored on begining of the file.
http://www.delphidabbler.com/tips/19
Just open the file yourself for block reading (not using TStringList builtin functionality), and read the first block of the file, and then you can for example load that block to a stringlist with strings.SetText() (if you are using block functions) or simply strings.LoadFromStream() if you are loading your blocks using streams.
I would personally just go with FileRead/FileWrite block functions, and load the block into a buffer. You could also use similair winapi functions, but that's just more code for no reason.
OS reads files in blocks, which are at least 512bytes big on almost any platform/filesystem, so you can read 512 bytes first (and hope that you got all 10 lines, which will be true if your lines are generally short enough). This will be (practically) as fast as reading 100 or 200 bytes.
Then if you notice that your strings objects has only less than 10 lines, just read next 512 byte block and try to parse again. (Or just go with 1024, 2048 and so on blocks, on many systems it will probably be as fast as 512 blocks, as filesystem cluster sizes are generally larger than 512 bytes).
PS. Also, using threads or asynchronous functionality in winapi file functions (CreateFile and such), you could load that data from files asynchronously, while the rest of your application works. Specifically, the interface will not freeze during reading of large directories.
This will make the loading of your information appear faster, (since the file list will load directly, and then some milliseconds later the rest of the information will come up), while not actually increasing the real reading speed.
Do this only if you have tried the other methods and you feel like you need the extra boost.
You can use a TStreamReader to read individual lines from any TStream object, such as a TFileStream. For even faster file I/O, you could use Memory-Mapped Views with TCustomMemoryStream.
Okay, I deleted my first answer. Using Remy's first suggestion above, I tried again with built-in stuff. What I don't like here is that you have to create and free two objects. I think I would make my own class to wrap this up:
var
fs:TFileStream;
tr:TTextReader;
filename:String;
begin
filename := 'c:\temp\textFileUtf8.txt';
fs := TFileStream.Create(filename, fmOpenRead);
tr := TStreamReader.Create(fs);
try
Memo1.Lines.Add( tr.ReadLine );
finally
tr.Free;
fs.Free;
end;
end;
If anybody is interested in what I had here before, it had the problem of not working with unicode files.
Sometimes oldschool pascal stylee is not that bad.
Even though non-oo file access doesn't seem to be very popular anymore, ReadLn(F,xxx) still works pretty ok in situations like yours.
The code below loads information (filename, source and version) into a TDictionary so that you can look it up easily, or you can use a listview in virtual mode, and look stuff up in this list when the ondata even fires.
Warning: code below does not work with unicode.
program Project101;
{$APPTYPE CONSOLE}
uses
IoUtils, Generics.Collections, SysUtils;
type
TFileInfo=record
FileName,
Source,
Version:String;
end;
function LoadFileInfo(var aFileInfo:TFileInfo):Boolean;
var
F:TextFile;
begin
Result := False;
AssignFile(F,aFileInfo.FileName);
{$I-}
Reset(F);
{$I+}
if IOResult = 0 then
begin
ReadLn(F,aFileInfo.Source);
ReadLn(F,aFileInfo.Version);
CloseFile(F);
Exit(True)
end
else
WriteLn('Could not open ', aFileInfo.FileName);
end;
var
FileInfo:TFileInfo;
Files:TDictionary<string,TFileInfo>;
S:String;
begin
Files := TDictionary<string,TFileInfo>.Create;
try
for S in TDirectory.GetFiles('h:\WINDOWS\system32','*.xml') do
begin
WriteLn(S);
FileInfo.FileName := S;
if LoadFileInfo(FileInfo) then
Files.Add(S,FileInfo);
end;
// showing file information...
for FileInfo in Files.Values do
WriteLn(FileInfo.Source, ' ',FileInfo.Version);
finally
Files.Free
end;
WriteLn;
WriteLn('Done. Press any key to quit . . .');
ReadLn;
end.
actually i am converting a c++ code to delphi, but i have problem to translate this line
PIMAGE_NT_HEADERS header = (BYTE *)lib + ((PIMAGE_DOS_HEADER)lib)->e_lfanew;
to delphi (this is my result at the moment)
var
lib : THandle;
header : PImageNtHeaders;
begin
//....
//.....
header := Pointer(PByte(lib) + PImageDosHeader(lib)._lfanew);
end;
but the compiler gives me this message operator not applicable to this operand type
can you help me to translate this line.
header := Pointer(Integer(PByte(lib)) + PImageDosHeader(lib)._lfanew);
You might be able to sidestep a lot of this. If you're looking for PE image header routines, look up the ImageHlp unit from the RTL, and the JclPeImage unit from the JCL. They've got lots of prebuilt code to make image and image header header work easier.
the _lfanew member is most likely an offset so it needs to be an integer or DWORD instead of a pointer. Just guessing as I don't use Delhpi but have you tried :-
header := Pointer(PByte(lib) + (DWORD)(PImageDosHeader(lib)._lfanew));
A web search came up with the following : http://www.cheesydoodle.com/?p=175
This code is Delphi based and is using the same library you are. You will most likely find a solution hidden in this code listing on CheesyDoodle.
Pointer arithmetic is much more limited in delphi, and direct addition is not allowed. You'll have to use the Inc function on your pointers.
example(source ):
program PointerArithmetic;
{$APPTYPE CONSOLE}
uses
SysUtils;
procedureWritePointer(P: PDouble);
begin
Writeln(Format('%8p', [P]));
end;
var
P: PDouble;
begin
P := Pointer($50000);
WritePointer(P);
Inc(P); // 00050008 = 00050000 + 1*SizeOf(Double)
WritePointer(P);
Inc(P, 6); // 00050038 = 00050000 + 7*Sizeof(Double)
WritePointer(P);
Dec(P, 4); // 00050018 = 00050000 + 3*Sizeof(Double)
WritePointer(P);
Readln;
end.
What you are working on is called RVA (Relative Virtual Address). Basic formula is
Address = Base + Displacement. Naturally, Address and Base are untyped pointers while Displacement is signed integer. Object Pascal disallows pointer arithmetics, so typecasting is required.
So:
var
Address, Base: Pointer;
Displacement: Integer;
{ ... }
Address := Pointer(Cardinal(Base) + Displacement);
{ or, in your case }
var
Module: HMODULE; { opaque type designates module handle and equals to load address }
NTHeaders: PImageNtHeaders;
begin
NTHeaders := Pointer(Cardinal(Module) + PImageDosHeader(Module)^._lfanew);
if NTHeaders^.Signature = ......
I don't work in Delphi day-to-day, but I suspect the error is due to one of two things:
Pointer math is not enabled. Delphi, by default, does not allow you to to C-style pointer manipulation, eg adding a number to a pointer to get another pointer - remember Delphi is a 'safe' language. To enable this, turn on pointer math using the {$POINTERMATH ON} directive. This forum posting has some more info too.
This is the bit I can't remember because it's been a while: You may not be able to add pointers of different types - remember the size of what the pointer points to is different. Without knowing what _lfanew is I can't give you more information. If this is the case, get everything in bytes and add those.
You may want to use the Inc function too, to convert your code to be more Delphi-like. Inc will increment a typed pointer by the size of the structure that pointer points to, not by one byte. Pointer math generally is not quite C-style :) I think it's better though, since it's type-aware.
Edit: I noticed Martin Broadhurst's comment on your question pointing out this is probably parsing a PE image. If so, look up the Jedi Code Library's PE image unit. I've never used it but I know it exists, and it's a translation of the C headers. It may include helper functions too. Using it might mean rewriting code rather than converting it, but you'll probably get cleaner, more Delphi-style code at the end.
I need to use a 3rd party dll in our main app. When I staticly link to the provided DLL it works ok and I can the DLLs exported functions.
But we don't want our main app dependend on this dll on startup so I tried to dynamicly load the DLL when I need it :
DLLHandle := LoadLibrary('3rdparty.dll');
ret := GetLastError();
if DLLHandle = 0 then
begin
err := SysErrorMessage(ret);
Writeln(err);
end //...
but did doesnt work : The LoadLibrary function returns 0 and the LastErrorcode is 3221225616. Because I don't know what I'm doing wrong I tried the same (on the same pc) coded in c and it works : but what doesn't it work with delphi ? :
I call the same LoadLibrary function on the same dll!
When I monitor with ProcMon I see that the 3rdparty dll gets loaded and that also the dependand dlls of the 3rdparty dll gets loaded. : So windows certainly finds the DLL.
But somewhere it the loading process it fails :
When I try to load the DLL with LoadLibraryEX with DONT_RESOLVE_DLL_REFERENCES or LOAD_LIBRARY_AS_DATAFILE it also works (but I can't offcourse call the needed functions...)
I'm out of ideas : hope you guys can help me further...
thx in adv.
Kristof
Does this work?
var
SavedCW: word;
...
SavedCW := Get8087CW;
Set8087CW(SavedCW or $7);
DLLHandle := LoadLibrary('3rdparty.dll');
Set8087CW(SavedCW);
if DLLHandle = 0 then
begin
ret := GetLastError();
err := SysErrorMessage(ret);
Writeln(err);
end //...
Some discussion:
The error code, 3221225616, seems, when asking Google, to be the result of an invalid floating point operation. Now, this seems very technical; indeed, what does loading a library have to do with floating point computations? The floating point control word (CW) is a bitfield where the bits specify how the processor should handle floating-point errors; it is actually rather common that unexpected floating point errors can be dealt with by changing one of these bits to 1 (which by the way is the default state). For an other example, see this question of mine, in which I get a totally unexpected division by zero error, which is dealt with by setting the "div by zero" bit of the control word to 1.
3221225616 = STATUS_FLOAT_INVALID_OPERATION. My wild guess is that the FPU CW is different in your Delphi and C apps, and that your DLL's initialization is sensitive to this.
Possibly related: http://discuss.joelonsoftware.com/default.asp?joel.3.88583.15
Try using SafeLoadLibrary() in the Delphi RTL instead of the Win32 LoadLibrary. This function preserves the FP control word before calling LoadLibrary, and sets it back to what Delphi wants after the LoadLibrary returns.
I think that you should report to 3rdparty.dll's developers about a bug in their DLL.
I know this is an old thread but I just came across the same problem with a DLL written in VB.
This solution works for both x86 and x64
var ret:cardinal;
em:TArithmeticExceptionMask;
begin
result:= 1;
If Lib <> 0 Then exit; // already loaded
em:=GetExceptionmask;
SetExceptionmask(em+[exInvalidOp,exZeroDivide,exOverflow, exUnderflow]);
Lib := LoadLibrary(DLLname);
SetExceptionmask(em);
ret := GetLastError;
if ret<>0 then
raise exception.create(SysErrorMessage(ret));