Mapping the API mapping/code redundancy
2024-11-30 03:23:33 Author: www.hexacorn.com(查看原文) 阅读量:8 收藏

In my last post I have shown that some of the shell32.dll functions are now mapped to windows.storage.dll.

This sort of API mapping, as well as blatant code redundancy present in many Windows binaries is not new, and we have seen many instances of it over the years:

  • Windows API sets
  • gdi32.dll and gdi32full.dll
  • gdi32full.dll and win32u.dll
  • combase.dll and ole32.dll
  • kernel32.dll and KernelBase.dll
  • IEAdvpack.dll and advpack.dll
  • crtdll.dll, msvcirt.dll, ucrtbase.dll and their many, many versions over the years
  • ntdll.dll and ntoskrnl.exe (user mode vs. kernel mode mapping)

and so on, and so forth.

It is probably not surprising that after that latest discovery it was only natural for me to build a list of APIs (API names) that are shared between many libraries to see if I can discover more interesting bits.

Looking at the list of API names that appear to be shared between at least 2 DLL libraries on the Windows 11 24 H2 build – win11_24H2_list_64_shared.txt – one can immediately see a lot of interesting findings:

  • sqlite functions are exported by SearchIndexerCore.dll, StateRepository.Core.dll, winsqlite3.dll
  • apart from kernel32.dll and KernelBase.dll there is now also kernel.appcore.dll
  • code base of tcblaunch.exe and winload.exe seems to be overlapping a lot
  • edgehtml.dll replaces mshtml.dll

Unfortunately, I have not seen anything similar to ShellExec_RunDLL – a discovery that kicked off this research 🙁


文章来源: https://www.hexacorn.com/blog/2024/11/29/mapping-the-api-mapping-code-redundancy/
如有侵权请联系:admin#unsafe.sh