ImportPatcher.41 - Find and fix dependency problems

[Dibya]

I am patching avrt.dll of Vista with import patcher any one know which api can be used for replacing following. I need it for FF54

[Patches needed]
avrt.dll=Functions  
[ntdll.dll]
NtAlpcConnectPort=
NtAlpcSendWaitReceivePort=
AlpcGetMessageAttribute=
AlpcInitializeMessageAttribute=
 

[Patches needed]
dwmapi.dll=Functions  
[ntdll.dll]
EtwEventUnregister=
WinSqmIsOptedIn=
EtwEventRegister=
WinSqmAddToStream=
EtwEventWrite=
[USER32.dll]
SfmDxBindSwapChain=
SfmDxReleaseSwapChain=
IsThreadDesktopComposited=
SetWindowCompositionAttribute=
DwmGetDxSharedSurface=
LogicalToPhysicalPoint=
IsProcessDPIAware=
IsTopLevelWindow=
GetWindowCompositionAttribute=
[KERNEL32.dll]
RegGetValueW=

I need more help with some windows media foundation files but please help me now with this one .

Edited June 6, 2017 by Dibya

[jumper]

Because the end product isn't likely to work, I wouldn't put much time into it initially. Use any function with a shorter name.

Once you get past the loader, if one of these functions actually gets called, that is the time to look for replacements that match parameter counts and return/LastError values on error.

[Dibya]

Okay

[Dibya]

I wish import patcher can fix TLS issue in Firefox

[jumper]

ImportPatcher does patch and/or report a few things in the headers other than just imports, so it'll be easy to also detect TLS directory entries in DLLs (not EXEs) and zero them if requested. Do these Firefox problem DLLs export any common functions (like plugins do) that can be used to identify them?

[hotnuma]

On 6/6/2017 at 7:19 AM, Dibya said:

[Patches needed]
IsTopLevelWindow=

https://jellevergeer.com/the-undocumented-istoplevelwindow-api/

https://stackoverflow.com/questions/16973995/whats-the-best-way-do-determine-if-an-hwnd-represents-a-top-level-window

It seems to be something like :

BOOL IsTopLevelWindow(HWND hWnd)
{
   return (hWnd==GetAncestor(hWnd, GA_ROOT));
}

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-getancestor

Edited February 16, 2019 by hotnuma

[Dibya]

1 hour ago, jumper said:

ImportPatcher does patch and/or report a few things in the headers other than just imports, so it'll be easy to also detect TLS directory entries in DLLs (not EXEs) and zero them if requested. Do these Firefox problem DLLs export any common functions (like plugins do) that can be used to identify them?
 

Nope only TLS function

[jumper]

I thought we had determined that the problem was DLLs using the TLS data type (resulting in a TLS directory entries) instead of calling the TLS functions (which work just fine).

I think you are referring to this post:
Vista's explicit-load-of-DLL's-that-use-implicit-TLS problem might be solvable by simply adding the delayed dependency to the import table. I'm working on adding support for this, plus automation and more to ImportPatcher.

and this post:
If we add a large implicit TLS data section to Kernel32.dll, that should solve the thorny reallocation problem. Then LoadLibrary just needs to properly initialize the TLS selector index.

[hotnuma]

I tried ImportPatcher under XP and I can't really understand how it works.

First, I've built a test.exe program which calls GetFileInformationByHandleEx
and targeting _WIN32_WINNT=0x0601

I've built a mod.dll containing a dummy bla function with the same arguments that
the real GetFileInformationByHandleEx

Now I want to replace the missing GetFileInformationByHandleEx with
the dummy bla function from mod.dll :
 

[Patches needed]
test.exe=Functions    
[KERNEL32.dll]
GetFileInformationByHandleEx=bla  * not found

I tried also : GetFileInformationByHandleEx=mod.bla
and different other things but I always get "not found".

I'm missing something.  
 

[jumper]

