Many people believe that native Windows programs are so deeply integrated with OS that there is no way to move them between these different OS versions. And it’s fair to say that at first this belief was reinforced by that good ol’ fashioned System File Protection (SFP) service, only to be later replaced by the Trusted Installer.

The new Windows 11 Notepad app can be very annoying, plus the news about Notepad AI integration are kinda worrying, so many people revert to Registry hacks to bring the ‘old Notepad‘ back. There are more ways than one to address this problem, and this post will focus on one of them, one that is less known…

You may not be aware, but the old Windows XP Notepad still works on Windows 11. Secondly, the same can be said about Windows 10 Notepad.

You can literally copy c:\WINDOWS\NOTEPAD.EXE from Windows XP or Windows 10 to Windows 11 and it will work like a charm. For later versions of Windows, the Notepad.exe requires language resource files to be copied as well, so you may want to copy the following files:

• c:\Windows\notepad.exe
• c:\Windows\en-US\notepad.exe.mui

Once you bring these old versions of Notepad to Windows 11 you can just store them in any directory you want. They are — believe or not — fully portable.

The very same can be said about Windows Calculator. While the Win10 Calculator was the first one pushing the Windows App agenda, the Windows XP Calculator can still run on Windows 11 w/o any issue:

Just copy the c:\WINDOWS\System32\calc.exe from Windows XP to Windows 11 and it will just run.

The portability of old Windows programs cannot be underestimated. With all the changes to the Windows ecosystem, with all these embedded-by-default program manifests, with all the push towards Windows Apps, ad-centric ecosystem, we still have a small window of opportunity to preserve the software that was just good at doing one thing – user-friendly programs that worked: offline, ad-, and telemetry-free.

This is a bunch of random notes from running Procmon on Win11_24H2 build.

We all know about autorun.inf that OS is checking when we attach a new device to the system, but on new devices the system is actually looking for more files — here’s the list:

• \Device\HarddiskVolumeN\audio_ts\audio_ts.ifo
• \Device\HarddiskVolumeN\autorun.inf
• \Device\HarddiskVolumeN\AVCHD
• \Device\HarddiskVolumeN\BDAV
• \Device\HarddiskVolumeN\BDMV
• \Device\HarddiskVolumeN\bootex.log
• \Device\HarddiskVolumeN\DCIM
• \Device\HarddiskVolumeN\desktop.ini
• \Device\HarddiskVolumeN\dvd_rtav\vr_mangr.ifo
• \Device\HarddiskVolumeN\EFI\Microsoft\Boot\BCD
• \Device\HarddiskVolumeN\EFI\Microsoft\Boot\BCD.LOG
• \Device\HarddiskVolumeN\EFI\Microsoft\Boot\Policies\UnlockToken.pol
• \Device\HarddiskVolumeN\PRIVATE\AVCHD
• \Device\HarddiskVolumeN\Recovery.txt
• \Device\HarddiskVolumeN\SVCD\entries.svd
• \Device\HarddiskVolumeN\SVCD\entries.vcd
• \Device\HarddiskVolumeN\System Volume Information
• \Device\HarddiskVolumeN\System Volume Information\AadRecoveryPasswordDelete
• \Device\HarddiskVolumeN\System Volume Information\ClientRecoveryPasswordRotation
• \Device\HarddiskVolumeN\System Volume Information\FveDecryptedVolumeFolder
• \Device\HarddiskVolumeN\VCD\entries.vcd
• \Device\HarddiskVolumeN\video_ts\video_ts.ifo
• \Device\HarddiskVolumeN\WinReOfflineScanningResult.dat

Some of them are obviously media-related, some are Windows Backup-related, and some … I have no clue.

The other interesting bit is that when executed, lsass.exe is trying to load a phantom DLL named “”.dll:

• C:\Windows\””.DLL
• C:\Windows\System\””.DLL
• C:\Windows\System32\””.DLL

While it looks like an attractive proposition, I am not sure if there is a way to exploit it 🙁 Still, need to come back to it to understand why the process is doing so. Perhaps there is a new data dumping opportunity here, somewhere…

