Allowed reverse engineering methods

[James McKenzie]

Mariusz Pluciński wrote:
> Hello
> I'm working on implementation of Games Explorer for Wine
> (in Google Summer of Code). My work gets progress, but to
> finish it, I need to get more information about Windows
> implementation.
>
> My question is: which reverse engineering methods are
> legal and accepted while working in Wine project?
> Only information I found is located on Wine's wiki page
> (http://wiki.winehq.org/SummerOfCode):
>
>   
>>  *  You are not allowed to read or reuse Windows source code
>> (leaked source / Windows >Research Kernel* / ...)
>> (* we are following the SFLC's advice)
>>  *  You are not allowed to reverse engineer Windows files by
>> disassembling or >decompiling them
>>  *  You are not allowed to analyze Windows files with the
>> trace functions of Wine
>>     
>
>   
These are just the start.  Any 'black box' method would be considered 
legal.  So, you can go to MSDN, find the function and then run that 
function as a conformance test against the .dll that provides the 
function.  For instance, a few others and I are working on the 
EM_FORMATRANGE function as provided in riched20.dll.  We first wrote 
some tests that comply with what is in MSDN, and these tests are in 
/dlls/riched20/tests/editor.c.  We then implemented code that reproduced 
these tests and gave the same result.  However, this did not implement 
the full functionality of the the call.  So, we wrote more tests, ran 
them against the .dll and retrieved the output.  We then implemented 
more code to reproduce the call.  This cycle should continue until:

1.  You run out of test cases.
2.  You cannot go any further in your implementation (that means all 
test cases are covered and all of the intended functions are implemented).

Under NO circumstances are you to 'look under the hood' or to examine 
dll code directly.

> But which methods are allowed? I assume that "obvious"
> methods (reading header files, registry dumps, etc.) are
> acceptable, but can I e.g. analyze .pdb symbol files
> (availble in e.g. Microsoft's DirectX SDK)?
>
>   
You can do the above as long as they are readily available.   The .pdb 
files are accessible to all, then you can use them.  If you have to copy 
them from a running Windows installation, they are not.

> Can I copy executable from Windows (.exe) and analyze it in Wine
> using winedebug's "relay" channel? (last point from website
> I linked above says that I can't analyze "Windows files" this way,
> but I'm not sure is it apply for executables in way I described).
>
>   
If you have a program that is available, you can analyze what Wine's 
code is doing.  You cannot substitute in a Windows native dll and do this. 

Again, anything that is allowed in black box is allowed in Wine. 

So, if a program expects input A and Wine's code gives input B, then you 
have to figure out what needs to be added without looking at code and 
how Windows implements a certain function.   One thing is that you can 
look on the web for hints and tricks (they have to be evaluated very 
closely as if they are partial/complete traces of Windows functions, 
then they are not allowed as these are not 'black box'.)

I know this is not very clear, but what are you trying to do and maybe 
we can give you hints and advice on where to go next.

James McKenzie