Jump to content











Photo
* * * * - 3 votes

PassPass - Bypass the Password


  • Please log in to reply
430 replies to this topic

#401 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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.



#402 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.


#403 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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? :unsure:

 

:duff:

Wonko  



#404 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.



#405 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 August 2021 - 03:40 PM

I gave link to new version.
Just unpack with 7zip and look for /_iso/docs/passpass folder

#406 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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.

 

:duff:

Wonko



#407 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 05 August 2021 - 05:17 PM

Yep

#408 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 August 2021 - 05:33 PM

Yep

 

It is IMHO an exceptionally ugly :ph34r: 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

 

:duff:

Wonko



#409 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

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



#410 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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):

  • Original pattern: 0F 1F 44 00 00 49 3B C6
  • Patched pattern: 90 90 90 90 90 90 33 C0

 

I'm hesitant about x86 because I only have the DLL and not testing system, but this should be analogous:

  • Original pattern: 3B C6 0F 84 63 FB FF FF
  • Patched pattern: 33 C0 0F 84 63 FB FF FF

 

 

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.


#411 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 06 August 2021 - 10:45 PM

Win11 64 bit

 

So you are correct!  The previous patch does not work but your new patch should work.

 

Attached Thumbnails

  • win1164.JPG
  • win1164asm.JPG


#412 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.



#413 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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???



#414 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.


#415 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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?



#416 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.


#417 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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)



#418 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.


#419 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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...)  



#420 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.


#421 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

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.



#422 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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.

 

Spoiler

Attached Files


  • Tokener likes this

#423 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

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



#424 ner0

ner0

    Member

  • Advanced user
  • 83 posts

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-2016 2016-2019 OS.

 

Spoiler

I mistakenly typed Windows Server 2012-2016 when in fact I meant Windows Server 2016-2019.



#425 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

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.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users