430 replies to this topic

[steve6375]

I have been following these posts and have modified the E2B version of PassPass to add the Win10 patch.

http://rmprepusb.blo...h-passpass.html

 

P.S. Since the full version number is found by the grub4dos script, why not display it on the screen to make it easier for the user to report it?

[Wonko the Sane]

Basically sometimes I sound like a grumpy old bastard exactly because I actually am a grumpy old bastard , but here I was trying to say that - for *some reasons* - there has been not enough (or not good enough) feedback by the userbase and this contributed to have not proper testing.
 
The thingy was originally half-@§§edly put together by Holmes.Sherlock at his first (or second) attempt to write a grub4dos batch and the (flawed) identification routine was overlooked by everyone, as it seemingly worked.
 
You are right saying that the identification routine is flawed, I was trying to say that - given that it is flawed - what is surprising is that noone before you happened to test it about the (unknown) version of the Vista .dll that you happened to test it against (thus detecting the issue).
 
This should mean that either the version you happened to use is a very "rare" one on real-world Vista installations (like I seem to remember there is a version of 7 .dll that is in practice nowhere to be found) or that the (already known to be scarce or sub-standard or both) feedback was even worse than what I thought .
 
 
 

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

 
That would be IMHO perfect. 
 
@Steve6375
Sure , the original "find dll version" displayed it, cannot say why Holmes (or you or both) removed that in PassPass (maybe in a good faith attempt to make the thing more user friendly? "it just works").
 

Wonko

[ner0]

You are right saying that the identification routine is flawed, I was trying to say that - given that it is flawed - what is surprising is that noone before you happened to test it about the (unknown) version of the Vista .dll that you happened to test it against (thus detecting the issue).
 
This should mean that either the version you happened to use is a very "rare" one on real-world Vista installations (like I seem to remember there is a version of 7 .dll that is in practice nowhere to be found) or that the (already known to be scarce or sub-standard or both) feedback was even worse than what I thought .

 

The DLL comes in a Windows Vista Business x86 (SP1) DVD, here's a copy:

 

msv1_0_v6.0.6001.18000_x86.7z (88KB)

[Wonko the Sane]

I would say that this should explain the reason why noone happened to report about it, it is version is v6.0.6001.18000 (longhorn_rtm.080118-1840).

The "normal" Vista files should be v6.0.6000.16386 (vista_rtm.061101-2205), it wouldn't surprise me in the least that the good MS  guys made a mess with naming or versions, (the SP1 version should be  v6.0.6001.something but also (vistasp1_ldr.something) ) but very likely most (of the few) people actually running Vista have on their "real" install (and had at the time PassPass was posted) already the SP2 version (that possibly has not the "coincidence bytes" ).

 

As a practical demonstration that sharing info is a good thing , since I have no Vista installs nor install media handy, I had a quick look around and found this page:

http://www.dllbang.com/dll/msv1_0_dll

which seems like a nice source to make an initial list of dll versions (though that page is only up to 7).

 

Wonko

[dencorso]

Just for the record... KB3198510 (for POSReady 2009, released this very month) includes msv1_0.dll v. 5.1.2600.7151 (xpsp_sp3_qfe.161011-0631); 137,216 bytes; MD5: 04B2DB58A3863400076BC5346CCB428E.

[Wonko the Sane]

Just for the record... KB3198510 (for POSReady 2009, released this very month) includes msv1_0.dll v. 5.1.2600.7151 (xpsp_sp3_qfe.161011-0631); 137,216 bytes; MD5: 04B2DB58A3863400076BC5346CCB428E.

And is it 32 bit or 64 bit?

 

Wonko

[ner0]

And is it 32 bit or 64 bit?

 

Wonko

 

If what the Wikipedia entry for POSReady 2009 says is correct...

Windows Embedded POSReady 2009

 

Based on Windows XP with SP3 (...)

source: https://en.wikipedia...d_POSReady_2009

 

...then I guess that we can assume it is 32-bit, since there is no SP3 for XP 64-bit.

