Delphi packing assistance.

[mudlord]

Hi,

I ran into a bug with processing Delphi/FreePascal executables. All Delphi versions seem to be affected.

I am unsure as to the problem.

I checked in non Delphi executables and TLS callbacks/tables seem to work correctly, so atm I am at a loss to see what I am missing.

This seems to be a final bug of my exe packer, and the main thing stopping its release.

 

Any help at all would be great.

test.rar

Edited December 4, 2014 by mudlord

[kao]

DATA section is not decompressed correctly. As a result, at address 452de4 you have 0, and packed program smashes with AV.

Are you using the exact same version of APLib in packer and program stub?

[mudlord]

Thanks for the advice, I will double check and rewrite that (I should have checked by unpacking the exe manually instead of just checking just the PE header and things). I'll do some more checks and things.

 

Have to check if this is a similar case for Delphi 2010 and the XE versions, too.

 

Edit: Thanks kao, with this hint discovered yet more bugs. Looks like this might take a while.

Edited December 9, 2014 by mudlord

[omar911]

if your going to pack your exe i would use a packer caled pacman which is free and just google it

Edited December 9, 2014 by omar911

[mudlord]

I fail to see your point. With your logic, I would have stuck with UPX like countless others do, when there is better alternatives. like bero's packer.

 

Anyway, with kao's hint, I did some more testing, doing mainly XORing of bytes so something like aplib did not need to be used. This uncovered plenty more bugs. Found a issue with mingw executables, not sure if its TLS related.

 

edit: found this long standiing bug. The variable in question is a DWORD which is in the TLS table. The AddressofIndex variable funnily enough resides in the DATA section, relocating it fixed it. Seems Windows zeroes that variable on startup, hence it being very difficult to trace when debugging the packer itself.

Edited January 5, 2015 by mudlord