At 15:11 17/02/2006 -0000, you wrote:
I apologize for this second intrusion, but i have some difficulties to really understand this:
Define 'MS code'. If we're talking about leaked source code, then that is true.
But you said elsewhere that there was _no_ leaked source, so that the only problem should be with your next words:
If we're talking about small chunks of assembly from dissasembled MS binaries, then that is what the audit hopes to uncover and remove. Once the audit is complete, we can also say we know this to be true, at the moment we don't know.
... and this one sounds strange to me, because i saw several messages talking in terms of *year* (?!), for the audit.
Well, i just downloaded the ReactOS Sources, and searched for all the Files having an "__asm__" Statements inside, after having saved in a dedicated Directory, the folders: bootdata / Drivers / hal / include / lin / media / modules / ntoskrnl / regtests / services / subsys and win32api.
I did not considered the other ones because, for example, i suppose that there can be no "problem" with the [apps] Folder. ;)
The search of the Files with "_asm_" inside shows only around 80 Files found. Opening several of these Files, shows that the occurencies of "_asm_" seem to be from 1 to, say, 10. Most usually around 2 or 3. It also shows that many of these Statements cannot be any problem. Example:
{ __asm__("int $3\n\t" : /* no outputs */ : /* no inputs */) }
Some other ones, a little bit more significative look like, for example:
__asm { mov edx, Port mov edi, Buffer mov ecx, Count cld rep ins byte ptr[edi], dx }
... that do not seem to me big enough for demonstrating anything, particulary not for a so trivial code... Not considering that most of the ones i saw, were simple LOCK or INT instructions, and the like, that do not even diserve a reading.
I did not search inside _all_ files, but i had to search inside many, (say, 1/3), before i could point out an Asm Routine with more than 10 Instructions...
I stopped there, because i said to me that it was stupid to read that way, and that i was possibly missing the Files of real interrest for the Audit. But all i have seen does not explain to me, how it could ever take one year for proof-reading so few, and so small, "__asm__" statements.
What am i missing?
Betov.
rené Tournois @mailhost.geldorp.nl schrieb:
At 15:11 17/02/2006 -0000, you wrote:
I apologize for this second intrusion, but i have some difficulties to really understand this:
Define 'MS code'. If we're talking about leaked source code, then that is true.
But you said elsewhere that there was _no_ leaked source, so that the only problem should be with your next words:
It's a comments on "...that there is still no Microsoft-Code found in ROS." It is true that there is *no* leaked source code inside reactos.
If we're talking about small chunks of assembly from dissasembled MS binaries, then that is what the audit hopes to uncover and remove. Once the audit is complete, we can also say we know this to be true, at the moment we don't know.
... and this one sounds strange to me, because i saw several messages talking in terms of *year* (?!), for the audit.
Well, i just downloaded the ReactOS Sources, and searched for all the Files having an "__asm__" Statements inside, after having saved in a [...]
I think this only applies to the bootsector, wich has asm directly taken from disassemblies in it.
I stopped there, because i said to me that it was stupid to read that way, and that i was possibly missing the Files of real interrest for the Audit. But all i have seen does not explain to me, how it could ever take one year for proof-reading so few, and so small, "__asm__" statements.
What am i missing?
I think what Ged was talking about was disassemblies converted into C. And this can be found by looking for typical things of that kind of code: - Magical number inside C code. Normally constants are used or the numbers are commented or really obvios. But when you don't know why there's a constant 0x2342 then you don't really know how to call it. In disc.c there's a constant called PARTITION_MAGIC ;-) - excessive gotos: You would normally not use any gotos, but it can be hard to identify complex structures of for, if, while,... inside asm code, so you do it like it's done in asm: with gotos. It doesn't look good, but it works.
Timo Kreuzer wrote:
rené Tournois @mailhost.geldorp.nl schrieb:
At 15:11 17/02/2006 -0000, you wrote:
I apologize for this second intrusion, but i have some difficulties to really understand this:
Define 'MS code'. If we're talking about leaked source code, then that is true.
But you said elsewhere that there was _no_ leaked source, so that the only problem should be with your next words:
It's a comments on "...that there is still no Microsoft-Code found in ROS." It is true that there is *no* leaked source code inside reactos.
If we're talking about small chunks of assembly from dissasembled MS binaries, then that is what the audit hopes to uncover and remove. Once the audit is complete, we can also say we know this to be true, at the moment we don't know.
... and this one sounds strange to me, because i saw several messages talking in terms of *year* (?!), for the audit.
Well, i just downloaded the ReactOS Sources, and searched for all the Files having an "__asm__" Statements inside, after having saved in a [...]
I think this only applies to the bootsector, wich has asm directly taken from disassemblies in it.
I stopped there, because i said to me that it was stupid to read that way, and that i was possibly missing the Files of real interrest for the Audit. But all i have seen does not explain to me, how it could ever take one year for proof-reading so few, and so small, "__asm__" statements.
What am i missing?
I think what Ged was talking about was disassemblies converted into C. And this can be found by looking for typical things of that kind of code:
- Magical number inside C code. Normally constants are used or the
numbers are commented or really obvios. But when you don't know why there's a constant 0x2342 then you don't really know how to call it. In disc.c there's a constant called PARTITION_MAGIC ;-)
WINE code is supposedly "clean as crystal" yet their low-level native modules/kernel libraries are full of magic numbers. All my kernel code is reversed and doesn't have a single magic constant.
- excessive gotos: You would normally not use any gotos, but it can be
hard to identify complex structures of for, if, while,... inside asm code, so you do it like it's done in asm: with gotos. It doesn't look good, but it works.
A good reverser such as myself can identify the complex structures. A bad coder can implement clean code with lots of gotos.
In the end, one of the best ways to figure out if something is reversed is not the code style, but the code quality. You tell yourself "Ok..so here we have a low-level kernel function that no driver out there uses, and which has absolutely no test case, but has 500 lines of perfectly implemented code which seem to magically know how to handle every combination of parameters, flags and situations. How was this coded?"
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
What Alex said is quite logical.
Alex Ionescu wrote:
Timo Kreuzer wrote:
rené Tournois @mailhost.geldorp.nl schrieb:
At 15:11 17/02/2006 -0000, you wrote:
I apologize for this second intrusion, but i have some difficulties to really understand this:
Define 'MS code'. If we're talking about leaked source code, then that is true.
But you said elsewhere that there was _no_ leaked source, so that the only problem should be with your next words:
It's a comments on "...that there is still no Microsoft-Code found in ROS." It is true that there is *no* leaked source code inside reactos.
If we're talking about small chunks of assembly from dissasembled MS binaries, then that is what the audit hopes to uncover and remove. Once the audit is complete, we can also say we know this to be true, at the moment we don't know.
... and this one sounds strange to me, because i saw several messages talking in terms of *year* (?!), for the audit.
Well, i just downloaded the ReactOS Sources, and searched for all the Files having an "__asm__" Statements inside, after having saved in a [...]
I think this only applies to the bootsector, wich has asm directly taken from disassemblies in it.
I stopped there, because i said to me that it was stupid to read that way, and that i was possibly missing the Files of real interrest for the Audit. But all i have seen does not explain to me, how it could ever take one year for proof-reading so few, and so small, "__asm__" statements.
What am i missing?
I think what Ged was talking about was disassemblies converted into C. And this can be found by looking for typical things of that kind of code:
- Magical number inside C code. Normally constants are used or the
numbers are commented or really obvios. But when you don't know why there's a constant 0x2342 then you don't really know how to call it. In disc.c there's a constant called PARTITION_MAGIC ;-)
WINE code is supposedly "clean as crystal" yet their low-level native modules/kernel libraries are full of magic numbers. All my kernel code is reversed and doesn't have a single magic constant.
- excessive gotos: You would normally not use any gotos, but it can
be hard to identify complex structures of for, if, while,... inside asm code, so you do it like it's done in asm: with gotos. It doesn't look good, but it works.
A good reverser such as myself can identify the complex structures. A bad coder can implement clean code with lots of gotos.
In the end, one of the best ways to figure out if something is reversed is not the code style, but the code quality. You tell yourself "Ok..so here we have a low-level kernel function that no driver out there uses, and which has absolutely no test case, but has 500 lines of perfectly implemented code which seem to magically know how to handle every combination of parameters, flags and situations. How was this coded?"
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
On 2/17/06, Jerry crashfourit@gmail.com wrote:
What Alex said is quite logical.
Logic left this project quite a while ago.
WD
Alex Ionescu wrote:
WINE code is supposedly "clean as crystal" yet their low-level native modules/kernel libraries are full of magic numbers. All my kernel code is reversed and doesn't have a single magic constant.
muuhuhaa ha ha ha ha! Yeah! Spotless!
8^D
Thanks, James