Or maybe just because xpsp_sp3_qfe.161011-0631   

Edited by ner0, 30 November 2016 - 08:49 PM.

[Wonko the Sane]

Yep it was a rhetorical question, just for the fun of it and to show how even dencorso, who - besides being a friend - is usually very attentive and exact (and has a long history of properly tracking and identifying .exe and .dll versions) when asked to provide 4 pieces of info managed to provide only 3 of them.

 

Wonko

[steve6375]

@Holmes.Sherlock

I have improved the PassPass batch file a bit in v1.87d.
When you Restore the DLL file (after first backing it up), it will now check the first 512 bytes to make sure you are restoring the same file and same version.

[Wonko the Sane]

@Holmes.Sherlock

I have improved the PassPass batch file a bit in v1.87d.
When you Restore the DLL file (after first backing it up), it will now check the first 512 bytes to make sure you are restoring the same file and same version.

But is your port/fork still WENV based or are you now using the (better) WENV-less versions by Chenall (and/or the other WENV-less new thingy by ner0 - that has a few other changes including the "better" x86/x64 detection)?

 

Wonko

[ner0]

I take issue with the word "better" being quoted, it may not be much but the detection is better - that's a fact - no need to mince words

[steve6375]

It still uses wenv, but I have included the long byte string for 64-bit detection and also used a different patch instead of just NOPs (because six NOPS may not be unique and we can use a different unique sequence for different DLLs to avoid unpatching back the wrong code).

[Wonko the Sane]

I take issue with the word "better" being quoted, it may not be much but the detection is better - that's a fact - no need to mince words

Which is OK, of course, as I wrote "better" between double quotes not to understate its betterness, which is not doubted in the least.

As soon as a "real user" (within quotes) will actually be locked out of his/her Vista system AND the previous PassPass thingy with the flawed (without being inside quotes) detection routine will be reported as not working, AND your new version will solve the issue at hand I will gladly strip the quotes out of the "better".

You want me to state how your detection routine is more correct? It is.

You want me to state how your detection routine is more accurate? It is.

You want me to state how your detection routine is more elegant[1]? It is.

But is it better?

Unless the old one will actually be proved to be not "good enough", your "better" one will remain within quotes.

 

The base declaration of PassPass - at least the original version by Holmes.Sherlock - being a half-@§§ed grub4dos batch would otherwise be undermined.

 

@Steve6375

I don't know, the script by Chenall is IMHO much "better" (within quotes) and it is surprising to me that you didn't adopt it as a new base for your fork.

Would you be so kind to share your "better" (within quotes) patch pattern (as opposed to the few NOPs)?

Maybe someone would like to adopt it in a non-E2B version ...

 Or at least provide a link to your current version?

As a side-side note , I have noticed that the http://www.rmprepusb.com/site has become very, very  slow since some time, maybe you are having too much traffic or are serving too much third party contents and you need to upgrade the available bandwidth (or *whatever*)?

 

Wonko

 

 

[1] this latter also thanks to my semi-random idea to limit the search space, BTW

[ner0]

