Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Neuer Reparse Point fuer MicrosoftEdge.exe in 1803
162 views
Skip to first unread message
Christoph Schneegans
May 4, 2018, 11:41:17 PM5/4/18
to
Hallo allerseits!
Um die Speicherfresser auf meinen Datenträgern schnell zu identifzieren,
benutze ich seit Ewigkeiten gerne SpaceMonger, auch wenn das Programm nicht
mehr weiterentwickelt wird und die Website des Herstellers unter
<http://www.sixty-five.cc/> auch nicht mehr erreichbar ist. Mit den
Alternativen von <https://www.jam-software.de/treesize_free/> oder
<https://windirstat.net/> kann ich mich hingegen nicht anfreunden.
Vermutlich seit dem Update auf Windows 10 1803 ist SpaceMonger aber nicht
mehr benutzbar: Es scannt zwar wie gewohnt den Datenträger, zeigt
schließlich aber nur die beiden Objekte
%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe und
%LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe
mit jeweils 0 Bytes Größe an, den freien Speicher dafür mit 12,9 Petabyte!
junction.exe aus der aktuellen Sysinternals Suite meldet für beide Objekte
einen Reparse Point unbekannten Typs:
| >junction.exe "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
|
| Junction v1.07 - Creates and lists directory links
| Copyright (C) 2005-2016 Mark Russinovich
| Sysinternals - www.sysinternals.com
|
| C:\Users\chris\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe: UNKNOWN MICROSOFT REPARSE POINT
fsutil.exe liefert für beide Objekte eine identische Ausgabe:
| >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
| Reparse Tag Value : 0x8000001b
| Tag value: Microsoft
|
| Reparse Data Length: 0x00000110
| Reparse Data:
| 0000: 03 00 00 00 4d 00 69 00 63 00 72 00 6f 00 73 00 ....M.i.c.r.o.s.
| 0010: 6f 00 66 00 74 00 2e 00 4d 00 69 00 63 00 72 00 o.f.t...M.i.c.r.
| 0020: 6f 00 73 00 6f 00 66 00 74 00 45 00 64 00 67 00 o.s.o.f.t.E.d.g.
| 0030: 65 00 5f 00 38 00 77 00 65 00 6b 00 79 00 62 00 e._.8.w.e.k.y.b.
| 0040: 33 00 64 00 38 00 62 00 62 00 77 00 65 00 00 00 3.d.8.b.b.w.e...
| 0050: 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 M.i.c.r.o.s.o.f.
| 0060: 74 00 2e 00 4d 00 69 00 63 00 72 00 6f 00 73 00 t...M.i.c.r.o.s.
| 0070: 6f 00 66 00 74 00 45 00 64 00 67 00 65 00 5f 00 o.f.t.E.d.g.e._.
| 0080: 38 00 77 00 65 00 6b 00 79 00 62 00 33 00 64 00 8.w.e.k.y.b.3.d.
| 0090: 38 00 62 00 62 00 77 00 65 00 21 00 4d 00 69 00 8.b.b.w.e.!.M.i.
| 00a0: 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 45 00 c.r.o.s.o.f.t.E.
| 00b0: 64 00 67 00 65 00 00 00 43 00 3a 00 5c 00 57 00 d.g.e...C.:.\.W.
| 00c0: 69 00 6e 00 64 00 6f 00 77 00 73 00 5c 00 53 00 i.n.d.o.w.s.\.S.
| 00d0: 79 00 73 00 74 00 65 00 6d 00 33 00 32 00 5c 00 y.s.t.e.m.3.2.\.
| 00e0: 53 00 79 00 73 00 74 00 65 00 6d 00 55 00 57 00 S.y.s.t.e.m.U.W.
| 00f0: 50 00 4c 00 61 00 75 00 6e 00 63 00 68 00 65 00 P.L.a.u.n.c.h.e.
| 0100: 72 00 2e 00 65 00 78 00 65 00 00 00 31 00 00 00 r...e.x.e...1...
Google findet nur sehr wenige Seiten, die den gemeldeten "Reparse Tag
Value" 0x8000001b im Zusammenhang mit Reparse Points finden. Eine davon ist
<https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/include/reparsept.h>,
und selbst dort liest man wenig Erhellendes:
| #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
Ich traue mich nicht, die beiden Objekte zu löschen. SpaceMonger
funktioniert aber wieder, wenn ich dem Administrator (denn unter diesem
Konto führe ich SpaceMonger aus) die Zugriffsrechte auf
"%LOCALAPPDATA%\Microsoft\WindowsApps" entziehe. Ob das Nebenwirkungen hat,
werde ich dann sehen…
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Um die Speicherfresser auf meinen Datenträgern schnell zu identifzieren,
benutze ich seit Ewigkeiten gerne SpaceMonger, auch wenn das Programm nicht
mehr weiterentwickelt wird und die Website des Herstellers unter
<http://www.sixty-five.cc/> auch nicht mehr erreichbar ist. Mit den
Alternativen von <https://www.jam-software.de/treesize_free/> oder
<https://windirstat.net/> kann ich mich hingegen nicht anfreunden.
Vermutlich seit dem Update auf Windows 10 1803 ist SpaceMonger aber nicht
mehr benutzbar: Es scannt zwar wie gewohnt den Datenträger, zeigt
schließlich aber nur die beiden Objekte
%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe und
%LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe
mit jeweils 0 Bytes Größe an, den freien Speicher dafür mit 12,9 Petabyte!
junction.exe aus der aktuellen Sysinternals Suite meldet für beide Objekte
einen Reparse Point unbekannten Typs:
| >junction.exe "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
|
| Junction v1.07 - Creates and lists directory links
| Copyright (C) 2005-2016 Mark Russinovich
| Sysinternals - www.sysinternals.com
|
| C:\Users\chris\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe: UNKNOWN MICROSOFT REPARSE POINT
fsutil.exe liefert für beide Objekte eine identische Ausgabe:
| >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
| Reparse Tag Value : 0x8000001b
| Tag value: Microsoft
|
| Reparse Data Length: 0x00000110
| Reparse Data:
| 0000: 03 00 00 00 4d 00 69 00 63 00 72 00 6f 00 73 00 ....M.i.c.r.o.s.
| 0010: 6f 00 66 00 74 00 2e 00 4d 00 69 00 63 00 72 00 o.f.t...M.i.c.r.
| 0020: 6f 00 73 00 6f 00 66 00 74 00 45 00 64 00 67 00 o.s.o.f.t.E.d.g.
| 0030: 65 00 5f 00 38 00 77 00 65 00 6b 00 79 00 62 00 e._.8.w.e.k.y.b.
| 0040: 33 00 64 00 38 00 62 00 62 00 77 00 65 00 00 00 3.d.8.b.b.w.e...
| 0050: 4d 00 69 00 63 00 72 00 6f 00 73 00 6f 00 66 00 M.i.c.r.o.s.o.f.
| 0060: 74 00 2e 00 4d 00 69 00 63 00 72 00 6f 00 73 00 t...M.i.c.r.o.s.
| 0070: 6f 00 66 00 74 00 45 00 64 00 67 00 65 00 5f 00 o.f.t.E.d.g.e._.
| 0080: 38 00 77 00 65 00 6b 00 79 00 62 00 33 00 64 00 8.w.e.k.y.b.3.d.
| 0090: 38 00 62 00 62 00 77 00 65 00 21 00 4d 00 69 00 8.b.b.w.e.!.M.i.
| 00a0: 63 00 72 00 6f 00 73 00 6f 00 66 00 74 00 45 00 c.r.o.s.o.f.t.E.
| 00b0: 64 00 67 00 65 00 00 00 43 00 3a 00 5c 00 57 00 d.g.e...C.:.\.W.
| 00c0: 69 00 6e 00 64 00 6f 00 77 00 73 00 5c 00 53 00 i.n.d.o.w.s.\.S.
| 00d0: 79 00 73 00 74 00 65 00 6d 00 33 00 32 00 5c 00 y.s.t.e.m.3.2.\.
| 00e0: 53 00 79 00 73 00 74 00 65 00 6d 00 55 00 57 00 S.y.s.t.e.m.U.W.
| 00f0: 50 00 4c 00 61 00 75 00 6e 00 63 00 68 00 65 00 P.L.a.u.n.c.h.e.
| 0100: 72 00 2e 00 65 00 78 00 65 00 00 00 31 00 00 00 r...e.x.e...1...
Google findet nur sehr wenige Seiten, die den gemeldeten "Reparse Tag
Value" 0x8000001b im Zusammenhang mit Reparse Points finden. Eine davon ist
<https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/include/reparsept.h>,
und selbst dort liest man wenig Erhellendes:
| #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
Ich traue mich nicht, die beiden Objekte zu löschen. SpaceMonger
funktioniert aber wieder, wenn ich dem Administrator (denn unter diesem
Konto führe ich SpaceMonger aus) die Zugriffsrechte auf
"%LOCALAPPDATA%\Microsoft\WindowsApps" entziehe. Ob das Nebenwirkungen hat,
werde ich dann sehen…
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Stefan Kanthak
May 5, 2018, 12:56:03 PM5/5/18
to
"Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
[...]
> Vermutlich seit dem Update auf Windows 10 1803 ist SpaceMonger aber nicht
> mehr benutzbar: Es scannt zwar wie gewohnt den Datenträger, zeigt
> schließlich aber nur die beiden Objekte
> %LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe und
> %LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe
> mit jeweils 0 Bytes Größe an, den freien Speicher dafür mit 12,9 Petabyte!
WEGWERFEN!
> junction.exe aus der aktuellen Sysinternals Suite meldet für beide Objekte
> einen Reparse Point unbekannten Typs:
>
> | >junction.exe "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
> |
> | Junction v1.07 - Creates and lists directory links
> | Copyright (C) 2005-2016 Mark Russinovich
> | Sysinternals - www.sysinternals.com
> |
> | C:\Users\chris\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe: UNKNOWN MICROSOFT REPARSE POINT
Ebenfalls wegwerfen!
> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>
> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
> | Reparse Tag Value : 0x8000001b
> | Tag value: Microsoft
[...]
Wie ueblich kann das Bordwerkzeug mit diesen Daten umgehen.
> Google findet nur sehr wenige Seiten, die den gemeldeten "Reparse Tag
> Value" 0x8000001b im Zusammenhang mit Reparse Points finden. Eine davon ist
> <https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/include/reparsept.h>,
> und selbst dort liest man wenig Erhellendes:
>
> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
AUTSCH!
Nicht nur dieser "reparse point tag value" ist seit dem letzten Jahrtausend
in der mit jedem Windows Development Kit oder Platform Software Development
Kit gelieferten WINNT.H definiert.
Da "Apps" mit Windows 8 alias "Blue" eingefuehrt wurden brauchst Du ein
WDK fuer Windows 8.
> Ich traue mich nicht, die beiden Objekte zu löschen.
Wie der symbolische Name angibt teilen solche "reparse points" dem in
NTDLL.DLL implementierten Modul-Lader mit, wie UWP-Apps zu starten sind!
Stefan
JFTR: die Volltrottel von Microsoft haben mit diesen unsaeglichen "Apps"
den bereits mit .NET verbrochenen Design-Fehler wiederholt, .NET
und "Apps" nicht als eigene NT-Subsysteme (neben Win32 und POSIX)
zu implementieren, und die eNTe dadurch noch mehr versaut!
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
[...]
> Vermutlich seit dem Update auf Windows 10 1803 ist SpaceMonger aber nicht
> mehr benutzbar: Es scannt zwar wie gewohnt den Datenträger, zeigt
> schließlich aber nur die beiden Objekte
> %LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe und
> %LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe
> mit jeweils 0 Bytes Größe an, den freien Speicher dafür mit 12,9 Petabyte!
> junction.exe aus der aktuellen Sysinternals Suite meldet für beide Objekte
> einen Reparse Point unbekannten Typs:
>
> | >junction.exe "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
> |
> | Junction v1.07 - Creates and lists directory links
> | Copyright (C) 2005-2016 Mark Russinovich
> | Sysinternals - www.sysinternals.com
> |
> | C:\Users\chris\AppData\Local\Microsoft\WindowsApps\MicrosoftEdge.exe: UNKNOWN MICROSOFT REPARSE POINT
> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>
> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
> | Reparse Tag Value : 0x8000001b
> | Tag value: Microsoft
Wie ueblich kann das Bordwerkzeug mit diesen Daten umgehen.
> Google findet nur sehr wenige Seiten, die den gemeldeten "Reparse Tag
> Value" 0x8000001b im Zusammenhang mit Reparse Points finden. Eine davon ist
> <https://github.com/JFLarvoire/SysToolsLib/blob/master/C/MsvcLibX/include/reparsept.h>,
> und selbst dort liest man wenig Erhellendes:
>
> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
Nicht nur dieser "reparse point tag value" ist seit dem letzten Jahrtausend
in der mit jedem Windows Development Kit oder Platform Software Development
Kit gelieferten WINNT.H definiert.
Da "Apps" mit Windows 8 alias "Blue" eingefuehrt wurden brauchst Du ein
WDK fuer Windows 8.
> Ich traue mich nicht, die beiden Objekte zu löschen.
NTDLL.DLL implementierten Modul-Lader mit, wie UWP-Apps zu starten sind!
Stefan
JFTR: die Volltrottel von Microsoft haben mit diesen unsaeglichen "Apps"
den bereits mit .NET verbrochenen Design-Fehler wiederholt, .NET
und "Apps" nicht als eigene NT-Subsysteme (neben Win32 und POSIX)
zu implementieren, und die eNTe dadurch noch mehr versaut!
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Takvorian
May 5, 2018, 1:32:05 PM5/5/18
to
Christoph Schneegans schrieb:
> Ich traue mich nicht, die beiden Objekte zu löschen. SpaceMonger
> funktioniert aber wieder,
Es wäre auch ziemlich irre, wegen eines uralten, nicht mehr korrekt
funktionierenden Schrotts, Windows-Dateien zu löschen...
> wenn ich dem Administrator (denn unter diesem
> Konto führe ich SpaceMonger aus) die Zugriffsrechte auf
> "%LOCALAPPDATA%\Microsoft\WindowsApps" entziehe. Ob das Nebenwirkungen hat,
> werde ich dann sehen…
... und deswegen solche Rechte-Basteleien zu machen.
> Ich traue mich nicht, die beiden Objekte zu löschen. SpaceMonger
> funktioniert aber wieder,
funktionierenden Schrotts, Windows-Dateien zu löschen...
> wenn ich dem Administrator (denn unter diesem
> Konto führe ich SpaceMonger aus) die Zugriffsrechte auf
> "%LOCALAPPDATA%\Microsoft\WindowsApps" entziehe. Ob das Nebenwirkungen hat,
> werde ich dann sehen…
Christoph Schneegans
May 8, 2018, 8:11:24 PM5/8/18
to
Stefan Kanthak schrieb:
> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
Und das Bordwerkzeug explorer.exe kennt diesen Typ Reparse Point offenbar
auch nicht. Wenn man nämlich auf einem solchen Objekt "Properties >
Security > Edit…" wählt, um die Berechtigungen zu ändern, zeigt Windows als
nächstes den Dialog "Select User or Group" an. Ändern lassen sich die
Berechtigungen da jedenfalls nicht…
>> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
>
Beschreibung gibt es dort auch nicht.
> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
>
>> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>>
>> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
>> | Reparse Tag Value : 0x8000001b
>> | Tag value: Microsoft
>
>> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>>
>> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
>> | Reparse Tag Value : 0x8000001b
>> | Tag value: Microsoft
>
> Wie ueblich kann das Bordwerkzeug mit diesen Daten umgehen.
Kunststück, fsutil.exe macht ja auch am wenigsten damit.
Und das Bordwerkzeug explorer.exe kennt diesen Typ Reparse Point offenbar
auch nicht. Wenn man nämlich auf einem solchen Objekt "Properties >
Security > Edit…" wählt, um die Berechtigungen zu ändern, zeigt Windows als
nächstes den Dialog "Select User or Group" an. Ändern lassen sich die
Berechtigungen da jedenfalls nicht…
>> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
>
> Nicht nur dieser "reparse point tag value" ist seit dem letzten Jahrtausend
> in der mit jedem Windows Development Kit oder Platform Software Development
> Kit gelieferten WINNT.H definiert.
Ich finde die Konstante durchaus in einer lokalen WINNT.H, aber eine
> in der mit jedem Windows Development Kit oder Platform Software Development
> Kit gelieferten WINNT.H definiert.
Beschreibung gibt es dort auch nicht.
Stefan Kanthak
May 9, 2018, 7:56:12 AM5/9/18
to
"Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
> Stefan Kanthak schrieb:
>
>> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
>>
>>> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>>>
>>> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
>>> | Reparse Tag Value : 0x8000001b
>>> | Tag value: Microsoft
>>
>> Wie ueblich kann das Bordwerkzeug mit diesen Daten umgehen.
>
> Kunststück, fsutil.exe macht ja auch am wenigsten damit.
Es zeigt sowohl den "tag value" als auch die Daten des "reparse point" an.
JUNCTION.exe dagegen gibt LAPIDAR nur "UNKNOWN MICROSOFT REPARSE POINT" aus,
und weder den "tag value" noch die Daten!
Wie Du anhand des von FSUTIL.exe angezeigten Dumps der Daten sehen kannst
beginnen diese mit einem DWORD, gefolgt von einem Feld, das hier 4 NUL-
terminierte UNICODE-Zeichenketten enthaelt.
Da Du PoserShell beherrschst hilft Dir James Forshaws (Google Project Zero)
<https://github.com/google/sandbox-attacksurface-analysis-tools/blob/master/NtObjectManager/NtObjectManager.psm1>
mit dem CmdLet "Get-ExecutionAlias" weiter.
> Und das Bordwerkzeug explorer.exe kennt diesen Typ Reparse Point offenbar
> auch nicht.
Wieso sollte es?
Die Interpretation von "reparse points" obliegt dem NTFS-Dateisystemtreiber
sowie ggf. geladenen Filtertreibern, NICHT den Anwendungen; diese erhalten
die von den Treibern "reparsten" Daten, bei Junctions oder Symlinks das
jeweilige Ziel.
Bei "reparse points" wie APPEXECLINK liefert der zustaendige Treiber KEIN
Dateisystemobjekt zurueck, daher koennen Programme wie der Explorer, die
ein Dateisystemobjekt erwarten, damit nichts anfangen.
Systemprogramme wie FSUTIL.exe oder JUNCTION.exe dagegen geben beim
Oeffnen der "reparse points" an, dass sie die Daten selbst interpretieren
wollen/koennen: dann unterlaesst der Treiber die Interpretation und
oeffnet den "reparse point", nicht dessen Ziel.
[ GIGO ]
>>> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
>>
>> Nicht nur dieser "reparse point tag value" ist seit dem letzten Jahrtausend
>> in der mit jedem Windows Development Kit oder Platform Software Development
>> Kit gelieferten WINNT.H definiert.
>
> Ich finde die Konstante durchaus in einer lokalen WINNT.H, aber eine
> Beschreibung gibt es dort auch nicht.
Mehr als unter <https://msdn.microsoft.com/en-us/library/dd541671.aspx>
sowie <https://msdn.microsoft.com/en-us/library/ff552014.aspx> haben die
Schweinepriester von Microsoft zu "reparse points" nicht veroeffentlicht.
Dort MUESSTEN sie eigentlich ALLE "reparse data buffer" beschreiben.
Im Zweifel hilft eine Beschwerde bei der EU-Kommission, dass Microsoft
ihrer Verpflichtung zur Offenlegung von Windows-Schnittstellen nicht
nachkommt und doch bitte eine Muelliarde Dollar Bussgeld zahlen moechte.
Stefan
PS: <https://blogs.windows.com/buildingapps/2017/07/05/command-line-activation-universal-windows-apps/>
ist nicht brauchbar, um das Zusammenspiel von Windows Modul-Lader
und diesen "reparse points" zu beschreiben.
> Stefan Kanthak schrieb:
>
>> "Christoph Schneegans" <Chri...@Schneegans.de> schrieb:
>>
>>> fsutil.exe liefert für beide Objekte eine identische Ausgabe:
>>>
>>> | >fsutil.exe reparsePoint query "%LOCALAPPDATA%\Microsoft\WindowsApps\MicrosoftEdge.exe"
>>> | Reparse Tag Value : 0x8000001b
>>> | Tag value: Microsoft
>>
>> Wie ueblich kann das Bordwerkzeug mit diesen Daten umgehen.
>
> Kunststück, fsutil.exe macht ja auch am wenigsten damit.
JUNCTION.exe dagegen gibt LAPIDAR nur "UNKNOWN MICROSOFT REPARSE POINT" aus,
und weder den "tag value" noch die Daten!
Wie Du anhand des von FSUTIL.exe angezeigten Dumps der Daten sehen kannst
beginnen diese mit einem DWORD, gefolgt von einem Feld, das hier 4 NUL-
terminierte UNICODE-Zeichenketten enthaelt.
Da Du PoserShell beherrschst hilft Dir James Forshaws (Google Project Zero)
<https://github.com/google/sandbox-attacksurface-analysis-tools/blob/master/NtObjectManager/NtObjectManager.psm1>
mit dem CmdLet "Get-ExecutionAlias" weiter.
> Und das Bordwerkzeug explorer.exe kennt diesen Typ Reparse Point offenbar
> auch nicht.
Die Interpretation von "reparse points" obliegt dem NTFS-Dateisystemtreiber
sowie ggf. geladenen Filtertreibern, NICHT den Anwendungen; diese erhalten
die von den Treibern "reparsten" Daten, bei Junctions oder Symlinks das
jeweilige Ziel.
Bei "reparse points" wie APPEXECLINK liefert der zustaendige Treiber KEIN
Dateisystemobjekt zurueck, daher koennen Programme wie der Explorer, die
ein Dateisystemobjekt erwarten, damit nichts anfangen.
Systemprogramme wie FSUTIL.exe oder JUNCTION.exe dagegen geben beim
Oeffnen der "reparse points" an, dass sie die Daten selbst interpretieren
wollen/koennen: dann unterlaesst der Treiber die Interpretation und
oeffnet den "reparse point", nicht dessen Ziel.
[ GIGO ]
>>> | #define IO_REPARSE_TAG_APPEXECLINK 0x8000001B /* ? */
>>
>> Nicht nur dieser "reparse point tag value" ist seit dem letzten Jahrtausend
>> in der mit jedem Windows Development Kit oder Platform Software Development
>> Kit gelieferten WINNT.H definiert.
>
> Ich finde die Konstante durchaus in einer lokalen WINNT.H, aber eine
> Beschreibung gibt es dort auch nicht.
sowie <https://msdn.microsoft.com/en-us/library/ff552014.aspx> haben die
Schweinepriester von Microsoft zu "reparse points" nicht veroeffentlicht.
Dort MUESSTEN sie eigentlich ALLE "reparse data buffer" beschreiben.
Im Zweifel hilft eine Beschwerde bei der EU-Kommission, dass Microsoft
ihrer Verpflichtung zur Offenlegung von Windows-Schnittstellen nicht
nachkommt und doch bitte eine Muelliarde Dollar Bussgeld zahlen moechte.
Stefan
PS: <https://blogs.windows.com/buildingapps/2017/07/05/command-line-activation-universal-windows-apps/>
ist nicht brauchbar, um das Zusammenspiel von Windows Modul-Lader
und diesen "reparse points" zu beschreiben.
0 new messages