On 12/08/2023 15:17, Java Jive wrote:
>
> See below for a possibly important update on what can or can not be done
> to jailbreak out of Win10 ...

And another ...

> On 07/08/2023 13:35, Java Jive wrote:
>>
>> [snip]
>>
>> On 29/07/2023 18:37, Java Jive wrote:
>>>
>>> On 23/07/2023 20:18, Java Jive wrote:
>>>>
>>>> Astonishing to note that, despite claims of increased security with
>>>> every new version of Windows, in Win10 Everyone *STILL* has RO
>>>> access to the parent Users folder  -  I always delete this and Users
>>>> and replace them by giving Authenticated Users RO access in their
>>>> place and copying the settings down the heirarchy ...
>>>>      Administrators       Full
>>>>      System               Full
>>>>      Authenticated Users  RO
>>>> .... then reverting the actual genuine %USERNAME% folders to give
>>>> Administrators, %USERNAME%, and SYSTEM all Full access.
>>>
>>> I can confirm that this is doable with Win11,

Well, it's doable, but unfortunately it breaks the Search box in
Explorer, for some reason it locks and no longer can you type in it.
I'm baffles as to why this should happen, but finally after a long
investigation I have nailed the above as being responsible for it. It's
not the changed permissions on C:\Users that is the problem, but
replicating them further down the hierarchy. So for now I've replaced
Everyone and Users with Authenticated Users having the same RO
permissions on C:\Users and C:\Users\Default, and replicated the latter
down the hierarchy, and left it at that. At least the insecure Everyone
was able to be removed.

A strange anomaly is that under Windows 10 Home, but not under Windows
10 Professional, a C:\Users\DefaultAppPool subdirectory was created.

To revert to Windows Search, one could argue that it has been broken to
the point of near uselessness for a long time already, at least since
W7, possibly Vista, though I've never used that.

Windows 10 upgraded from Windows 7, so same programs as previous build,
initially filled about 45GB of my 64GB system drive, but after a few
upgrades it's now about 55GB. If I allow Windows Search Indexing to
run, it fills up the remaining 9GB in no time at all with its indexing
database, so, as in all previous versions of Windows, it's now been
disabled. After all, there is a perfectly good index already, it's
called a filesystem.

The difference in performance of various implementations of Windows
Search was brought sharply into focus to me recently!

I was doing a bit of housekeeping on my servers, because I'd noticed
that I had various versions of Rufus downloaded in various
subdirectories of my Install folder, presumably wherever had seemed most
appropriate to my mood at the time I saved each version. So I set a
search going on that folder and its subdirectories. I discovered that
by a freak chance of Linux linking, a circular link had been created:
within some backed up Linux data there was a link that when the data was
originally in situ from where the back up was made, pointed correctly,
but now in the backed up version happened to point to a location back up
the folder hierarchy happening to have the same name. However, I didn't
know this yet when I started searching ...

Well over an hour later, Win10 with indexing enabled on a Dell Inspiron
4-core i5 running at 2.5GHz with 8GB RAM, had found only 2 of the 10 or
so files that I knew were there.

So next I set the same search going with indexing disabled from Win7
running on a Dell Precision 2-core Duo running at 2.8GHz with 8GB RAM,
and it found all of them, 11 as it turned out, in just under 1 minute 40
seconds.

So finally I set the same search going with indexing disabled in WinXP
on a Dell Precision 2-core Duo running at 2.6GHz with 4GB RAM, and it
found all of them in under 7 seconds. Further, within a reasonable time
it went on to find the same files circularly-linked, revealing a problem
I hadn't known about previously.

So there you have it: XP 7 seconds, Win10 still not finished after an
hour. My constant complaint these days is: "Just *WHO* programs this
shit?!"

