creating a SECURITY_DESCRIPTOR for an independant Thread

[TouEnMasm]

I have not found a sample on this in the forum,so I post it.
The easy part is when you want to modify the access right for the CurrentProcess (You are in).
The SECURITY_DESCRIPTOR is given by the system.
For  an indepedant thread (createthread) you must first create the SECURITY_DESCRIPTOR.
create the thread
If you want to modify his access rights,you need to post a message after createthread.
When the thread begin call
invoke ImpersonateSelf,SecurityImpersonation OR SecurityIdentification
When you receive the message:
invoke OpenThreadToken ......

If you call  OpenThreadToken just after createthread "The jeton doesn't exist"
need perhaps some improvements.

[Zen]

TOUTENMASM,
I downloaded your code and made a quick reconnaissance. Thanks,...this is very useful.
I will study it more extensively at my leisure.

...Oh,...and by the way,...

If you call  OpenThreadToken just after createthread "The jeton doesn't exist"

This is pretty typical, in my limited experience. The SDK code samples that I've seen recomend that you call OpenThreadToken. Normally, it fails, returning: ERROR_NO_TOKEN,...and, then you call: OpenProcessToken

[Fribernip]

Every time there is a problem, it will just sit back and read this whole time.

[TouEnMasm]

I recently read a post saying "Windows 10 security is a Nightmare"
I's not false,I will try here to made thing a little less unclear.

A very usable sample on the subject is here:
Display security descriptor of various Windows kernel objects (CppCheckSD)
https://code.msdn.microsoft.com/windowsapps/CppCheckSD-6bac6d3a

To avoid the search of the language used:
MSDN Security Descriptor String Format
https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa379570(v=vs.85).aspx
The bottom of the page is usefull

[TouEnMasm]

A little nightmare wit files.
I have further programs who save data in subdirectory\files .
I put one Under Windows 10 in C:\Program Files (x86)
What happen ?,all work perfectly but saved files stay blank without any errors.
The question is,which flag to use to know there is a problem ?
I find this one,FILE_ATTRIBUTE_VIRTUAL:
The file is not show,don't exist (sometimes he can be visible) and don't generate errors at all.

OpenForWrite proc NomaOuvrir:Dword
   Local file_information:BY_HANDLE_FILE_INFORMATION,buffer[50h]:BYTE
   Local retour:DWORD
   mov retour,0
           invoke CreateFile,NomaOuvrir,\
                        GENERIC_WRITE,NULL,\
                        NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,0
   mov retour,eax
             .if eax !=INVALID_HANDLE_VALUE
         invoke GetFileInformationByHandle,retour,addr file_information   
         mov eax,file_information.dwFileAttributes
         and eax,FILE_ATTRIBUTE_VIRTUAL
         .if eax != 0
            invoke CloseHandle,retour
            mov retour,INVALID_HANDLE_VALUE
            invoke MessageBox,NULL,addr path_error,addr titre,MB_OK         
         .endif
       .endif
      findeaOuvrirEcriture:
   mov eax,retour             
             ret
OpenForWrite endp

 

[fearless]

I think it might have to do with UAC access, programs writing to Program Files & (x86) Program Files is not recommended for win7 upwards from what i remember, hence the existance and use of the ProgramData folder for programs to store data there or Users\<userprofilename>\AppData\Roaming or Local folders.

Might be a bit like the System | sysWOW64 folders and wow64 redirecting files virtually.

Try program in its own folder c:\myapp and see if files are created, if they are then you can sure its a UAC / system 'feature' that is preventing them being written to the Program Files | (x86) Program Files folders