Sorry, you can't do what you're trying to do. :(
Imports from Kernel32.dll have to come from Kernel32.dll...
...unless you redirect them _all_ to mod.dll:
[DLL replacements]
KERNEL32.dll=mod.dll

And then mod.dll has to handle _all_ Kernel32 APIs (it can export-forward them back to Kernel32.dll, however).

[hotnuma]

I understand, that's how xompie do it. :-P

So, I tried with xompie's kernelxp.dll this way :
 

[DLL replacements]
KERNEL32.dll=kernelxp.dll

It works just fine. Thanks a lot. :-D 

 

Edited February 17, 2019 by hotnuma

[-SnooPY-]

Can anyone clarify the situation with [Export forward replacements]? Please advise what can be done to make this section disappear? Thanks a lot.

I try to patch Revo Uninstaller and get the following log:

============================================================

[Patches needed]
...
ntext.dll=Forwards  
KERNELXP.dll=Forwards  
...
RevoUninPro.exe=No problems found.
[Export forward replacements]
ntdll.ExpInterlockedPopEntrySListEnd=
ntdll.ExpInterlockedPopEntrySListFault=
ntdll.ExpInterlockedPopEntrySListResume=
ntdll.NtAddDriverEntry=
ntdll.NtApphelpCacheControl=
ntdll.NtDeleteDriverEntry=
ntdll.NtEnumerateDriverEntries=
ntdll.NtGetTickCount=
ntdll.NtModifyDriverEntry=
ntdll.NtQueryDriverEntryOrder=
ntdll.NtSetDriverEntryOrder=
ntdll.NtUnloadKey2=
ntdll.NtWaitForMultipleObjects32=
ntdll.NtWow64CsrAllocateCaptureBuffer=
ntdll.NtWow64CsrAllocateMessagePointer=
ntdll.NtWow64CsrCaptureMessageBuffer=
ntdll.NtWow64CsrCaptureMessageString=
ntdll.NtWow64CsrClientCallServer=
ntdll.NtWow64CsrClientConnectToServer=
ntdll.NtWow64CsrFreeCaptureBuffer=
ntdll.NtWow64CsrGetProcessId=
ntdll.NtWow64CsrIdentifyAlertableThread=
ntdll.NtWow64CsrNewThread=
ntdll.NtWow64CsrSetPriorityClass=
ntdll.NtWow64DebuggerCall=
ntdll.NtWow64GetNativeSystemInformation=
ntdll.NtWow64QueryInformationProcess64=
ntdll.NtWow64QueryVirtualMemory64=
ntdll.NtWow64ReadVirtualMemory64=
ntdll.RtlAcquirePrivilege=
ntdll.RtlAddVectoredContinueHandler=
ntdll.RtlAllocateActivationContextStack=
ntdll.RtlCopyMappedMemory=
ntdll.RtlFormatMessageEx=
ntdll.RtlFreeActivationContextStack=
ntdll.RtlGetCriticalSectionRecursionCount=
ntdll.RtlIsCriticalSectionLocked=
ntdll.RtlMultipleAllocateHeap=
ntdll.RtlMultipleFreeHeap=
ntdll.RtlReleasePrivilege=
ntdll.RtlRemoveVectoredContinueHandler=
ntdll.RtlSetUnhandledExceptionFilter=
ntdll.ZwAddDriverEntry=
ntdll.ZwApphelpCacheControl=
ntdll.ZwDeleteDriverEntry=
ntdll.ZwEnumerateDriverEntries=
ntdll.ZwGetCurrentProcessorNumber=
ntdll.ZwLoadKeyEx=
ntdll.ZwModifyDriverEntry=
ntdll.ZwQueryDriverEntryOrder=
ntdll.ZwQueryOpenSubKeysEx=
ntdll.ZwSetDriverEntryOrder=
ntdll.ZwUnloadKey2=
ntdll.ZwWaitForMultipleObjects32=
advapi32.AddMandatoryAce=
ntext.RtlAddVectoredContinueHandler=
kernel32.BaseCheckRunApp=
kernel32.BasepCheckBadapp=
kernel32.EnumSystemFirmwareTables=
fileextd.GetFileInformationByHandleEx=
kernel32.GetSystemFileCacheSize=
kernel32.GetSystemFirmwareTable=
kernel32.IsNLSDefinedString=
shlwapi.PathIsValidCharA=
shlwapi.PathIsValidCharW=
advapi32.RegCopyTreeW=
advapi32.RegDeleteKeyExA=
advapi32.RegDeleteKeyExW=
advapi32.RegDeleteTreeA=
advapi32.RegDeleteTreeW=
advapi32.RegGetValueA=
advapi32.RegGetValueW=
advapi32.RegLoadMUIStringA=
advapi32.RegLoadMUIStringW=
ntext.RtlRemoveVectoredContinueHandler=
fileextd.SetFileInformationByHandle=

============================================================

Edited August 30, 2019 by -SnooPY-

[jumper]

Add a valid forwarding definition to each line.

Don't use XP extenders (KernelXP.dll, ntext.dl) in 9x; use KernelEx instead if ImportPatcher isn't sufficient.

[windows2]

Hello,please new link of :

ImportPatcher.41.7z
debugging DLL: IPstub.zip
Drugwash's API Parameter Count v1.0.1.0

[Drugwash]

Latest version of API Parameter Count is 1.0.2.0.
Initial release can be found in the large package here.
A repackage can be found here. It adds previous versions 1.0.0.0 and 1.0.1.0 as scripts only (in the source folder) and a fixed section name in the ini file. Also, due to a programming error the application cannot unpack the internal copy of the ini file upon first start, remaining in a file open loop until fed with a proper path, therefore a copy of the ini has been placed in the executable folder making it easy for the user to select it.