430 replies to this topic

[Holmes.Sherlock]

I have tried to analyze the kon-boot. After unziping the kon-boot.iso file, I got a new file named Bootable_1.44M.img.

Next boot to a Linux Mint live cd and use the following commands to mount/unzip the img file, but there are still no files inside the mounted folder.

 

You may want to take a look at 'El-Torito - Bootable CD ROM Format Specification v1.0'. To extract the boot image, this may come handy (of course, unless our resident Finder points out to something better).

[Wonko the Sane]

Well, no.
The point besides the fact that the Kon-Boot floppy image has NOT a filesystem, AFAIK - and besides being potentially illegal to reverse it - I believe that it uses a DIFFERENT approach, as such I would advise AGAINST attempting to reverse it, as it it will - set aside the fun of it - completely unlike useful.
BTW considering:
http://reboot.pro/topic/8027-kon-boot/
that it was written in pure assembler, good luck in attempting to reverse it.

All in all if a user with Windows 8.1 64 bit with latest update forgets his/her password there are other ways to workaround the issue, and to be fair he/she should be able to spend US$ 15 for a Kon-Boot license.

As expected, the version Astr0baby found a patch for is an early version, possibly earlier than the ones Steve6375/Joakims posted, and BOTH of them are not valid for the newish version of the .dll 6.3.9600.17415.


Wonko

[steve6375]

@linda

I have same dll 6.3.9600.17415 with same MD5 on my Win 8.1 system.

I have looked with IDA and it has the byte pattern 49 3b c6 0F 85 (in at least two places) in the password validate code so it looks like it should work.

Maybe you could compare the patched dll with the unpatched dll using windows

fc /b  msv1_orig.dll  msv1_patched.dll

to see which bytes have been changed. Are you testing on a real machine?

 

P.S. You are testing with a local account (i.e NOT using your online email address to log in)?

Edited by steve6375, 24 May 2015 - 08:52 PM.

[linda]

@steve6375

It's a microsoft account. later on I test with a local account and it works!

Is it possible to work out a patch for microsoft account login?

[steve6375]

@steve6375

It's a microsoft account. later on I test with a local account and it works!

Is it possible to work out a patch for microsoft account login?

Thanks for wasting an hour of my life!

re. patching email account login, I don't know where the patch point is or how to recognise it.

[Wonko the Sane]

@linda

Not unexpected, see:

http://reboot.pro/to...sword/?p=190637

 

@Steve6375

A question I have for you or for anyone else with a working Windows 8/8.1 install is the following.

How does the "microsoft account login" behave if there is no Internet Connection?

 

Real life situation:

A few weeks ago a bunch of (mindless) road workers managed to cut the telecom cable covering the area I work in (they were planting road steel barrier supports and managed to cut the cable in two or three points ).

It took 4 days to the telecom company to find the cuts and repair them.

We temporarily managed e-mails fine through smartphones, and the second day I bought a little wireless cellular router that allowed us to connect the POS, but all the PC's (obviously) worked fine while not connected to the Internet and all in all it was just a minor nuisance that didn't affect much the daily workflow.

What would happen in the same situation if we had 8/8.1's installed?

Is there  a way to log in without a wired or wireless connection to the Internet?

 

Wonko

[steve6375]

With no internet connection you can still log-in (otherwise you would be stuck if you had a laptop somewhere were there was no internet).

It's just that the code path in the dll  (if it is in that dll?) is obviously different for this type of account.

[linda]

As far as I know, there are only two softwares that can unlock Windows 8 microsoft account: Kon-Boot and PCUnlocker. We might have to study these two sofwares to find out a way to get PassPass to work with Microsoft account.

I guess Microsoft account works similar to domain logons: if the domain controller is not available but the entered password matches the locally stored one, Windows allows logon. Even more, Windows does not contact the domain controller right away if the cached password matches, but it will validate the password on the domain if it doesn't, in case you changed it.

