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
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)?
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).
Mariusz Pluciński
On 5/30/2010 21:41, 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.
Hi, Mariusz.
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
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)?
The main method is to write test.
Reading headers is allowed of course, the rule here is not to copy code blocks from them to Wine's headers. Clean way is to study, then close it and write it itself.
Windows registry editor doesn't hide things AFAIK, so you obviously can read keynames, default values etc. Wine uses same namings for keys for compatibility reasons, so that's allowed.
I don't know what kind of information is store in .pdb files, but assuming it's a private binary format for machine consumption I think you should avoid it.
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).
It depends what executable are you talking about. If it's your program but linked (or uses) to a module you're testing AND this native module is setup to be used by Wine - then no, you can't.
In general Wine's tracing functionality shouldn't be used to get inside native modules provided by MS to re-implement them. Often it happens that users do +relay by request for bug reports for example, I believe this is fine as long as you don't use this trace data to implement module.
Mariusz Pluciński
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
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.
.pdb files should not be used. For instance they show internal data structures, internal functions and much more. Stay away from them.
Roderick
-
James McKenzie -
Mariusz Pluciński -
Nikolay Sivov -
Roderick Colenbrander