9 May
2005
9 May
'05
12:11 p.m.
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
9 May
9 May
1:20 p.m.
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
2:14 p.m.
Alex Ionescu wrote:
2) 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
4:27 p.m.
Thomas Weidenmueller wrote:
Alex Ionescu wrote:
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.
2) 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.
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
2:53 p.m.
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
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.
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.
2) 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
4:33 p.m.
Javier Muñoz Mellid wrote:
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.
Exactly.
I know they are easy, I was talking so one of the developers about
implementing them; that's not the point.
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
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.
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. 2) 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)
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.
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
6:24 p.m.
Alex Ionescu 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 ?
Thanks.
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.
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. 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
6:48 p.m.
Javier Muñoz Mellid wrote:
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.
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.
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
7073
days inactive
7073
days old
7 comments
3 participants
participants (3)
-
Alex Ionescu -
Javier Muñoz Mellid -
Thomas Weidenmueller