Of course, you have to be connected when you log in to Microsoft account for the first time.

[Wonko the Sane]

Yep, I will reword as follows.

Given that when there is no connection to the Internet a "local" something is used instead, does PassPass fail for a Microsoft Account in the same way with the PC connected or not connected?

 

Wonko

[linda]

I used PCUnlocker to reset a Microsoft account password on a virtual machine for testing. After comparing the registry before and after password reset, I found out that PCUnlocker made a change with the "CachedLogonInfo" vaiue in the following registry key location:

HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\<rid>

It's likely that the Microsoft account login is cached and stored in "CachedLogonInfo". Obviously it's encrypted using a different algorithm as the local account. After password reset, I can use the password given by PCUnlocker to log on Microsoft account successfully without Internet connection.

 

I hope this would be helpful for us to work out a patch for PassPass.

[Wonko the Sane]

Well, MOST of the point about the PassPass approach is that of NOT resetting the password and/or changing *anything* on the system  that cannot be reverted by simply unpatching.

 

PassPass is not the *only* way in the world, if the scope is resetting the password (as opposed to logging in on a system WITHOUT changing any password) you should look for other programs/methods.

 

Still, more or less there must be a "comparison" between the locally cached password and the one the user supplies, the whole point is finding out:

1) if it also resides in msv1_0.dll (or in which file it resides)

2) if it is also patchable

 

Wonko

[linda]

@Wonko

Thank you for pointing me in the right direction.

[knjor]

is there update for windows 10

 

thanks

[Holmes.Sherlock]

is there update for windows 10

 

No, we haven't updated it long.

[knjor]

No, we haven't updated it long.

ok thanks

 

i hope that you have time to do that

 

With best wishes for success

[ner0]

This information might be useful: https://github.com/c...tion/issues/122

Or this: https://github.com/c...dules/unlock.py

[ner0]

After a little stroll through IDA, I was able to patch NtlmShared.dll successfully and login without password.

 

This is the NtlmShared.dll file version that I tested with:

• Windows 10 Pro (x64) v1607 (build 14393.447)
• NtlmShared.dll v10.0.14393.0
• MD-5: 638B97E9B2C57097F148EC7C6D0E60FB
• SHA-1: E97A6A9583D3BA19982CF42ADB4220A069518676

 

Some images follow...

 

 

Graphical view from MsvpPasswordValidate function

 

 

Text view from MsvpPasswordValidate function

 

 

Hex view for the jump (JNZ) to be patched in MsvpPasswordValidate function

 

 

To sum it up, in my particular case, I patched, with simple NOPs, 12 bytes at address 0x2AE8:

• Originally: 0F 85 18 FB FF FF
•   Patched: 90 90 90 90 90 90

 

Hope this can be ported to the batch script! 

 

 

P.S: I'm not sure if this is common knowledge or not but if you try to peek at the file while in the system and in it's original path (System32) then the contents of the file will be different from what they actually are and you possibly won't find that particular instruction at that address.

Edited by ner0, 26 November 2016 - 07:51 PM.

[ner0]

For some odd reason I can't get cat to work with any binary file within Windows folder.

Is there a limitation that I don't know about?

 

For example, this would have to work for any executable file:

cat --hex --locate=\x4D\x5A\x90 (hd0,1)/windows/explorer.exe

Yep, seems like something is terribly wrong here:

 

Edited by ner0, 26 November 2016 - 09:44 PM.

[Wonko the Sane]

Maybe it is one of those queer WOW64/whatever redirections/links/etc.?

Try getting the extents of the file with the blocklist command, and then try to cat the extents.

 

Then try checking the extents with a Windows tool capable of reading the $MFT directly, let's say DMDE.

 

About the move of the function to NtlmShared.dll, very good to know

 

It would be not a problem to add that to the PassPass (or to a separate PassPass10, which I would find a better idea), but I believe that it would be a "moving target", in the previous OS, besides the "generic, good for all" 32-bit patch, also the patches for the 64 bit versions are a handful (i.e. there are not so many versions of msv1_0.dll ), with the Windows 10 number of releases it is probable that you will never be fast enough or will need tens of different patches for tens of versions of the file.

 

