Well with Franks trick dropper worked.
Here is the log from infected machine.
==============================================
OS Name: Windows XP
Version 5.1.2600 (Service Pack 3)
Number of processors #1
==============================================
>Drivers
==============================================
0x82356FA9 unknown_irp_handler, size: 87 bytes
!-->[Hidden Driver] 0x82386F38 00000212, size: 0 bytes
==============================================
>Stealth
==============================================
0x8235BB52 Page with executable code [ ETHREAD 0x82340DA8 ] TID: 112, size: 1198 bytes
0x8235A925 Page with executable code [ ETHREAD 0x82340610 ] TID: 124, size: 1755 bytes
0x8235890D Page with executable code [ ETHREAD 0x8193D030 ] TID: 304, size: 1779 bytes
0x823595C7 Page with executable code [ ETHREAD 0x82340DA8 ] TID: 112, size: 2617 bytes
0x8235712B Page with executable code [ ETHREAD 0x823C8740 ] TID: 8, size: 3797 bytes
0x82356028 Page with executable code [ ETHREAD 0x82340DA8 ] TID: 112, size: 4056 bytes
0x82359309 Unknown thread object [ ETHREAD 0x82340DA8 ] TID: 112, size: 600 bytes
0x82359A21 Unknown thread object [ ETHREAD 0x82340898 ] TID: 120, size: 600 bytes
0x8235A901 Unknown thread object [ ETHREAD 0x82340610 ] TID: 124, size: 600 bytes
==============================================
>Hooks
==============================================
atapi --> [IRP_MJ_INTERNAL_DEVICE_CONTROL], Type: Address Change 0x82356FA9 [unknown_irp_handler]
==============================================
>Callbacks
==============================================
Callback with handler outside any module :: 0x823595DC, Type: CreateProcess
Callback with handler outside any module :: 0x8235B3B2, Type: LoadImage
The same filtering method used even less hardcore than in TDL4, the same hook in atapi irp handlers covered by the same memory forging technique (dr0 + KiDebugRoutine callback). I don't see any blacklists added. Tools mentioned by HackJack works normally. However in memdump he provided I've found a numerous ImageExecutionOptions related entries, so this blocking can be caused by something else (don't forget about McAfee kernel mode junk), for example other malware, or by 3rd party security tools widely used by HackJack according to memory. Rootkit does not survived mbr fix (in my case through RkU). As expected most of HackJack troubles were related to his machine configuration/additional software or by his actions. This is updated MaxSS yes, but not cardinally.
Most of mysteries solved.
Fixmbr didn't worked for HackJack because there is nothing to fix in mbr, since code stay untouched and rootkit only adds new partition entry and sets it active. Fixmbr not supposed to fix mbr data and it didn't know how to do that obviously. Fixboot is not recommended to use at all with this rootkit because it will try to fix rootkit allocated partition (by following partition entry set as active) boot code resulting in unbootable system. So basically there are two options left - fixing with rootkit removers or booting from CD with partition manager to do manual fix (the recommended way).