June 6, 20179 yr 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, 20179 yr by Dibya
June 7, 20179 yr Author 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.
February 16, 20197 yr Author 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?
February 16, 20197 yr 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, 20197 yr by hotnuma
February 16, 20197 yr 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
February 16, 20197 yr Author 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.
February 17, 20197 yr 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.
February 17, 20197 yr Author 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).
February 17, 20197 yr 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, 20197 yr by hotnuma
August 30, 20197 yr 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, 20197 yr by -SnooPY-
August 31, 20197 yr Author 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.
December 22, 20205 yr Hello,please new link of : ImportPatcher.41.7z debugging DLL: IPstub.zip Drugwash's API Parameter Count v1.0.1.0
December 22, 20205 yr 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.
Create an account or sign in to comment