Wonko

[ner0]

I forgot to mention that I was having that problem with a virtual machine (vmware).

Unfortunately I lost my patience with the VM having that specific issue and since it didn't have any particular setup in place I just ditched it and created a new VM from scratch. That solved the problem for good. I would have liked to understand the issue and fix it but I was afraid I was going to lose too much time with it. Thanks for the tips though, never heard of DMDE before, I'm sure it will come in handy at a later date.

 

As for the question of having to update the patching patterns very frequently, I guess we'll have to wait and see.

For the moment I did a different version of PassPass,  it borrows much of the code but I changed it for simplicity (in my perspective) and also because it didn't work at all with G4D v0.4.6, and I also got rid of 'wenv' in the process.

 

Before I forget, for Win10 x86 this is the file tested:

• Windows 10 Pro (x86) v1607 (build 14393.0)
• NtlmShared.dll v10.0.14393.0
• MD-5: CDBCB3105D8C0B6FC891DE71A98CDD51
• SHA-1: 4E66D1F76499C5D3C706A620E85AC5EC2DADF900

Here also I patched with NOPs 12 bytes at address 0x2B90:

• Originally: 0F 85 98 FB FF FF
•   Patched: 90 90 90 90 90 90

 

Now, I'm trying to figure out how to add attachments to my posts, because I don't see where that works...

I guess I'll throw an external link then:

 

ByePass_v1.0.0.7z (2KB)

 

 

PS: I took the liberty of updating PEPassPass: http://reboot.pro/to...spass/?p=200890

Edited by ner0, 27 November 2016 - 07:17 PM.

[Wonko the Sane]

Then most probably it was an issue with some kind of caching of the VM, good that it was not a "permanent" issue .

 

You need a given number of posts to be able to attach files, but it's OK , there is some misconfiguration of the board (or whatever) that prevents attaching files to everyone (and that the Board Administrators cannot or don't have time to solve/correct).

 

From a quick look at it seems nice  , though - if I may - you could remove a few  > nul redirections by manipulating the debug settings, compare your script with the no-wenv version by Chenall:
http://reboot.pro/to...sword/?p=188197

 

JFYI, the "base" .dll version detecting subroutine:

http://reboot.pro/to...nd-dll-version/

could (please read as should have been)  modified/updated to get a more exact dll version since Windows 8 (or 8.1 cannot remember) came out as - if I recall correctly - there were issues also with some of those .dll's versions, maybe this extension to 10 it will be the right occasion to do so.

 

I lost count if Holmes.Sherlock's version is the updated one or if Steve6375's fork/version has some additional patterns, if you have time do recheck this.

 

Wonko

[ner0]

I took a look at Chenall's version and could see the improvements.

For the moment I won't bother with it but I think you're right that the file version check mechanism might need to be improved and extended to include build version, although I don't see a problem with it at the moment, even though I've read some posts where people complained that it didn't work in some instances. At the moment I'm just focusing on Windows 10 / Server 2016 and have yet to encounter an issue where the file version detection isn't appropriate or the instruction's pattern doesn't fit. Here are a few other examples that I was able to download from the internet and worked as well as the latest DLL version:

 

NtlmShared.dll v10.0.10240.16384 (x86)

SHA-1: CB748DDEAB908AF5BC46EFAD60AC2470C6D02A68

MD-5: 21FC7542794BD83FF23BBED60AF1E60A

 

NtlmShared.dll v10.0.10240.16384 (x64)

SHA-1: A1ACE4B1992E3B5ABAB25B031AD57146BBA99DF9

MD-5: 151631EE7C78521506DE1A0BA0651606

 

NtlmShared.dll v10.0.10586.0 (x64)

SHA-1: 4E9C42B836969652AA105C8D95812CD4DC98979F

