RtlFindLdrpHandleTlsData failed

[kotori2]

• MajorVersion: 10
• BuildNumber: 26100

RtlFindMemoryBlockFromModuleSection returned failed, DllBase seems to be valid. I guess the Feature bytes could be invalid. How can I find that?

[kotori2]

I think in this piece of code, it was searching for LdrpHandleTlsData function. However, the function have a different signature since the very early version of 22H2 (somewhere between 10.0.22621.317 and 10.0.22621.2134). So the way of searching for raw bytes is not reliable.

An insanely unreliable workaround for this could be:
RtlFindLdrpHandleTlsData:

		if (MmpGlobalDataPtr->NtVersions.BuildNumber >= 26100) {
#ifdef _WIN64
            Feature = "\x39\x05\xfa\x50\x1c\x00";
            Size = 6;
            OffsetOfFunctionBegin = 0x60;
#else
            return STATUS_NOT_SUPPORTED;
#endif
        }

RtlFindLdrpReleaseTlsEntry:

        if (MmpGlobalDataPtr->NtVersions.BuildNumber >= 26100) {
#ifdef _WIN64
            Feature = "\x74\x19\x48\x8b\x08";
            Size = 5;
            OffsetOfFunctionBegin = 0x2F;
#else
            return STATUS_NOT_SUPPORTED;
#endif
        }

I'm going to find another way around for these two functions.

[bb107]

Hi. Please reference this link to find a pattern.
By the way, search by pattern is the only way to find these private routines in ntdll. If the network is always available, you can download and parse pdb file for ntdll, implements please reference BlackBone.

[zema1]

This repo provide a new method to find the addr of LdrpHandleTlsData:

https://github.com/howmp/LdrpHandleTlsData

And it's reference:
https://github.com/chainreactors/wiki/blob/a471d9a237da832a06f694f40a17b5d000d9f4fa/docs/blog/todo/IoM-%E4%BB%8E%E4%B8%80%E4%B8%AA%E5%B4%A9%E6%BA%83%E5%BC%80%E5%A7%8B%E7%9A%84%20PE%20Loader%20%E6%95%91%E8%B5%8E%E4%B9%8B%E6%97%85.md

[kotori2]

I was working on finding pattern for Windows 10/11 series, and was just about to fire a PR about that. If we are using pattern-based search, we can narrow the code down to three patterns for LdrpHandleTlsData, and one pattern that covers all OS versions for LdrpReleaseTlsEntry, by searching for the stack operations in the function prologue.

@zema1 These two references seem to be using different paths. One search for LdrpHandleTlsData string in exception handler, and parse the C_SCOPE_TABLE reference in .rdata, and parse the UNWIND_INFO_HDR and RUNTIME_FUNCTION (I didn't look into the details). The blog post searched for LdrpInitializeTls instead.

I have an easier idea. After we located the C_SCOPE_TABLE for LdrpAllocateTls$filt$0, we already get a start & end pointer to this exception. We can simply search up from 18005585E, until we reach the 0xCC padding. I will try to implement this idea later when I have time.

.rdata:0000000180142254                 C_SCOPE_TABLE <rva loc_18005585E, rva loc_18005587C, \
.rdata:0000000180142254                                rva LdrpAllocateTls$filt$0, rva loc_18005587C>

[zema1]

@kotori2 I have tried the method you mentioned above. It seems that some version of ntdll has different layout.

Test ver: Windows7 x64 6.1.7601.21861

• It use 0x90 as memory padding
• It jumps to other position quickly, the seh handler is located at the new position, which means we can't simply search up via SCOPE_TABLE's reference.

ext:0000000078E8B934                            ; ---------------------------------------------------------------------------
.text:0000000078E8B935 90 90 90 90 90 90 90 90 90                 align 20h
.text:0000000078E8B935 90 90                      ; } // starts at 78E8B91C
.text:0000000078E8B935                            SbpDeterimineDllContext endp
.text:0000000078E8B935
.text:0000000078E8B940
.text:0000000078E8B940                            ; =============== S U B R O U T I N E =======================================
.text:0000000078E8B940
.text:0000000078E8B940
.text:0000000078E8B940                            ; __int64 __fastcall LdrpHandleTlsData(__int64)
.text:0000000078E8B940                            LdrpHandleTlsData proc near             ; CODE XREF: LdrpLoadDll-398↑p
.text:0000000078E8B940                                                                    ; LdrpLoadImportModule+213F↓p
.text:0000000078E8B940                                                                    ; DATA XREF: ...
.text:0000000078E8B940
....
....
.text:0000000078E8B940
.text:0000000078E8B940                            ; __unwind { // __C_specific_handler
.text:0000000078E8B940 48 89 4C 24 08                             mov     [rsp+arg_0], rcx
....
....
.text:0000000078E8B98C
.text:0000000078E8B992
.text:0000000078E8B992                            loc_78E8B992:                           ; CODE XREF: LdrpHandleTlsData+39985↓j
.text:0000000078E8B992 33 C0                                      xor     eax, eax        ; Logical Exclusive OR
.text:0000000078E8B992
.text:0000000078E8B994
.text:0000000078E8B994                            loc_78E8B994:                           ; CODE XREF: LdrpHandleTlsData+11EF7↓j
.text:0000000078E8B994                                                                    ; LdrpHandleTlsData+39A5D↓j ...
.text:0000000078E8B994 48 81 C4 A0 00 00 00                       add     rsp, 0A0h       ; Add
.text:0000000078E8B99B 41 5F                                      pop     r15
.text:0000000078E8B99D 41 5E                                      pop     r14
.text:0000000078E8B99F 41 5D                                      pop     r13
.text:0000000078E8B9A1 41 5C                                      pop     r12
.text:0000000078E8B9A3 5F                                         pop     rdi
.text:0000000078E8B9A4 5E                                         pop     rsi
.text:0000000078E8B9A5 5B                                         pop     rbx
.text:0000000078E8B9A6 C3                                         retn                    ; Return Near from Procedure
.text:0000000078E8B9A6
.text:0000000078E8B9A6                            ; ---------------------------------------------------------------------------
.text:0000000078E8B9A7 90 90 90 90 90 90 90 90 90                 align 10h
.text:0000000078E8B9A7                            ; } // starts at 78E8B940
.text:0000000078E8B9A7                            LdrpHandleTlsData endp
.text:0000000078E8B9A7

I also tested the first method implemented in https://github.com/howmp/LdrpHandleTlsData. It worked well by now.
I'm not quite good at c++. I hope that will help you a little and still looking forward to you PR @kotori2

[kotori2]

@zema1 Thanks, I think we can go by pattern based on older systems (since they are EOL by now and unlikely to change).
I tested my theory and it works well on Windows 11 24H2. Going to do more tests on older Windows 10, as I found I made a mistake in my dll scraper and it will only spit out the very first UBR of a minor version.

[kotori2]

Hi thread, long time no see.
After my last comment, I realized that there's a major flaw in my Windows Update crawler that will only actually save the very first major version of ntdll. e.g., (10.0.26100.1).
After some digging of Windows Update mechanisms, I realized that I need to install patches to get the latest version. But extracting and applying patches is actually a very complicated procedure. With the help of some scripts online, I ended up with a ~500 lines project that only extracts ntdll from every Windows versions.
Also I have something to confess: I made a mistake and searched for LdrpAllocateTlsBlock instead of LdrpHandleTlsData in my last comment. But actually the process for these two function are almost exactly the same.
I just created a PR, and I will mark it as ready once all tests are passed.