Total Commander

Hello,

Is there a reason why Total Commander does not use ASLR (Address Space Layout Randomization, look it up on wikipedia ) ? When I force its use thorugh group policy, everything appears to be working fine. You can use this to test: kb2458544 on microsoft page.

Sorry, cannot post actual links due to forum restriction...

I don't see any reason to use it.
TC is not an application that works with extra-secret data like user account credentials or credit card numbers, so it is not necessary for it. And, such applications require more time to start because of relocation.

Anyway, TC made with Delphi 2 which doesn't support it.
And, it is necessary to have relocations inside of EXE to enable this feature.

Hm-m, maybe this is the reason why it works for you - Delphi creates section with relocations even in EXE (redundant 121 kB of TOTALCMD.exe) although it is NOT necessary for executables at all since EXE's always loaded at preferred address.

It seems that this won't work with TOTALCMD64.exe because it doesn't contain relocation table. Or maybe it will just work as if option is disabled.

advsrch wrote:When I force its use thorugh group policy, everything appears to be working fine.

BTW can you tell which base address OS chooses for module TOTALCMD.exe? Look e.g. in lower pane of Process Explorer. If TOTALCMD.exe has base 0x400000, ASLR is not used.

The main use for ASLR is prevention of buffer overflow (or basically all shellcodes) which is a real issue for Total Commander since it can load modules etc.

Are you sure Total Commander is made in Delphi2? Since there is now a 64-bit version, it cannot be Delphi2.

The base address is different from 0x400000 when I use EMET so it is clearly working.

TC8x64 is made in Lazarus because Delphi doesn't support x64 (at least it didn't support it when porting to Lazarus was started), TC8x32 is still made in Delphi 2.

Have you tried to enable ASLR for TOTALCMD64.EXE?

Just tested in on TC64 and ASLR is working - confirmed both in Process Explorer and in VMMap.

Why? Is it not working for you? Are you testing it as well?

Actually I haven't tried it, I have WinXPx32 at home.

Unfortunately ASLR would make stack traces quite useless - or is there a way to find out the (random) module base programmatically?

What exactly is the problem you are talking about? I perform stack traces just fine on my ASLR enabled applications.

I mean when TC crashes on a user's computer and he posts a stack trace, the posted numbers are useless without knowing the module base address (which would have to be included in the stack trace).

Unfortunately somebody else will need to answer that question. I perform memory dumps on crash.

I guess if you get the method parameters in the stack trace or enable reflection then you can derive what methods caused the crash.

But if I look at it logically, a lot of programs run with ASLR enabled, and the developers are not saying that it makes debugging more difficult...

I would say try enabling ASLR, make Total Commander crash (implement a crash method), and see what the stack trace gives you.

ghisler(Author) wrote:[...] the posted numbers are useless without knowing the module base address (which would have to be included in the stack trace).

Module base addresses can be obtained by using FindHInstance function from this post.

Regards

8.52a x64 still hasn't ASLR enabled

Because no one have tried enabling.