MD-5: 2FE4D1704AD2A81D744F3D627C002BAA

 

 

If someone encounters a non-working case I would just ask them to upload a zipped copy of their NtlmShared.dll (or msv1_0.dll if earlier than Win10) so that I could check if there was a change in the function's instruction and update accordingly.

Edited by ner0, 28 November 2016 - 11:57 AM.

[ner0]

I have done a bit more testing and I've found an issue with the way 64/32bit is determined. This might be behind some of the issues reported in this topic where PassPass wouldn't work but manually patching the same bytes would.

For example, I installed Vista 32 bit and PassPass function for architecture detection is identifying the wrong one.

grub> cat --locate=\x64\x86 --number=1 (hd0,0)/Windows/System32/msv1_0.dll
 27986
grub> echo %@retval%
1

and since we have:

if "%@retval%"=="1" goto :64BitPatch

This will jump to the 64bit patterns instead of the 32bit ones because, by chance, this particular DLL has one instance of \x64\x86 inside the whole DLL (which is curious that doesn't happen more often).

 

It should have been searching exactly in the PE header only and nowhere else, this would be more appropriate I guess:

cat --locate=\x50\x45\x00\x00\x64\x86 --number=1 (hd0,0)/Windows/System32/msv1_0.dll

Edited by ner0, 29 November 2016 - 11:53 AM.

[Wonko the Sane]

Yep .

The generic issue with this kind of stuff is that the ones actually "knowing what to do"  usually (since they also know where their passwords - besides their towels - are ) actually *never* or almost never *need* this kind of tricks, and when they need it they can actually do it from command line alright.

On the other hand the "end users" of this kind of solutions tend to be poor morons less advanced users that by fiddling senselessly with their PC got locked out of it and come here in panic.

Both kind of users however never or almost never report what was asked since day one, i.e. the EXACT version of the OS and dll for which the patch worked (or failed to work).

Without this data it is difficult or impossible to make an adequate "database" of dll's and their versions.

 

Please note how this info has been asked for since day one (JFYI , EXACTLY because I suspected that before or later the *need* for such a database would have arisen) and there was already enough bickering about this request.

 

The "more restrictive" detection is a good step forward  BUT to be picky (as I am) you fall in the same trap, you didn't report which EXACT version of the .dll confused the detection.

 

I believe additionally that limiting the "range" would be (slightly) faster, *like*:

cat --locate=\x50\x45\x00\x00\x64\x86 --length=512 --number=1 (hd0,0)/Windows/System32/msv1_0.dll

 

(I know that the above 512 is "arbitrary" and in theory it should be the value of e_lfanew + 6 bytes, but I believe that no file has a MS-DOS stub larger than 240 or 256 bytes and anyway the time to load the first sector should be the same as that of a lower value, but at least this way we avoid scanning the whole fine when the pattern is not found at the beginning) 

 

Wonko

[ner0]

For the first part of your answer, I think I understand your grief but can't help but notice that it is somewhat off topic in relation to my post, and I conclude that either you didn't understand what I said or ignored it for the sake of ranting.

 

I also think that you got it backwards, it's not that I'm suggesting a "more restrictive detection", as you put it, it's more that the original script has a BAD detection. I don't know how someone could have thought that it was reasonable to use only 4 bytes as a sensible way to id anything, let alone the architecture in the PE header. Curiously, all along, no one bothered to correct it and maybe avoid a third of the so called bickering.

 

It doesn't bother me that you're picky, but it does somewhat when you do so for no apparent reason. It is completely beside the point which DLL version I'm using; it wouldn't, and doesn't, matter in the least given that the problem is in the script and nowhere else.

 

As for restricting the length of the search body, I thought about that too and agree. You also could lose the --number=1 part because it serves no purpose, so I think that the correct way would be:

cat --locate=\x50\x45\x00\x00\x64\x86 --length=512 (hd0,0)/Windows/System32/msv1_0.dll