-
Notifications
You must be signed in to change notification settings - Fork 5
/
Technicals.txt
1104 lines (955 loc) · 59.8 KB
/
Technicals.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
It's not just AutoRun, USB malware is more than that.
One of the reasons that USB malware is hard to defeat and so widespread on
Windows systems is that Windows, originated from DOS, do not have proper enough
execution prevention mechanisms. Generally, user should be aware of that he is
_unintentionally_ running an _arbitrary_ program, when he opens a drive or a
file inside it.
Unix/Linux already have execution mode bits, and the (optional) 'noexec' mount
option. They're not perfect, but DO prevent most of the tricks that USB malware
could do on Windows. There's no execute bit on Windows, so we have to let users
aware by other means.
There are several factors that a Windows user might mistakenly runs a program,
thinking he is opening a (legitimate) file:
- File extension displayed in Windows Explorer (_displayed_, which may be fake)
- File icon, whether it is static or dynamic based on file content (malicious
file can have an icon faking the user that it's something safe)
- Shortcut arrows
- Whether file itself is loaded and executed directly by the OS, executed only
via an interpreter, or have no execution data at all
(This list is not exhaustive.)
Technically these correspond to the following things:
1. "NeverShowExt" or "AlwaysShowExt" registry value in class key (technically
known as ProgID) of the file type ("NeverShowExt" takes precedence if both
values exist)
2. "Hide extension for known file types" checkbox in "Folder Options", which
corresponds to "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\
Advanced" value "HideFileExt" in registry
3. The presence of "shellex\IconHandler" registry subkey of class key of the
file type, and, if not present, the "DefaultIcon" subkey
4. "IsShortcut" registry value in class key of the file type
5. "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Icons" value
"29" (if present this overrides the shortcut overlay arrow icon provided by
shell32.dll)
6. Default value of "shell\open\command" subkey of class key of the file type,
whether it begins with "%1", or ends with "%*", or both
Ideally on a secure system,
1. No "NeverShowExt" value should be present for every file type, so that users
can see every extension of every file type. ("AlwaysShowExt" would be
optional if no extensions are hidden at all.)
2. "HideFileExt" should be 0 (false).
3. The file icon may be dynamic only if there's no executable code in the file
contents, and static otherwise. By "static" here I mean there's no Icon
Handler, and the "DefaultIcon" is not "%1". That is, all files of the same
type should display the same icon.
4. "IsShortcut" be present for all file types that represent links to another
file, especially to file that may be executable.
5. The "Shell Icons" registry value "29" should either not exist or refer to an
icon that is not blank icon.
6. Files that are not binary self-executable (PE, NE, MZ, or old COM format)
shouldn't have "%1" in the beginning data of their "shell\open\command"
default values, and files that are no executable code (script or binary)
shouldn't have "%*" in end of "shell\open\command" default values.
One exception can be made for scripts that contain shebangs indicating which
interpreter it is meant to be run in, and so will be necessary for OS kernel to
load it and parses the shebang. This is true for perl/python/shell scripts, but
not batch scripts. (And so having the default value of '"%1" %*' in "HKCR\
batfile\shell\open\command" is a bad idea. Should be 'cmd /c "%1" %*'. It might
remain as is for historical reasons. I don't know.)
Below is the list of some common file types and whether they fit the conditions
listed above. To ensure safety, at least 1 of the 6 cells should be marked
"safe" for every file type. The "Extension display" column is considered safe
only if there doesn't exist "NeverShowExt" value for the given file type, and
user disables the "HideFileExt" option (value set to 0), which is NOT the
default.
File | Extension | Icon | Shortcut | %1 | %* ending
ext. | display | (safe: | arrow | beginning | (safe:no)
| determined by | static) | (safe:yes) | (safe:no) |
-------+----------------+---------+------------+-----------+----------
.bat HideFileExt (safe) no[1] yes yes
.cmd HideFileExt (safe) no[1] yes yes
.com HideFileExt (safe) no[1] yes yes
.exe HideFileExt "%1" no[1] yes yes
.scr HideFileExt "%1"[2] no[1] yes no[3]
.pif NeverShowExt[4] handler (safe) yes[4] yes[4]
.lnk NeverShowExt handler (safe) n/a[5] n/a[5]
.url NeverShowExt handler (safe) n/a[5] n/a[5]
symlink HideFileExt[6] handler (safe)[6] n/a[5] n/a[5]
.WSH HideFileExt (safe) (safe) (safe) yes
.js HideFileExt (safe) no[1] (safe) yes
.JSE HideFileExt (safe) no[1] (safe) yes
.vbs HideFileExt (safe) no[1] (safe) yes
.VBE HideFileExt (safe) no[1] (safe) yes
.WSF HideFileExt (safe) no[1] (safe) yes
.msc HideFileExt handler no[1] (safe) yes
Notes:
[1] These types are not shortcuts, but executable code, hence the files may
contain code that executes other programs.
[2] There is no DefaultIcon subkey in "HKCR\scrfile", but "%1" is implied for
this file type.
[3] .scr is self-executable (NE or PE format), so %* technically doesn't
matter. Therefore no "safe" is marked on this field.
[4] Although .pif is a shortcut format, it's "open" verb, as handled by Windows
Explorer, does not check the validity of PIF format properly. It silently
allows a PE executable in .pif extension to be executed when user "opens"
it in Explorer. For this reason 'usb_vaccine.cmd' proposes to remove the
NeverShowExt value for this file type. Strangely enough, an executable of
COM, MZ or NE format and in .pif extension has the expected behavior of
not being executed.
[5] .lnk, .url and symbolic links have special Context Menu Handlers that
change the default (open) verb.
[6] Symbolic links ("symlinks") are a kind of special files in NTFS whose file
name may be in any or no extension. Since Windows 8.1, Windows Explorer
associates file symbolic links with the "HKCR\.symlink" registry key.
Windows 7 SP1 systems will also support the "HKCR\.symlink" association if
KB3009980 hotfix is installed.
In Windows 8.1 or later, or in Windows 7 with the hotfix, the display
behavior of the symlink's name extension is determined by "NeverShowExt" or
"AlwayShowExt" values in "HKCR\.symlink" key, or, if neither of the values
exist (which is the default), user's "HideFileExt" option. Therefore
symlink's name extension is not displayed for a default user's setting.
(This is a bad thing, since a symlink's name extension becomes irrelevant
in the new behavior of opening symlink or showing symlink's icons.
Therefore the extension shall be visible. 'usb_vaccine.cmd' will propose
this change for you if possible on your system.)
In Windows Vista, 8 or 7 without the hotfix, the display of a symlink's
extension is determined by the file type to which the symlink's name
extension corresponds. For example, a "foo.dll" symlink to "bar.scf" will
have the ".dll" extension always displayed, because of the default
"AlwaysShowExt" behavior of the .dll file (the "NeverShowExt" behavior of
.scf file is ignored).
A symlink always shows a shortcut arrow overlay in Windows Explorer, even
though there isn't an "IsShortcut" value in the ".symlink" key. This arrow
overlay display behavior is the same (since Windows Vista) with or without
the hotfix.
-------------------------------------------------------------------------------
File types with data "%1" in default values of their "DefaultIcon" subkeys:
Extension Software Class registry key, technically known as ProgID
.ani (Win95+) HKCR\anifile
.cdf IE4-IE6 HKCR\ChannelFile
(CLSID) IE4-IE6 HKCR\ChannelShortcut
.cur (Win95+) HKCR\curfile
.exe (Win95+) HKCR\exefile
.ht WinXP- HKCR\htfile ("HyperTerminal File")
.ico (Win95+) HKCR\icofile
.msc Win2000+ (NT) HKCR\MSCFile
.otf Win2000-Vista HKCR\otffile
.ttc Win2000-Vista HKCR\ttcfile
.ttf Win2000-Vista HKCR\ttffile
Software CLSID registry key
Win95 only HKCR\CLSID\{00028B05-0000-0000-C000-000000000046}
("Shortcut to The Microsoft Network")
Note: The (Win95+) mark in Software field means that the file type exists in
older Windows versions or DOS, but not until Windows 95 was there a file
association entry for it.
In Windows 2000, XP or Vista, the font file types ('.otf', '.ttc', '.ttf',
except '.fon') have "%1" in default values of their respective "DefaultIcon"
subkeys. Font files can never contain an icon, so it is fontext.dll that
provides the icon for those fonts (depending on format, e.g. TrueType or
"OpenType with TrueType outlines", both having '.ttf' file extension).
-------------------------------------------------------------------------------
File types that contain "IsShortcut" and "NeverShowExt" registry values:
Extension Software Class registry key a.k.a. ProgID
.appref-ms .NET2.0+ HKCR\Application.Reference
.cnf WinXP- HKCR\ConferenceLink (NetMeeting "SpeedDial")
.shb WinXP- HKCR\DocShortcut ("Shortcut into a document")
.url IE HKCR\InternetShortcut
(unused) WinVista+ HKCR\IE.AssocFile.URL
(unused) IE9+ HKCR\IE.AssocFile.WEBSITE
.website IE9+ HKCR\Microsoft.Website ("Pinned Site Shortcut")
.lnk Win95+ HKCR\lnkfile
.pif (Win95+) HKCR\piffile
.maw Office2000+ HKCR\Access.Shortcut.DataAccessPage.1
.mag Office2000+ HKCR\Access.Shortcut.Diagram.1
.maf MSOffice95+ HKCR\Access.Shortcut.Form.1
.mau OfficeXP+ HKCR\Access.Shortcut.Function.1
.mam MSOffice95+ HKCR\Access.Shortcut.Macro.1
.mad MSOffice95+ HKCR\Access.Shortcut.Module.1
.maq MSOffice95+ HKCR\Access.Shortcut.Query.1
.mar MSOffice95+ HKCR\Access.Shortcut.Report.1
.mas Office2000+ HKCR\Access.Shortcut.StoredProcedure.1
.mat MSOffice95+ HKCR\Access.Shortcut.Table.1
.mav Office2000+ HKCR\Access.Shortcut.View.1
.glk Office2007+ HKCR\GrooveLinkFile
.xnk Office2003- HKCR\xnkfile ("Exchange Shortcut", used in Outlook)
File types that contain "IsShortcut" registry values but not "NeverShowExt":
Extension Software Class registry key a.k.a. ProgID
.mcc Win95 only HKCR\Dialer10CallingCard
("Shortcut to The Microsoft Network")
.ccr MSChat HKCR\ComicChatRoomShortcut
.ccr MSChat2.5 HKCR\MicrosoftChatRoomShortcut
.WSH IE5+ HKCR\WSHFile
(Note to developers: Do not add every shortcut introduced in third party
applications. There may be countless number of them. Only note those that
appear in Windows components or Microsoft Office.)
-------------------------------------------------------------------------------
File types and CLSIDs that contain "NeverShowExt" registry values but not
"IsShortcut":
Extension Software Class registry key a.k.a. ProgID
.accountpicture-ms Win8+ HKCR\accountpicturefile
.appcontent-ms Win8.1+ HKCR\ApplicationContent
.library-ms Win7+ HKCR\LibraryFolder
.searchConnector-ms Win7+ HKCR\SearchConnectorFolder
.search-ms WinVista+ HKCR\SearchFolder ("Saved Search")
.settingcontent-ms Win8.1+ HKCR\SettingContent
.scf IE4+ HKCR\SHCmdFile ("Windows Explorer Command")
.shs WinXP- HKCR\ShellScrap ("Scrap object")
Software CLSID registry key
Win98 only HKCR\CLSID\{450D8FBA-AD25-11D0-98A8-0800361B1103} ("My Documents")
WinME+ HKCR\CLSID\{888DCA60-FC0A-11CF-8F0F-00C04FD7D062}
("Compressed (zipped) Folder SendTo Target")
HKCR\CLSID\{9E56BE60-C50F-11CF-9A2C-00A0C90A90CE} ("Mail Service")
IE4+ HKCR\CLSID\{9E56BE61-C50F-11CF-9A2C-00A0C90A90CE}
("Desktop Shortcut")
Win2000+ HKCR\CLSID\{ECF03A32-103D-11d2-854D-006008059367}
("MyDocs Drop Target")
-------------------------------------------------------------------------------
File types that are self-executable (i.e. their data of "shell\open\command"
default values begin with "%1"):
batfile, cmdfile, comfile, exefile, piffile, scrfile
For these extensions, the "NeverShowExt" value in their class keys should never
be created. It is possible to have a PE executable in one of these extensions
(even .pif!)
File types that contain "%*" in their "shell\open\command" default values:
Extension Software Class registry key a.k.a. ProgID
.bat (Win95+) HKCR\batfile
.cmd WinNT4+ HKCR\cmdfile
.com (Win95+) HKCR\comfile
.exe (Win95+) HKCR\exefile
.hta IE5+ HKCR\htafile
(unused) IE9+ HKCR\IE.AssocFile.WEBSITE
(multi) MSIME2010+ HKCR\IMEDictionaryCompiler
.JSE IE5.01+ HKCR\JSEFile
.js IE5+ HKCR\JSFile
.msu WinVista+ HKCR\Microsoft.System.Update.1 (See note below)
.website IE9+ HKCR\Microsoft.Website ("Pinned Site Shortcut")
.msc Win2000+ (NT) HKCR\MSCFile
.msi Win2000+ HKCR\Msi.Package
.msp Win2000+ HKCR\Msi.Patch
.pif (Win95+) HKCR\piffile
.VBE IE5.01+ HKCR\VBEFile
.vbs IE5+ HKCR\VBSFile
.xaml .NET3.0+ HKCR\Windows.XamlDocument
.xbap .NET3.0+ HKCR\Windows.Xbap
(multi) Win7+ HKCR\Windows.XPSReachViewer
.WSF IE5.01+ HKCR\WSFFile
.WSH IE5+ HKCR\WSHFile
(multi) .NET3.0+ HKCR\XPSViewer.Document.1
IMEDictionaryCompiler is associated with 2 file extensions: .dctx .dctxc
XPSViewer.Document.1 is associated with 3 file extensions: .dwfx .jtx .xps
Windows.XPSReachViewer is associated with 6 file extensions (7 extensions in
Windows 8 or later): .dwfx .jtx .xps .easmx .edrwx .eprtx (.oxps)
It is in Windows 8 or later that "Microsoft.System.Update.1\shell\open\command"
default value contains "%*". In Windows Vista, the value is
'"%systemroot%\system32\wusa.exe" "%1" %2 %3 %4'; in Windows 7 the value is
'"%systemroot%\system32\wusa.exe" "%1" %2 %3 %4 %5 %6 %7 %8 %9'.
.cpl (HKCR\cplfile) contains "%*" in its "shell\cplopen\command" default value.
-------------------------------------------------------------------------------
'usb_vaccine.cmd' only concerns about shortcut types that can execute arbitrary
code when user opens a file of the type. 'usb_vaccine.cmd' does these to the
aforementioned shortcut types:
- Provide optional procedures, activated via '--fix-shortcut-icon' and
'--fix-file-icon' command-line options, that restore the shortcut arrow
overlay and default icon / icon handler, respectively.
- For .pif and .shb types and symlinks, suggest to perform registry tweaks to
add visual indicators to the files' icon display (for now the tweak is to
show file extensions if user didn't hide them via "HideFileExt" option).
- Move away or delete shortcut files of these types from the root directories
of each drive.
We don't try to fix every shortcut type, but only those that are dangerous to
open. The types that we currently concern about are:
.pif, .lnk, .shb, .url, .appref-ms, .glk, and symlink.
Note: Regarding showing file extensions, we try to avoid showing extensions for
types that are common in use in Start Menu or Quick Launch bar, that is, .lnk,
.url and .scf (.scf is technically not a shortcut, but it launches commands of
Windows Explorer shell and behaves similar to a shortcut in users' eyes).
List of various shortcut types in Windows and their properties regarding
security:
Shortcut | Format | May point to | Custom | Show | Handles | Proper-
type | | executable | icon | ext. | default | ties
| | | | | verb | tab
----------+--------+----------------+--------+-------+---------+--------
.pif Binary Yes Yes[1] Never No[2] Yes
.lnk Binary Yes Yes Never Yes Yes
.url INI Yes (file://) Yes Never Yes Yes
.website INI Not executed Yes Never No No
.glk XML Yes(file://)[3] Yes Never No No
.appref-ms CSV+URL Indirect[4] Yes Never No No
Folder Direc-
Shortcut tory Not executed Yes[5] N/A No No
Symlink[6] Symlink Yes Yes[6] N/A[6] Yes[6] No
.mcc ? ? (Unknown) Yes User No Yes
.shb Binary Not executed[7] No Never No No
.WSH INI Not executed No User No Yes
.ma? INI Not executed No Never No No
.cnf INI No No Never No No
.xnk Binary ? (Unknown) No Never No No
.ccr Binary No No User No No
(This list is in no particular order.)
Fields meanings:
- May point to executable: Whether the shortcut format allows the target to be
an executable file and whether it will be executed when user opens the
shortcut. "Not executed" means the file format allows pointing to executable,
but the handler program will filter out the file type of the target and so
it's not executed.
- Custom icon: Whether the file type is associated with a custom IconHandler.
- Show ext.: Whether the file extension will be shown for the file type.
"Never" means a "NeverShowExt" value is present for the type. "User" means
the extension is shown according to user's "HideFileExt" option. "N/A" means
technically the shortcut type can have any or no extension.
- Handles default verb: "Yes" means the type is associated with a
ContextMenuHandler which may change the default (open) verb for the file. In
other words, the "shell\open\command" subkey is not reliable to determine the
default action for that type.
(<https://msdn.microsoft.com/en-us/library/windows/desktop/ee453696(v=vs.85).aspx>)
- Properties tab: Whether the file type is assigned a custom tab in the
Properties window.
Notes:
[1] Custom icon for .pif is no longer shown in Windows Vista or later.
(Reported by some users on the Internet. I couldn't find an official
document noting this change. This is nothing to do with MS10-046 lnk file
vulnerability.)
[2] The default "open" verb for .pif is handled by Windows Explorer.
[3] Office Groove 2007 launches the URL directly when user opens the shortcut.
SharePoint Workspace 2010 instead pops up a warning before launching.
However it's a bad idea to allow pointing to .exe in the first place.
[4] .appref-ms may point to remote application only (to a .manifest file).
However it may still trick users into opening and downloading the app.
[5] Windows Explorer associates Folder Shortcuts with the
"HKCR\CLSID\{0AFACED1-E828-11D1-9187-B532F1E9575D}" registry key, in which
there is "shellex\IconHandler" subkey and value.
[6] Symbolic links ("symlinks") are a kind of special files in NTFS whose file
name may be in any or no extension. Since Windows 8.1, Windows Explorer
associates file symbolic links with the "HKCR\.symlink" registry key.
Windows 7 SP1 systems will also support the "HKCR\.symlink" association if
KB3009980 hotfix is installed.
In Windows 8.1 or later, or in Windows 7 with the hotfix, the symlink type
has an IconHandler that displays the icon of the file the link points to.
(Unlike .lnk file, a symlink doesn't allow specification of a custom icon.)
The display behavior of the symlink's name extension is determined by
"NeverShowExt" or "AlwayShowExt" values in "HKCR\.symlink" key, or, if
neither of the values exist (which is the default), user's "HideFileExt"
option (which is to hide by default).
The symlink type has a ContextMenuHandler that sets the default verb of the
symlink, similar to .lnk file. However, for a symlink pointing to a .lnk
file, no verbs will be assigned for the symlink (and the symlink will show
a generic file icon). It won't resolve .lnk target from a symbolic link
pointing to a .lnk file.
In Windows Vista, 8 or 7 without the hotfix, a symlink's icon, context
menu, default verb and the display of the symlink's name extension are all
determined by the file type that the symlink's name extension corresponds
to, except that a symlink always shows a shortcut arrow overlay despite the
symlink's name extension. The file type or name extension of the symlink's
target is not considered. Windows Explorer may resolve a .lnk target from a
symlink if the symlink's name is in ".lnk" extension.
[7] It's possible to have a .shs file renamed to .shb. (The Shell Scrap handler
doesn't check whether the file extension matches the format.) .shs files
allow embedding executable code (as OLE objects).
-------------------------------------------------------------------------------
Access | Name as defined in API constant[1] | icacls | SDDL abbreviation
Mask | (Name as shown in GUI) | abbr. | (and mnemonic)[2]
----------+-------------------------------------+--------+---------------------
Bits 0-15 Object-specific Access Rights:
0x1 List directory / Read data
("List folder / read data") RD CC (Create child)
0x2 Add file / Write data
("Create files / write data") WD DC (Delete child)
0x4 Add subdirectory / Append data / Create pipe instance
("Create folders / append data") AD LC (List children)
0x8 Read EA[3]
("Read extended attributes") REA SW (Self write)
0x10 Write EA[3]
("Write extended attributes") WEA RP (Read property)
0x20 Traverse / Execute
("Traverse folder / execute file") X WP (Write property)
0x40 Delete child
("Delete subfolders and files") DC DT (Delete tree)
0x80 Read attributes ("Read attributes") RA LO (List object)
0x100 Write attributes
("Write attributes") WA CR (Control access)
Bits 16-23 Standard Access Rights:
0x10000 Delete ("Delete") DE SD (Standard delete)
0x20000 Read control ("Read permissions") Rc RC (Read control)
0x40000 Write DAC ("Change permissions") WDAC WD (Write DAC)
0x80000 Write owner ("Take ownership") WO WO (Write owner)
0x100000 Synchronize[4] S 0x100000
Bit 24 SACL Access Right:
0x1000000 Access system security (IO)[5] AS 0x1000000
Bit 25:
0x2000000 Maximum allowed (IO)[5] MA 0x2000000
Bits 26-27 (Reserved)
Bits 28-31 Generic Access Rights:
0x10000000 Generic all (IO)[6] GA GA (Generic all)
0x20000000 Generic execute (IO)[6] GE GX (Generic execute)
0x40000000 Generic write (IO)[6] GW GW (Generic write)
0x80000000 Generic read (IO)[6] GR GR (Generic read)
Other constants and sets of access rights[7]:
0x1f0000 STANDARD_RIGHTS_ALL - 0x1f0000
0xf0000 STANDARD_RIGHTS_REQUIRED - SDRCWDWO
0x20000 STANDARD_RIGHTS_EXECUTE Rc RC
0x20000 STANDARD_RIGHTS_WRITE Rc RC
0x20000 STANDARD_RIGHTS_READ Rc RC
0x1f01ff FILE_ALL_ACCESS ("Full control") F FA
0x1301bf ("Modify") M 0x1301bf
0x1200a9 ("Read & execute") RX 0x1200a9
0x1200a9 ("List folder contents") (CI)[8] RX 0x1200a9
0x1200a0 FILE_GENERIC_EXECUTE - FX
0x120089 FILE_GENERIC_READ ("Read") R FR
0x100116 ("Write") W 0x100116
0x120116 FILE_GENERIC_WRITE - FW
0x110000 (Used by 'icacls' only; no GUI name) D 0x110000
Notes:
[1] For ease of reading, sentence case is applied on the names, and the "FILE_"
prefix is omitted for File and Directory Access Rights that are in object-
specific bits range. The original constants are in SCREAMING_SNAKE_CASE.
For example, the constant for read control right is READ_CONTROL, and
constant for read data right is FILE_READ_DATA.
(<https://msdn.microsoft.com/en-us/library/windows/desktop/gg258116(v=vs.85).aspx>)
The GUI refers to the "Security" tab in files' "Properties" dialog box and
the "Advanced Security Settings" dialog box. No GUI name listed means the
right (a.k.a. permission) is not visible nor changeable in the GUI.
[2] The SDDL access right strings were intended for Active Directory objects,
hence they don't match the masks that File and Directory Access Rights use.
(<https://msdn.microsoft.com/en-us/library/windows/desktop/aa374928(v=vs.85).aspx>)
(<https://msdn.microsoft.com/en-us/library/aa772285(v=vs.85).aspx>)
A hexadecimal value on this field means no string is defined for the access
right, and that hexadecimal value must be used in SDDL ACE for the right.
[3] These mean OS/2 extended attributes.
[4] Synchronize right is noted in Windows help files but not changeable in GUI.
[5] These rights have no effect on file or directory access, however they may
be applied on directories, with Inherit Only flag (IO), for applicable
objects to inherit these.
[6] These generic rights can only be applied on directories with Inherit Only
flag (IO). Files and directories that inherit these will grant FA, FX, FW,
and FR rights to the specified user, respectively.
[7] Except for STANDARD_RIGHTS_ALL and STANDARD_RIGHTS_REQUIRED, the access
masks of all other sets might change in the future.
[8] "List folder contents" checkbox only appears when changing permissions of a
folder. While other basic permission checkboxes will apply to "This folder,
subfolders and files" (inheritance flags (OI)(CI)) when checked, "List
folder contents" applies to "This folder and subfolders" (inheritance flag
(OI) only).
It is generally unwise to set to Deny the Generic access rights or rights with
"FILE_GENERIC_" prefix, because all of said Generic rights include Synchronize
right, which may cause problems when explicitly denied. Read this for details:
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx>
-------------------------------------------------------------------------------
Important notes about commands behaviors:
1. 'icacls':
- For user names with spaces, quotes must be used. For example:
icacls foo /grant "ANONYMOUS LOGON:(OI)(CI)(RX)"
Quotes are stripped during processing of the argument. It's enough to only
quote the spaces, so this works:
icacls foo /grant ANONYMOUS" "LOGON:^(OI^)^(CI^)^(RX^)
- '/L' is not available before Windows Vista.
- The following flags and access rights have been working from the beginning
despite being undocumented or wrongly documented in help text (all corrected
in Windows 7): (I) (N) (D) (DE)
- '/Q' option doesn't supress the final "Successfully processed X files; Failed
processing Y files" message line. Windows Server 2003 SP2 'icacls' accepts
'/Q' option although it was undocumented and buggy (would always output
"Successfully processed 0 files" ignoring facts).
- '/setintegritylevel' is not available before Windows Vista.
- '/inheritance' is not available before Windows Vista SP1.
- (N) "no access" as described in "simple rights" list is only a shorthand for
(DENY)(F). (N) is invalid when specified in arguments.
- Bug: Upon querying a Deny ACE entry, Synchronize right is always displayed as
denied, ignoring facts. For example, a sole denied (RD) right displays as
(DENY)(S,RD) instead of (DENY)(RD); a sole denied (DE) right displays as
(DENY)(D) instead of (DENY)(DE). Doesn't affect '/save' option output.
2. 'attrib':
- Refuses to change attributes for Hidden or System files if the respective
'+H'/'-H' or '+S'/'-S' option is not also specified on the command line.
Requires specifying both H and S options in order to process files with both
Hidden and System attributes set.
- Follows symlinks when reading or changing attributes unless '/L' option is
specified. '/L' is not available before Windows Vista.
- Seems to always exit with status 0 despite any error; seems to output every
message, including error messages, to stdout.
3. Others:
- The %~a1 method will retrieve attributes of the link itself, if the file
referenced by %1 is a link (junction or symlink).
- DEL command exits with 1 only when arguments syntax or path is invalid. It's
exit code does not distinguish between deletion success and failure.
- MOVE command exits with 1 when a move error occurs. There's no way to specify
"don't overwrite" option for MOVE command.
- Both DEL and MOVE refuse to process files with Hidden or System (or both)
attribute set. (They'll output the "could not find" error.) However since
Windows NT, DEL supports '/A' option that can workaround this.
- If "dirlink" is a directory link (attributes "DL"), "DEL dirlink" deletes all
files in the target directory (DANGEROUS), while "RMDIR dirlink" (with or
without '/S') removes the symlink without touching anything in the target
directory (SAFE). MOVE command on links always processes links themselves
rather than link targets.
-------------------------------------------------------------------------------
The 'ASSOC' command in Windows NT is simply a registry program reading and
writing default value of "HKLM\SOFTWARE\Classes\<key>", ignoring the
equivalent key in HKCU. There is an unintentional feature: "ASSOC exefile"
works, and shows the name of the file type or ProgID in question.
Similarly, 'FTYPE' command reads and writes the "shell\open\command" subkey for
a given file type. It ignores the default value of "shell" subkey.
As Microsoft does not document the details of these commands, neither of them
are reliable across Windows versions. (Can't ensure they always read HKLM and
never HKCU.) We will just use "reg query" or "reg add" for accurate reading and
writing.
-------------------------------------------------------------------------------
Important notes about file names, long file names (LFN), "short names" (a.k.a.
8.3 file name), and how Windows processes them:
1. Long file names, as stored in NTFS and VFAT LFN entries, are all encoded in
UCS-2LE (or UTF-16LE in Windows 2000, XP or later).
2. In FAT, short names are encoded in the "character set" as defined by OS's
current "system locale" (changeable in Windows 2000, XP or later, i.e.
"Control Panel" -> "Regional Options" -> "Language for non-Unicode programs"
setting; note that this setting requires reboot and isn't what CHCP command
could change in shell environment). On a multi-byte encoding, Windows may
generate short names that contain bytes 0x5C "\" or 0x7C "|". GBK, Big5 and
Shift_JIS encodings all suffer from this because a code point like 0xE05C
may be a valid character in them.
3. Short names can be optionally generated in NTFS (it's enabled by default),
short names in NTFS are encoded in UCS-2LE or UTF-16LE and stored as
variable-length strings in on-disk format, just like long file names.
4. When reading file names, for non-Unicode programs including cmd.exe, they
are transparently converted from Unicode to the current "system locale"
encoding.
Unmappable characters are converted to question marks "?" (0x3F) on display
and command output.
5. cmd.exe has limitations and bugs regarding file name processing:
- If two files can be presented as same name in DIR output (possible when
name contains characters unmappable in shell's "active code page" (as set
by 'chcp' command) and become question marks on display), retrieving file
info via parsing DIR output may retrieve the wrong file.
Example that won't work:
FOR /F "delims=" %%I IN ('DIR /B') DO (ECHO "%%~atzfsI" & DIR "%%I")
But this works:
FOR %%I IN (*) DO (ECHO "%%~atzfsI" & DIR "%%I")
Retrieving file name via "file name completion" (tab key, or Ctrl+F and
Ctrl+D if cmd.exe is invoked with "/f:on") can refer to the correct file
even though question marks might appear on display.
- If a file's short name happens to contain a 0x5C "\" byte (for example
from a 0xE05C character) in a FAT filesystem, and the shell's "active code
page" doesn't treat a "\" byte as part of a multi-byte character, "%%~psI"
will contain part of the file name up to and including the last "\" byte,
while "%%~nsI" will have the aforementioned part of file name cut out.
Note that this bugs happens only in FAT with short names - Windows never
leaks out "\" character on interpreting UTF-16LE file names.
Algorithm of generating "short names" from long file names in Windows:
1. First, determine the "base name" and the "extension" from the file name.
Search for last period "." in the file name, and split the file name string.
Define "base name" as part of the string before the period, and "extension"
as part of the string after the period. If the file name contains no period,
then this file has no extension, and define "base name" as the whole string.
2. If "base name" is empty when determined by the method above (possible with
file names like ".bashrc"), set "extension" to empty and "base name" to what
was the "extension", and set "add suffix" flag.
3. Remove all spaces and periods "." from "base name" and "extension". If there
is any character removed, set "add suffix" flag.
4. Replace each occurrence of following characters with underscores "_":
+ , ; = [ ]
If any character get replaced this way, set "add suffix" flag.
(Multi-byte characters are not touched yet, even for those just happening to
contain any of these bytes.)
5. Convert all lowercase letters in "base name" and "extension" to UPPERCASE.
The conversion depends on OS, file system and "system locale":
- FAT in Windows 95, 98 or Me: Windows will also convert uppercased Unicode
characters to the default code page for the DOS/shell environment (e.g.
CP437 for en-US locale). If there are characters that can't be converted
to the target code page, replace them with underscores and set "add
suffix" flag.
If no characters have been uppercased or converted, and the file name
contains no underscore and no character with code point 0x7F or above, an
LFN entry will not be created for the file (unless "base name" or
"extension" exceeds the 8.3 length limit, see below).
(An LFN entry may be created unnecessarily, with the byte-identical name
if the name just happens to contain underscores and no other special
characters, e.g. "STI_CI32.DLL".)
In Turkish locale, both lowercase dotted and dotless i's are converted to
uppercase dotless I's when generating short names, uppercase dotted I's
are left as is. (I'm not sure if this behavior is intended.)
- FAT in Windows NT: Windows will also convert uppercased Unicode characters
to the default code page for the DOS/shell environment, except that visual
lookalikes may be used if there's no direct representation (e.g. "small a
with acute" converted to "A" without acute as CP437 doesn't include
"capital A with acute" despite including "small a with acute"). If there
are characters that can't be converted this way, set "add suffix" flag,
and the characters may be removed or replaced with underscores (the detail
is locale-specific).
If the file name contains no character with code point 0x80 or above, the
"base name" characters are either all UPPERCASE or all lowercase, and so
are the "extension" characters, an LFN entry will not be created for the
file (unless "base name" or "extension" exceeds the 8.3 length limit).
Windows NT logs the letter case of two strings as two flag bits in FAT
directory entry of the file. The file name will be stored in all UPPERCASE
on disk after this.
In Turkish locale, the lowercase dotless i is left as is (not uppercased),
and so is the uppercase dotted I.
In Hebrew locale, combining marks are removed because they are not
included in CP862 (DOS Hebrew code page). If there existed such marks in
the file name, set "add suffix" flag.
- NTFS: If "system locale" is not using a multi-byte encoding, Windows
removes all (Unicode) characters with code point 0x7F or above in the file
name. If there existed such characters, set "add suffix" flag.
If "system locale" is using a multi-byte encoding, Windows checks if the
file name characters can be represented in the target encoding, using the
same conversion rule as in FAT. If there are characters that can't
represent in target encoding, set "add suffix" flag, and the characters
may be removed or replaced with underscores (the detail is locale-
specific).
If "add suffix" flag is not set, and "base name" and "extension" fit the
8.3 length limit, a "short name" entry will not be created for the file.
6. If "add suffix" flag is not set, and, when represented in the current
"system locale" encoding, the "base name" is at most 8 bytes in length, and
"extension" at most 3 bytes (the "8.3 length limit"), make this "base name"
and "extension" the short name of the file. If this name has been used by
another file (with a long file name), regenerate the short name of that
file. End.
Otherwise, remove characters (not bytes) from the right of "base name" and
"extension", until "base name" is at most 6 bytes and "extension" at most
3 bytes.
7. In Windows NT only, if "base name" is at most 2 bytes at this point, append
4 uppercase hexadecimal digits from an undocumented hash of the file name.
8. Let N be 1 and "suffix" be "~1". From now on, "suffix" will be always a
tilde "~" followed by the number N formatted in decimal digits.
9. (Loop:)
Construct "name" from "base name", "suffix", a period and "extension".
If no file in the directory use this "name" as its short name, make this be
the file's short name. End.
Otherwise, a collision occurs. Increment N by 1 and go to head of (loop).
In Windows NT only, if N reaches 4 and "name" still collides at this point,
and "base name" has not been appended with the hash in step 7, remove
characters from the right of "base name" to at most 2 bytes, append 4
uppercase hexadecimal digits from an undocumented hash of the file name,
reset N to 1, and go to head of (loop). If "base name" has already been
appended with the hash, continue incrementing N and looping.
(Side note: Linux vfat driver does not implement the hash, but instead use
hexadecimal digits generated from "jiffies" and thus the digits are not
deterministic.)
If N reaches 9 and "name" still collides, truncate "base name" further to at
most 5 bytes (note: in Windows NT this can result in one digit of hash being
removed), set N to 10, and go to head of (loop).
If N reaches 99 and "name" still collides, truncate "base name" further to
at most 4 bytes, set N to 100 and continue the loop, and so on, until no
collision occurs.
Forbidden characters in long file names in Windows:
0x00-0x1F " * / : < > ? \ |
(41 characters in total)
Forbidden characters in file names in IBM PC DOS / MS-DOS (2.00 and later):
0x00-0x20 " * + , . / : ; < = > ? [ \ ] a-z |
(75 characters in total)
Forbidden characters in file names in IBM PC DOS / MS-DOS (1.x):
0x00-0x20 " * + , . / : ; = ? [ ] a-z
(71 characters in total)
Note: \ < > | was allowed in DOS 1.x, before DOS 2 introduces directories and
I/O redirection.
-------------------------------------------------------------------------------
Technical notes about users, user profiles and user registry hives in NT-based
Windows versions.
Windows DOES NOT load the registry settings (hives) of all users to the main
tree (specifically, under HKEY_USERS). Rather, only hives of the users that are
currently logged on will be loaded, as well as registry of service users.
(The "service user accounts" in Windows have similar functions as "system
users" in Unix and other operating systems.) There are 3 service users
available by default in Windows at this time:
SID Name Available since
S-1-5-18 LocalSystem ("SYSTEM") WinNT3
S-1-5-19 LocalService ("LOCAL SERVICE") WinXP
S-1-5-20 NetworkService ("NETWORK SERVICE") WinXP
See this for general information about these 3 service users:
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms686005(v=vs.85).aspx>
All NT-based Windows versions store the list of all user profiles in
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList", with users'
SIDs as subkey names. (Windows might create profile backups with key names like
"<SID>.bak" inside "ProfileList", in case that some profiles fail to logon).
For ease of documenting, we will refer to this key as the "ProfileList" key.
Forbidden characters in usernames of all NT-based Windows versions:
0x00-0x1F " * + , / : ; < = > ? [ \ ] |
(47 characters in total)
For NT-based Windows versions, the list of currently loaded hives and the file
locations of them may be seen in
"HKLM\SYSTEM\CurrentControlSet\Control\hivelist".
The locations where users' profiles and registry hives are stored differ among
Windows versions. In Windows terminology, a "user profile" consists of user
registry hives and, in Windows NT 4 or later, a set of profile folders.
Below are differences in user profiles management per Windows version.
In Windows 3.x:
There is no multi-user support at all. No user profiles or user registry.
In Windows 95, 98 and Me:
If multi-user is not enabled (which is the default), the user registry will be
"%WinDir%\USER.DAT" and loaded as "HKEY_USERS" registry key. If multi-user is
enabled, each user will have a profile folder and registry hive
"%WinDir%\Profiles\<username>\USER.DAT" (loaded as "HKU\<username>" key) as
well as local system's USER.DAT.
In addition, the list of all user profiles will be provided in
"HKLM\Software\Microsoft\Windows\CurrentVersion\ProfileList", with <username>
as subkeys. (Note: Multi-user in Windows 9x was not meant to be a security
mechanism. There's no access control in the file system level. What it does is
only separating user profiles, documents and folders.)
In Windows NT 3.x:
The "user profile" is only a registry hive. The user hives are all in
"%SystemRoot%\system32\config", with file naming like this: "first 5 characters
of username (including spaces)" + "3 lowercase hexadecimal digits" + "(no
extension)" Example: "J. Ra000" for username "J. Random Hacker".
The hive of local system user ("SYSTEM") is "%WinDir%\system32\config\default"
and loaded as "HKU\.DEFAULT". The hive template for creating new users is
"%WinDir%\system32\config\UserDef".
Registry values "ProfileImagePath" in "ProfileList\<SID>" store paths to the
hive files of the respective users (not the directories).
User's "Home folder" (a.k.a. home directory, which is distinct from "profile")
is optional and may be specified as any local path, or a network share folder
with a drive letter to "map" at login time. If the path is not specified when
creating a new user, it defaults to "C:\users\default", a common directory that
is writable by everyone (assuming your system drive is C:).
Roaming user profiles and mandatory user profiles are distinguished from local
user profiles by file extensions (.usr for roaming and .man for mandatory).
(We cannot test if Windows NT 3.x supports the "CentralProfile" registry value
(see below) or how mandatory profiles are created or managed.)
In Windows NT 4.0:
The "user profile" consist of also profile directories in Windows NT 4 or
later. The profiles directories are by default
"%SystemRoot%\Profiles\<username>". (Also, %USERPROFILE% environment variable
starts to exist and refers to the directory.) User's registry hive is
"NTUSER.DAT" in %USERPROFILE%.
The hive of local system user ("SYSTEM") is still
"%WinDir%\system32\config\default". The template profile directory for new
users is "%WinDir%\Profiles\Default User". The hive template for creating users
is NTUSER.DAT in Default User directory. "%WinDir%\Profiles\All Users" exists
and stores files shared for all users.
Registry values "ProfileImagePath" in "ProfileList\<SID>" store paths to the
profile directories, a.k.a. %USERPROFILE% for the respective users. (Local
users with their "ProfileImagePath" pointing to a hive file will, upon login,
have a profile directory created and the hive moved in there.)
User's "Home folder" is still distinct from "profile folder" and the home
folder defaults to "C:\" if not specified.
For a roaming or mandatory profile, the "CentralProfile" registry value (with
type REG_SZ) stores the path of the folder (usually a network share folder, but
a local one also works) the roaming profile is copied from and also the folder
that it will sync to when logging off. Mandatory profiles are distinguished
from roaming ones by the existence of the hive file "NTUSER.MAN" (instead of
NTUSER.DAT) in the profile directories. For local user profile, the
"CentralProfile" value exists but its data is an empty string.
In Windows 2000:
Profiles directories are by default in "%SystemDrive%\Documents and Settings".
For every user except the local system user, in addition to hive NTUSER.DAT,
user will have its registry entries under "Software\Classes" subkey stored in a
separate hive, named:
"%USERPROFILE%\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat"
UsrClass.dat files are loaded as "HKU\<SID>_Classes" key upon logon, and
"HKU\<SID>\Software\Classes" (and the respective Classes key in HKCU) will be
a link to "HKU\<SID>_Classes".
"Default User" (the template) and "All Users" (the shared files) still exist,
but their profile directories are moved to "Documents and Settings".
Registry values "AllUserProfile", "DefaultUserProfile" and "ProfileDirectory"
exist in the "ProfileList" key.
Value name Type Default data
"AllUserProfile" REG_SZ "All Users"
"DefaultUserProfile" REG_SZ "Default User"
"ProfileDirectory" REG_EXPAND_SZ "%SystemDrive%\Documents and Settings"
In "ProfileList\<SID>" key, "RefCount" value starts to exist and denotes the
number of active sessions for that user. ('usb_vaccine.cmd' will ensure this
value's data be 0 before attempting to load and edit the user's hives.)
User's "Home folder" still defaults to "C:\".
Windows 2000, XP and later separate "local" data (files) from roaming data in a
profile. Local files are not synchronized with what's in the central profile
folder when the profile is logged off. Registry value "ExcludeProfileDirs" in
key "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" determines
which sub-directories should not be synchronized upon logoff. The UsrClass.dat
mentioned above is local by default, but my be changed according to KB298960.
In Windows XP:
Two service accounts, "LocalService" and "NetworkService", are available in
addition to local system user since Windows XP. Their profile directories are
in "Documents and Settings" in Windows XP (by default; they may be changeable).
Local system user also has a profile directory, as
"%systemroot%\system32\config\systemprofile", except that registry hive is
still "%WinDir%\system32\config\default" and so there is no NTUSER.DAT for the
system profile.
SIDs and profile information of all three service accounts are available as
subkeys in the "ProfileList" key.
"HKU\S-1-5-18" key exists and links to "HKU\.DEFAULT".
User's "Home folder" defaults to %USERPROFILE%.
Windows XP is the last version that supports roaming profiles of a Windows NT
3.x format.
In Windows Vista or later:
Major changes are done in file system layout and user profiles management in
Windows Vista. Old directory layout and names are created as NTFS junction
points for backward compatibility. For brevity, directory names and junctions
for backward compatibility are omitted in this document.
A new virtual user account, "NT SERVICE\TrustedInstaller", has been introduced,
with its SID permanently being:
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
All Windows files and directories, including the root directory of the drive,
are now owned by this TrustedInstaller account upon installation. Before Vista
they have been owned by the "BUILTIN\Administrators" group (SID: S-1-5-32-544).
Profiles directories are now by default in "%SystemDrive%\Users".
UsrClass.dat for each user is now in
"%USERPROFILE%\AppData\Local\Microsoft\Windows"
"ProgramData" and "Public" directories replace "All Users" directory.
("C:\Users\All Users" becomes a symlink to "C:\ProgramData". Sub-directories
previously available in "All Users" are created as junctions in "ProgramData"
for backward compatibility, some of which point to respective sub-directories
in "Public".) Note that the layout of "Public" and "All Users" are different.
Folder names like "Shared Documents" are renamed to "Public Documents" in
abstract level.
Profile directories of LocalService and NetworkService are in
"%WinDir%\ServiceProfiles". Registry hive for local system user is
"%WinDir%\System32\config\DEFAULT" (letter casing change only).
("%WinDir%\System32\config\systemprofile\ntuser.dat" exists in Windows Vista,
7, 8 and 8.1. We haven't figured out the purpose of this hive file yet. This
file does not appear in Windows 10.)
In the "ProfileList" key, values "AllUserProfile" and "DefaultUserProfile" are
no longer available. They are replaced with "Default", "ProgramData" and
"Public" values for managing directories of Default User (template profile),
Program Data, and Public respectively. (NOTICE: This is a backward-incompatible
registry change!)
Value name Type Default data
"Default" REG_EXPAND_SZ "%SystemDrive%\Users\Default"
"ProfileDirectory" REG_EXPAND_SZ "%SystemDrive%\Users"
"ProgramData" REG_EXPAND_SZ "%SystemDrive%\ProgramData"
"Public" REG_EXPAND_SZ "%SystemDrive%\Users\Public"
Windows Vista cannot roam a user profile of Windows XP format or vice versa.
The profile formats are backward incompatible!
Roaming user profile in Windows Vista and 7 is known as "version 2" profile -
the central profile _folder_ (the one on a network share) requires a ".v2" name
suffix to distinguish from Windows 2000 / XP profiles on the network. (The
suffix isn't needed when all computers on the network use Vista or later.)
Windows Vista and later also supports "super mandatory profile", a kind of
mandatory profile with an addition that when the central profile folder cannot
be loaded, the system denies the log on instead of creating a temporary profile
for the user. Super mandatory profiles are distinguished from (normal)
mandatory profiles by the ".man" or ".man.v2" suffix on the central profile
_folder_ (the hive file should also be named "NTUSER.MAN" inside).
BACKWARD INCOMPATIBLITY WARNING: Windows 8 and 8.1 both introduced some
undocumented changes on the user profiles that makes them incompatible with
older versions of Windows, and yet they continue to use the ".v2" folder name
suffix. PROFILE CORRUPTION IS POSSIBLE if user uses a Windows 8 or 8.1 system
to logon a roaming profile created in Windows Vista / 7, or vice versa.
This error is addressed in KB2887239 (Windows 8) and KB2890783 (Windows 8.1).
(NOTE: The version suffix change is disabled by default after the hotfix is
installed. You need to manually set up a registry value to enable it. Blame
Microsoft for not caring for compatibility problem earlier!)
Windows 10 enables the ".v5" suffix by default and so no longer has the
problem. (See KB3056198)
See also: Managing Roaming User Data Deployment Guide
<https://technet.microsoft.com/en-us/library/cc766489(v=ws.10).aspx>
-------------------------------------------------------------------------------
Technical details about folders' "Web View", Desktop.ini and Folder.htt.
The "Web View" of the folders, Folder.htt, and extensions for Desktop.ini were
all introduced in Windows Desktop Update, which was a feature of IE4. (The
Desktop.ini itself was in Windows 95 earlier than Windows Desktop Update.)
Windows Desktop Update was optional for Windows 95 and NT4, but is a mandatory
feature in Windows 98 or later.
The program of the "Customize This Folder Wizard" was "ieshwiz.exe" located in
"%WinDir%\System" (for 95, 98 or Me) or "%WinDir%\System32" (for NT4 or 2000).
In 95, NT4 or 98, when user chooses to "Create or edit an HTML document",
ieshwiz.exe copys the "%webdir%\folder.htt" file to the folder to be
customized, and shows an edit screen (Notepad) of the new Folder.htt to user.
(The %webdir% refers to "C:\Windows\Web" directory, if it's not explicitly
configured otherwise. The variable does appear in registry entries.)
Windows 2000 and Me included an updated version of ieshwiz.exe that allows user
to choose one of four templates, and optionally edit it:
- Standard ("standard.htt")
- Classic (icons only) ("classic.htt")
- Simple ("starter.htt")
- Image Preview ("ImgView.htt")
If user selects ImgView.htt and doesn't select "I want to edit this template"
checkbox, ieshwiz.exe will not copy the template. Otherwise, it copies the
selected template to a new subfolder named "Folder Settings" (with Hidden and
System attributes) inside the folder to be customized (hence, "Folder Settings\
Folder.htt").
Note that standard.htt in the choice above is not the same as folder.htt.
"folder.htt" in Windows 2000 or Me was used only for uncustomized folders.
Windows XP supported Web View before SP1, but no longer included ieshwiz.exe
and .htt file was not used unless in special places (such as Desktop).
The left "Tasks" pane (note: there's no official name for this) in Windows XP
is not implemented as a .htt file. The pane is not used when a folder has a
customized Web View (either done in previous Windows version or coded by hand).
The "Customize This Folder" in Windows XP or later is a property tab instead.
(Details are documented here: <https://support.microsoft.com/kb/812003>)
Windows 2000 SP3 and later, and XP SP1 and later have Web View disabled by
default (<https://support.microsoft.com/kb/819028>). However Desktop.ini may
still be used there to specify a custom icon or background for a folder.