There are a lot of new phantom DLLs, but they are tricky to play with. While writing this post I messed up this build’s booting so many times that I no longer understand which of these test phantom DLLs I added to the system contributed to the damage 🙂 I have added a list of potentials at the bottom of this post.

Then there is smss.exe trying to find these:

• C:\Windows\apppatch\drvpatch.sdb
• C:\Windows\System32\wowarmhw.dll
• C:\Windows\System32\xtajit.dll
• C:\Windows\System32\xtajit64.dll
• C:\Windows\System32\xtajit64se.dll
• C:\Windows\SysWOW64\wow64.dll
• C:\Windows\SysWOW64\wow64base.dll
• C:\Windows\SysWOW64\wow64con.dll
• C:\Windows\SysWOW64\wow64win.dll
• C:\Windows\SysWOW64\xtajit64.dll
• C:\Windows\SysWOW64\xtajit64se.dll

Then spoolsv.exe trying to access these:

• C:\Windows\System32
• C:\Windows\System32\spool
• C:\Windows\System32\spool\drivers
• C:\Windows\System32\spool\drivers\ARM64
• C:\WINDOWS\system32\spool\drivers\ARM64\3\New\
• C:\WINDOWS\system32\spool\drivers\ARM64\3\Old\
• C:\WINDOWS\system32\spool\drivers\ARM64\4\New\
• C:\WINDOWS\system32\spool\drivers\ARM64\4\Old\
• C:\Windows\System32\spool\drivers\IA64
• C:\WINDOWS\system32\spool\drivers\IA64\3\New\
• C:\WINDOWS\system32\spool\drivers\IA64\3\Old\
• C:\Windows\System32\spool\drivers\W32X86
• C:\Windows\System32\spool\drivers\W32X86\3\New
• C:\Windows\System32\spool\drivers\W32X86\3\Old
• C:\Windows\System32\spool\drivers\x64
• C:\Windows\System32\spool\drivers\x64\3\New
• C:\Windows\System32\spool\drivers\x64\3\Old
• C:\WINDOWS\system32\spool\drivers\x64\4\New\
• C:\WINDOWS\system32\spool\drivers\x64\4\Old\
• C:\Windows\System32\spool\PRINTERS
• C:\Windows\System32\spool\SERVERS
• C:\Windows\System32\ualapi.dll
• C:\Windows\System32\vfprint.dll

There seems to be a lot of cross-architectural code logic present here that needs further exploration.

There also seem to be more phantom DLL loading opportunities that are only available under specific conditions:

• C:\Windows\System32\Unknown.DLL (loaded by svchost.exe when AFAICT there is no network connectivity)
• C:\WINDOWS\SYSTEM32\windowsdefender:\.DLL – a potential phantom DLL but impossible due to file/ADS naming limitations

And finally, there is really a lot of paths the OS is trying to access in the procmon log that suggests some incoherent environment variable parsing:

• C:\Windows\System32\%ProgramFiles(arm)%
• C:\WINDOWS\system32\%systemroot%\system32\wbem\cimwin32.dll
• C:\WINDOWS\system32\%systemroot%\system32\wbem\wmipcima.dll
• C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppgenmig.dat
• C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppmig.dat
• C:\Windows\System32\%SystemRoot%\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftWindows.Client.AIX_1000.26100.29.0_x64__cw5n1h2txyewy\ActivationStore.dat
• C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\%SystemRoot%\ProgramData\Microsoft\Windows\AppRepository\Packages\MicrosoftWindows.Client.AIX_1000.26100.29.0_x64__cw5n1h2txyewy\ActivationStore.dat
• C:\WINDOWS\%WINDIR%\System32\SPP\Migration\sppgenmig.dat
• C:\WINDOWS\system32\%systemroot%\system32\wbem\wmiprov.dll
• C:\Users\<USER>\Desktop\%1
• C:\Users\Public\Desktop\%1

That’s a lot of sideloading and potential LPE vulns to explore…

The full list of possible phantom DLLs can be found here (win11_24H2_phantom_dlls.txt). Some of them are obvious path problems, but many are real phantom DLLs.