I didn't mean anything by it, I was half-joking anyway. But indeed there seems to be some twisted meaning to those quotes that I didn't properly understand until you explained in detail.  In any case, yes, the pattern that I suggested is better because the previous pattern is incomplete, but there is nothing elegant about it. And I think that I qualify as a "real user" (didn't I pass the Turing Test?), I did provide proof that the current version didn't work with at least one version of Vista, no matter how "rare". Honestly, the only thing undermining Holmes.Sherlock's script is you calling it half-assed every other day. But to be fair, I can't really comment on it being "good enough" because it didn't work for me on G4D 0.4.6 (as I stated earlier in one of the posts), and neither does it work on Windows 10. So, there's that.

[Wonko the Sane]

I didn't mean anything by it, I was half-joking anyway. But indeed there seems to be some twisted meaning to those quotes that I didn't properly understand until you explained in detail.  In any case, yes, the pattern that I suggested is better because the previous pattern is incomplete, but there is nothing elegant about it. And I think that I qualify as a "real user" (didn't I pass the Turing Test?), I did provide proof that the current version didn't work with at least one version of Vista, no matter how "rare". Honestly, the only thing undermining Holmes.Sherlock's script is you calling it half-assed every other day. But to be fair, I can't really comment on it being "good enough" because it didn't work for me on G4D 0.4.6 (as I stated earlier in one of the posts), and neither does it work on Windows 10. So, there's that.

Sure you pass as a"real user" and I was full-joking BTW.

 

It is your install that - as said - is probably "not real" in the sense that very likely it does not exist in the real world anymore (and probably did not exist at the time of release) OR the few such installs are in the hands of people that do remember their normal password, AND/OR never found or tested PassPass.

I personally doubt that someone actually needed it on Vista SP1, tested it, found it not working and failed to post here for help/assistance. 

 

And sure, having been released a few years ago, it may (or may not) work with more recent versions than the one listed in the first post, this is expected.

 

Does the (more recent) Chenall Wenv-less version work on the 0.4.6x yyyy-mm-dd you are using?

 

wonko

[ner0]

It is your install that - as said - is probably "not real" in the sense that very likely it does not exist in the real world anymore (and probably did not exist at the time of release) OR the few such installs are in the hands of people that do remember their normal password, AND/OR never found or tested PassPass.

I personally doubt that someone actually needed it on Vista SP1, tested it, found it not working and failed to post here for help/assistance. 

 

Does the (more recent) Chenall Wenv-less version work on the 0.4.6x yyyy-mm-dd you are using?

 

Sure, my test setup was something that might not align the multitude of variables that you suggest or at least very unlikely, but isn't that the point after all? Isn't it unlikely, but possible, that a sequence of two bytes exists once or more within a couple hundred of them? This isn't as important as I make it sound, but the point I'm making is that your logic leaves things up to chance.

 

As for Chenall's version, I did look at the code but I'm not sure I tried it, I've been using "my" script which works just fine.

I also changed the patch bytes because, as Steve mentioned, NOPs are present in the DLLs and you would possibly restore bytes to the wrong places. I ended up using the exact same pattern as Windows 8.1 for 64bit and a very similar one for 32bit:

:32BitPatch
if "%majmin%"=="10." set patt=\x10\x3B\xC7\x0F && set rpatt=\x10\x33\xC0\x0F
:64BitPatch
if "%majmin%"=="10." set patt=\x49\x3B\xC6\x0F\x85 && set rpatt=\x33\xC0\x90\x0F\x85

I'm wondering which ones Steve used...

And also, how do you go about validating the first 512 bytes of the target file. How do you check them and against what?

Edited by ner0, 02 December 2016 - 07:29 PM.

[Wonko the Sane]

 

And also, how do you go about validating the first 512 bytes of the target file. How do you check them and against what?

I am not sure to understand, what do you mean by "validate" or "check"?

 

Wonko

[ner0]

When you Restore the DLL file (after first backing it up), it will now check the first 512 bytes to make sure you are restoring the same file and same version.

 

This here, how does that work? Where do you (he) store(s) the 512 bytes "signature" ?

Edited by ner0, 02 December 2016 - 07:48 PM.

[Wonko the Sane]

Get the (his) file (the one that he did not post a link to) which is here:

https://drive.google...dmFjcUJJQ0RyZTQ

 

You find the passpass as PPass.g4b inside Easy2Boot v1.87d.zip\_ISO\docs\PassPass\

 

Wonko

[ner0]

Thanks, Wonko.

It looks like the script must be deployed alongside a ".bak" file that acts as a place-holder.

As for the pattern he used:

:32BitPatch
if "%majmin%"=="10.0" set patt=\xC7\x0F\x85\x98\xFB\xFF\xFF && set rpatt=\xC7\x90\x90\x90\x90\x85\xc0
:64BitPatch
if "%majmin%"=="10.0" set patt=\xC6\x0F\x85\x18\xFB\xFF\xFF && set rpatt=\xC6\x90\x90\x90\x90\x85\xc0

[steve6375]

The user can make a backup of the DLL (which could be either msv1_0.dll or NtlmShared.dll) to PassPass.bak.

The user can overwrite the target DLL with the contents of PassPass.bak at any time.

So the .bak file could contain anything.

I copy the first 512 bytes of the .bak file and the target dll into memory and then run cmp to compare the bytes.

If they are the same then the copy will proceed.

I am assuming that this will vary between different DLLs but the patch bytes will be beyond this area...

 

This is the restore code which makes a  cfg file in memory

echo -e \niftitle [if exist %backup%] Restore File %dllPath%\\nRestore from file PassPass.bak >> (md)0x19300+10
echo -e dd if=%2/%3/system32/%dll% of=(md)0x300+1 \> nul >> (md)0x19300+10
echo -e dd if=%backup% of=(md)0x301+1 \> nul >> (md)0x19300+10
echo -e cmp (md)0x300+1 (md)0x301+1 \> nul \|\| pause Backup is not same file as %dll% - press ENTER to continue... \&\& configfile (md)0x19300+10 >> (md)0x19300+10
echo -e dd of=%2/%3/system32/%dll% if=%backup% \> nul >> (md)0x19300+10
echo -e if not "%^@retval%"=="1" pause ERROR restoring file! - Press ENTER to continue... \nconfigfile (md)0x19300+10 >> (md)0x19300+10

[steve6375]

P.S. I did look at chenall's code which was not very well commented and vastly different from H.S and my code.

It would have taken a LOT of re-writing and retesting just to remove the wenv code.

As E2B already has wenv, I did not consider the effort worthwhile (although I did notice that wenv seems to destroy memory at (md)0x3000).

[Wonko the Sane]

@Ner0

Yes, one of the limitations of grub4dos (on NTFS, but not on FAT, as long as the external fat module is available) is that it cannot "create" a file, so you need to provide beforehand in the filesystem  a "dummy container" to which you can dd or write actual values.

 

 

@Steve6375

Sure, the wenv version is OK for E2B use, of course .

If only it was possible to have in a future version of "plain" grub4dos for loops (and possibly string substitution *like* %var:this=that% it would much easier to remove the dependency to Wenv.

I do believe Chenall when he stated that his plain version is faster, though of course we are probably talking of a few seconds at the most.

 

Wonko

[Wonko the Sane]

@Ner0
I had some time to check the byepass thingy, you introduced a small "feature limitaton".
You batch assumes that the Windows directory is actually called "Windows", while it is very, very common that it is called as such , it is not really "hardcoded".
Other versions do check for any directory that contain a \System32\msv1_0.dll .

Question:
On 10 - even if the "code to be patched" is moved to NtlmShared.dll the msv1_0.dll is still present, right?
Then why are you loooking for Winlogon.exe?

I am thinking that there may be "edge cases" where versions are "mixed" (for whatever reasons).
It just feels more "correct" to check for the version of msv1_0.dll and - in case a 10 is detected - re-check the version of the NtlmShared.dll, just in case, particularly if - before or later - we will need to go for the "versions database driven" patching.

I'll see if I can put together a "different" identification scheme, ready for the - eventual - migration to version database.


Wonko

[ner0]

Yes, I didn't bother much about the Windows folder, but you're right.

One of the reasons why I didn't carry the mechanism over was because the script was all too confusing, with numerous calls to itself by passing own variables as arguments, it was hard to follow the logic and it's mainly why I did my own version of the script. I did add a static check for WINNT afterwards (considering 2K) but I can also allow an argument to manually specify the Windows folder. But even if I implemented the "check for any folder with", couldn't it have a considerable impact on performance?

 

As for switching to winlogon.exe, I think I made that mistake when adjusting the script.

I was updating PEPassPass at the same time and I think that this is what the script used to locate the Windows folder.

In this case, it is not only useless but also may turn out problematic if thee aim becomes to check for the build version, and of course msv1_0.dll is present in every WIndows (2K+) version that I know of.

 

Any ideas that aim at improvement are welcome.