Create c: \ con.txt? Windows File System Vulnerabilities

Will you create c: \ con.txt? -- Windows File System Vulnerability
Alas, all the previous nonsense headers are lost. Tell me if there are any errors.
----------------------------
If you are thinking about con.txt, isn't it normal? Well, you should first create a file with an independent con, and then you will find out what you want to read. Article (If you use Linux, Mac, or UNIX, forget it ).

Normally, files or directories with the terms con, PRN, and COM1 cannot be created (for your own reasons), but I think of an article that was previously focused on security, it teaches you how to create a folder. At that time, the method was created using the Console Command (if you call the doscommand, It is not standard) mkdir CSK. It seems that this is a Windows File System Vulnerability, right ......

Later, I was thinking about the principle. Maybe you will find something like the above CSK .. \ After creation, it is CSK ., windows actually interpreted it as accessing mkdir CSK. \ directory. It seems that some characters were omitted during creation. By chance, I found that mkdir c: \ con \ was successful. The C: \ con folder appears under C and cannot be deleted ...... A bug ......

I suddenly thought of the possible reason: First, you must verify the correctness of the directory when creating the directory. For example, c: \ dir \ must have omitted the \ symbol first, but what about the content? It seems that Windows does not check ...... Otherwise, mkdir c: \ con \ should fail, and mkdir c: \ con is definitely invalid.

So I was wondering if the files I created could also use this vulnerability to win some checks on the Windows file system? As you can see, I have succeeded ^-^

In The Same go, this is not an image, but a real con.txt. In fact, the principle is similar to the above speculation, but due to limited time, my analysis is not necessarily correct. The specific cracking process is as follows:
2005.8.1: 23: 00
first, I want to know the root cause of mkdircreation, so I can take ollydbgto cmd.exe (mkdir is an internal command, but I don't know who he is looking ?). Then we set a breakpoint for kernel32.createdirectoryw, And it was interrupted after mkdir c: \ con \ was input. Createdirectoryw:
pushed
7c81e97f 50 push eax
7c81e980 57 push EDI
7c81e981 ff15 3c11807c call dword ptr ds: [<& NTDLL. rtlDosPathNameToNtPathName_U >>< br>; NTDLL. latency
7c81e987 84c0 test Al, Al
7c81e989 0f84 8aca0100 je 133
7c81e98f 66: 817d F4 f001 CMP word ptr ss: [EBP-C], 1f0
7c81e995 0f87 8cca0100 ja kernel32.7c83b427
7c81e99b 8b45 F8 mov eax, dword ptr ss: [ebp-8]

----------------------------------------------------------------
Note that the above API: RtlDosPathNameToNtPathName_U, after the execution is complete, SS: [ebp-8] points to the location where :\?? \ C: \ con \ (UNICODE ).
ThenProgramRun the following command:
7c81e9fe ff15 0810807c call dword ptr ds: [<& NTDLL. ntcreatefile>]
Oh, native's file creation, so far c: \ con has been on your hard disk, from which you can guess that \?? \ C: \ con \ (UNICODE) is the final generated path.
You must use RD c: \ con \ to delete the directory!

Then try mkdir c: \ con: To continue tracking. Although NTDLL. ntcreatefile is also reached, it is obvious that function execution has failed ...... However, it can be clarified that createdirectoryw does not seem to check the file validity ......

But I'm not convinced, think of that \?? \ C: \ con \ (UNICODE) always serves this starting point, so the mkdir c: \ coo is used again.

Then run NTDLL. RtlDosPathNameToNtPathName_U and find the Unicode address: dword ptr ss: [ebp-8], which was 0x001581e8,
Therefore, the memory modification is Enabled:
Find the address first:
001581e0 47 00 45 00 0f 07 1E 00 5C 00 3f 00 3f 00 5C 00 g.e.