>>> but you'd be best
>>> advised to remove beforehand the circular links in each user profile,
>>> including the Default profile, ...
>>>      C:\Users\%USERNAME%\AppData\Local\Application Data
>>> .... each of which points back up to ...
>>>      C:\Users\%USERNAME%\AppData\Local
>>> .... causing an endless loop.  This was the case in W7 as well, and
>>> possibly Vista.  Duh!  Who's idiotic idea was that???!!!  And why
>>> hasn't it been fixed by now!
>>>
>>> There's another such circular loop ...
>>>      C:\ProgramData\Application Data
>>> .... which points back up to ...
>>>      C:\ProgramData
>>> .... so, while you're about it, remove that one as well.
>>>
>>> You'll have to run Explorer as an Administrator and take ownership of
>>> each link file in order to be able to delete it.
>>
>> I can also confirm that the following that were doable in W7 also are
>> doable in W10 from a Command prompt run as an Administrator  -  note
>> that each command will take an appreciable time, particularly the last
>> two, and you are advised very strongly to back up the system drive
>> using an imaging program before beginning:
>>
>> 1)    Find all the junctions on the system drive, to check for
>> circularities like those given above (note that a double redirect >>
>> is required rather than a single one >, because it's a for loop, and
>> that that the 2>&1 captures error messages in their proper sequence):
>>
>> for /f "usebackq tokens=*" %A in (`DIR /AL /S /B "C:\"`) do @for /f
>> "usebackq tokens=1-3*" %B in (`DIR /AHS "%A*" 2^>^&1 ^| FIND
>> "<JUNCTION>" `) do @echo %~dpA%E >> %TEMP%\Junctions.log 2>&1
>>
>> 2)    Give Administrators ownership to every file on the system drive;
>> naturally there will be some failures to take ownership of files such
>> as hiberfile.sys and Windows Defender files, which can be ignored, the
>> find clause suppresses the myriad blank lines and "SUCCESS:" messages
>> that TakeOwn spews out:
>>
>> takeown /A /R /D Y /SKIPSL /F C:\ | find "INFO:" > %TEMP%\TakeOwn.log
>> 2>&1
>
> IMPORTANT!  See below ...
>
>> 3)    Give Administrators Full Control permission to every file on the
>> system drive, leaving other permissions intact; as above, not every
>> file will be captured, but those that aren't can be ignored:
>>
>> icacls C:\* /T /C /L /Q /grant Administrators:F > %TEMP%\Icacls.log 2>&1
>
> IMPORTANT!  This last step might NOT work on Windows 10 Home, whereas it
> worked for me on Windows 10 Pro.  Symptom is that after a reboot the
> login screen appears, you log in, but the desktop never appears.  There
> is a mouse pointer on a black screen, but nothing else. <Ctrl-Alt-Del>
> brings up that menu, but choosing Task Manager creates a 'busy' mouse
> pointer for a second or two, but nothing further happens.
>
> By binary chopping first the root directory then the Windows directory,
> I've isolated the problem directory or file to ...
>     %WinDir%\Registration
> .... or an item within it.

Actually it may be the CRMLog sub-directory, even though it's entirely
empty. I got round this as follows:

Save permissions on problem folder, note that it is specified as itself
in the command line:
icacls C:\Windows\Registration /T /C /L /Q /save "D:\Temp\WRPrms.txt"

As before:
icacls C:\* /T /C /L /Q /grant Administrators:F > D:\Temp\Icacls.log 2>&1

Restore permissions on problem folder, note that its parent directory is
specified in the command line:
icacls C:\Windows /restore "D:\Temp\WRPrms.txt"

With each new version of Windows it gets harder and harder to retain
absolute control over your own PC.

> PC                                 Time to:  GRUB/OS Load  Win Logon
> P1 8GB @ 2.8GHz - Dual-boot Ubuntu 18 & W7:  0:12          0:24 later
> P2 4GB @ 2.6GHz - Dual-boot Ubuntu 18 & XP:  0:31-1:00+    0:19+ later
> P3 4GB @ 2.2GHz - XP:                        0:08          0:06 later
>
> It happened that the video card in P1 failed a couple of days ago, so I
> cannibalised successfully the one from P3 to repair it  -  I'm using the
> result to post this  -  and while I was about it I investigated further
> the slow P2, and its non-working fan.  It turned out that the fan had
> been disconnected deliberately, and when I reconnected it I found out
> why, it made a deeply unpleasant whine.  I replaced it with a spare that
> is a little quieter, though still too noisy, and the PC is now
> performing normally again.
>
> Accordingly, I put back the Window 10 Pro image that came on it, with a
> view to bringing it up to date, and found that, if it ever had been, it
> was no longer authenticated.  I have been able to retrieve from the
> build the Product Key used originally to install it, but it isn't
> accepted as authentication.
>
> The trouble is, I can't be sure of its original authentication status.

Happily, I've solved this. The image actually belonged to P3 that is
now without a working video card, it having been sacrificed it to keep
P1 going. I tried swapping in P2's working video card, putting the
image on it, and it authenticated. So I gave the slmgr command to
deauthenticate it, and swapped the video cards back again. Hopefully,
as it's a retail product key, in time it can be applied to the other
machine when I have a build ready for it.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk