Hi there,
It'd be very appreciated if some fellow with write access can commit this patch.
It implements SeCreateAccessState, SeDeleteAccessState and SeSetAccessStateGenericMapping.
It defines an opaque structure for _ACCESS_STATE too.
Best regards, -Javier
Javier Muñoz Mellid wrote:
Hi there,
It'd be very appreciated if some fellow with write access can commit this patch.
It implements SeCreateAccessState, SeDeleteAccessState and SeSetAccessStateGenericMapping.
It defines an opaque structure for _ACCESS_STATE too.
Best regards, -Javier
And I would very much appreciate to know
1) Why you had to reverse an opaque structure: a) It's easy to guess the layout since it was created in NT4 to manage something new added post NT 3.5.1 b) There's no point in cloning something so opaque that it's not even in the symbols, since nobody could possibly be using it.
2) How you knew that the third member of that structure (or that it even exists) is an ACCESS_MASK called AccessesToAudit.
I've looked at the functions you implemented and it isn't used anywhere. I've looked with IDA at the binaries, and it's not used anywhere either.
Best regards, Alex Ionescu
Alex Ionescu wrote:
- How you knew that the third member of that structure (or that it even
exists) is an ACCESS_MASK called AccessesToAudit.
If you know, why shouldn't he know? From what I understand the entire structure is opaque, so my guess is that the names are just guessed, based on the obviously known layout.
Thomas
Thomas Weidenmueller wrote:
Alex Ionescu wrote:
- How you knew that the third member of that structure (or that it even
exists) is an ACCESS_MASK called AccessesToAudit.
If you know, why shouldn't he know?
I DON'T know. That's the point. It's impossible to guess something that doesn't exist in the ntoskrnl.exe binary unless you have access to the Windows Source Code; that's my point.
From what I understand the entire structure is opaque, so my guess is that the names are just guessed, based on the obviously known layout.
The third member is not part of a known layout. It isn't referenced ANYWHERE in the binary. You could spend your life reversing the entire binary and only the first two members would appear.
Thomas
Best regards, Alex Ionescu
Hello Alex,
I have a very bad english so give me a chance if you don't understand all my words :(
This is my first contact with ReactOS development. I am looking in code and learning a lot of things here. I want to contribute and i think that i am a "acceptable" reverser so i followed a blackbox approach with this patch byte to byte.
And I would very much appreciate to know
- Why you had to reverse an opaque structure: a) It's easy to guess the layout since it was created in NT4 to
manage something new added post NT 3.5.1 b) There's no point in cloning something so opaque that it's not even in the symbols, since nobody could possibly be using it.
You're right but i think that if we get the best match against opaque structures we aren't going to have to change (a lot of) code in the future to adjust "undocumented" drivers by Msoft or 3rd parties. It is my opinion only. For example, i am viewing some drivers incorporating undocumented calls and structures from books like "Undocumented NT" and similar. If we know those structures i think that we can add them. It isn't a design problem and it is only a future's choice.
- How you knew that the third member of that structure (or that it even
exists) is an ACCESS_MASK called AccessesToAudit.
When i began to reverse SeCreateAccessState it only touch PrivilegedUsed and GenericMapping so i get the types and sizes then i mail out my question in our University list at Coruna. I was replied with the structure that i add in the .h It's similar to previous choice. I only need two fields but i was provided with a structure and it has a better match that mine so i add the second (Copy&Paste)
I've looked at the functions you implemented and it isn't used anywhere. I've looked with IDA at the binaries, and it's not used anywhere either.
Alex, i read TODO and Security is a beautiful field to me. I grep the unimplemented functions and i found three easy funtions in access.c They were a good choice because they aren't touched for more experienced programmers and so i could implement freely. They look like basic stones to more complicated functions so i can continue adding code in my possibilities.
If you want i can attach in this list my SeCreateAccessState's dead-listing from Windows XP no-sp (Spanish version).
-Javier
Javier Muñoz Mellid wrote:
Hello Alex,
I have a very bad english so give me a chance if you don't understand all my words :(
This is my first contact with ReactOS development. I am looking in code and learning a lot of things here. I want to contribute and i think that i am a "acceptable" reverser so i followed a blackbox approach with this patch byte to byte.
I don't have anything against that. Btw, you missed a call to SeCaptureSubjectContext in SeCreateAccessState.
And I would very much appreciate to know
- Why you had to reverse an opaque structure: a) It's easy to guess the layout since it was created in NT4 to
manage something new added post NT 3.5.1 b) There's no point in cloning something so opaque that it's not even in the symbols, since nobody could possibly be using it.
You're right but i think that if we get the best match against opaque structures we aren't going to have to change (a lot of) code in the future to adjust "undocumented" drivers by Msoft or 3rd parties. It is my opinion only. For example, i am viewing some drivers incorporating undocumented calls and structures from books like "Undocumented NT" and similar. If we know those structures i think that we can add them. It isn't a design problem and it is only a future's choice.
I totally agree with this as well, this has always been my opinion. But the AUX_DATA structure has been specifically opaqued by Microsoft, and never published anywhere.
- How you knew that the third member of that structure (or that it
even exists) is an ACCESS_MASK called AccessesToAudit.
When i began to reverse SeCreateAccessState it only touch PrivilegedUsed and GenericMapping
Exactly.
so i get the types and sizes then i mail out my question in our University list at Coruna. I was replied with the structure that i add in the .h It's similar to previous choice. I only need two fields but i was provided with a structure and it has a better match that mine so i add the second (Copy&Paste)
You ended up adding a structure from the Windows Source Code into your patch. Perhaps your university has legal access to it through the Microsoft Shared Source Code Initiative.
I've looked at the functions you implemented and it isn't used anywhere. I've looked with IDA at the binaries, and it's not used anywhere either.
Alex, i read TODO and Security is a beautiful field to me. I grep the unimplemented functions and i found three easy funtions in access.c They were a good choice because they aren't touched for more experienced programmers and so i could implement freely. They look like basic stones to more complicated functions so i can continue adding code in my possibilities.
I know they are easy, I was talking so one of the developers about implementing them; that's not the point.
If you want i can attach in this list my SeCreateAccessState's dead-listing from Windows XP no-sp (Spanish version).
No, it's ok.
-Javier ______
The problem which I have is that the binary only accesses the first two members of that structure. There is no way anyone could've known the function of the third member ( I didn't even think/know one existed) since it is currently unused, even in Windows Server 2003. Therefore I must conclude it was added from internal microsoft headers which were emailed to you.
Best regards, Alex Ionescu
Alex Ionescu wrote:
This is my first contact with ReactOS development. I am looking in code and learning a lot of things here. I want to contribute and i think that i am a "acceptable" reverser so i followed a blackbox approach with this patch byte to byte.
I don't have anything against that. Btw, you missed a call to SeCaptureSubjectContext in SeCreateAccessState.
I am not viewing one second call to SeCaptureSubjectContext. I back-reverse from WinXP no-sp and it only take one call. Can you mail me version and SP to check ?
If you want i can attach in this list my SeCreateAccessState's dead-listing from Windows XP no-sp (Spanish version).
No, it's ok.
Thanks.
The problem which I have is that the binary only accesses the first two members of that structure. There is no way anyone could've known the function of the third member ( I didn't even think/know one existed) since it is currently unused, even in Windows Server 2003. Therefore I must conclude it was added from internal microsoft headers which were emailed to you.
Headers weren't emailed to me. Structure yes and it didn't contain any reference to Msoft headers.
Anyway the point is that we know that the original structure have tree members. It is publicly know in a legal or ilegal way but we can't add that structure because Google doesn't reference that third member and public code references doesn't exist.
Ok, functions doesn't need that third member so we can delete it.
Alex, my problem is that i get that information with a single question in an internal but public list to students and professors. When i change my raw structure by that best match i was thinking in code calculating sizeofs or allocating memory internally by drivers programmed for Windows where we have only the binary.
My question is about closed-source drivers. Imagine that they allocate that opaque structure and then they zeroed with a sizeof(). I am sure that it should get problems. I think that if we know a structure we should can add it avoiding future crashes but i get your point perfectly.
so what do you think about erase the third member and keep the two field touched by SeCreateAccessState ?
-Javier
Javier Muñoz Mellid wrote:
I am not viewing one second call to SeCaptureSubjectContext. I back-reverse from WinXP no-sp and it only take one call. Can you mail me version and SP to check ?
Sorry, I didnt' see you were already calling it. Forget what I said.
If you want i can attach in this list my SeCreateAccessState's dead-listing from Windows XP no-sp (Spanish version).
No, it's ok.
Thanks.
Headers weren't emailed to me. Structure yes and it didn't contain any reference to Msoft headers.
But it could've only came from them.
Anyway the point is that we know that the original structure have tree members.
Right, after playing around with the stack of an Ob* function i noticed the size was 0xC bytes. Took a damn long time.
It is publicly know in a legal or ilegal way but we can't add that structure because Google doesn't reference that third member and public code references doesn't exist.
Ok, functions doesn't need that third member so we can delete it.
Not quite delete it.
Alex, my problem is that i get that information with a single question in an internal but public list to students and professors. When i change my raw structure by that best match i was thinking in code calculating sizeofs or allocating memory internally by drivers programmed for Windows where we have only the binary.
I seriously doubt drivers need to use access states (I don't even know why MS exported that API), much less know anythign about AuxData.
My question is about closed-source drivers. Imagine that they allocate that opaque structure and then they zeroed with a sizeof(). I am sure that it should get problems.
Right, which is why we can't delete it.
I think that if we know a structure we should can add it avoiding future crashes but i get your point perfectly.
Yeah, but the question is how did you come to know upon it.
so what do you think about erase the third member and keep the two field touched by SeCreateAccessState ?
It should be renamed to ULONG Reserved; I'll fix up your patch and commit it.
We are really in need of someone experienced with Se*; we do have Eric Kohl but he's been very busy lately. but I also hope you also know some of NT's design and won't spend days reversing Windows; to tell you the truth, we really don't like that approach unless it is the only approach left and it is really needed. It would've been easy to write these functions from scratch just by looking at the public ACCESS_STATE structure and figuring out what goes in AuxData; you would've avoided many problems by doing just that. Reversing shoudln't be a solution, it's should be a last-chance attempt.
-Javier
Best regards, Alex Ionescu
-
Alex Ionescu -
Javier Muñoz Mellid -
Thomas Weidenmueller