OSDev.org

Posted: **Sun Oct 26, 2008 12:36 pm**

Hi,

TheDragon wrote:What do you mean by embedded data and trashing it?

I mean data that happens to be mixed in with the code (and not in a separate section like the ".data" section, where it can easily be identified as data). By "trashing" I mean accidentally corrupting it.

For example, imagine if my application contains something like this:

Code: Select all

myFunction:
    mov eax,0x12345678
    int 0x80                     ;<-call windows API (not sure what it actually looks like)
    mov eax,[esp+4]
    mov ebx,[esp+8]
    jmp [.myTable + eax*4 + ebx]

.myTable:
    dd 0x90909090, 0x000080CD, 0x00000000

Your utility will look at this code, and might think the code is:

Code: Select all

    mov eax,0x12345678
    int 0x80                     ;<-call windows API (not sure what it actually looks like)
    mov eax,[esp+4]
    mov ebx,[esp+8]
    jmp [.myTable + eax*4 + ebx]
    nop
    nop
    nop
    nop
    int 0x80                     ;<-possibly another windows API call?
    add eax,???

In this case, your utility might convert it into:

Code: Select all

    mov eax,0x87654321
    mov ebx,0x12345678
    syscall                     ;<-equivelent API function for your OS
    mov eax,[esp+4]
    mov ebx,[esp+8]
    jmp [.myTable + eax*4 + ebx]
    nop
    nop
    nop
    nop
    mov eax,0x87654321
    syscall                     ;<-equivelent API function for your OS
    add eax,???

Now, not only would this mess up the jump table but you've also inserted bytes (due to different kernel APIs) and you'd need to recalculate every dword in the table. You've also got no way of knowing how large the table is - maybe the table only had one entry and you did the right thing when you changed the bytes after the first entry, but maybe the table had 8000 entries and you corrupted lots of data.

To avoid things like this you'd need to interpret every instruction, one by one, starting from the entry point and following every path from every branch (for e.g. for "jc .foo" you'd need to interpret the "branch taken" path and the "branch not taken" path), while keeping track of which instructions actually were instructions.

Maybe your OS is fundamentally different to Windows in some way. For a simple example, maybe your "open a file" API function returns a "this file is too smelly" error code that Windows doesn't support, so when the application tries to open a file there's no code in the application to handle your extra error code and your utility needs to automatically generate code that makes sense for the application (should it create a dialog box, or retry, or exit the application, or try a different file name? I don't know, but your utility would need to automatically figure out what it should do).

Just for fun, write down a very minimal specification for your kernel API that's just enough to display "Hello World". Then create a "Hello World" console application for Windows and disassemble it. See if you can convert the resulting disassembly (by hand) into something that might run using your kernel API. This might sound like an very simple task to you. I think it'd be valuable "proof of concept" exercise just to see how viable your utility will be...

TheDragon wrote:But I think we are getting off topic here... Is this LEGAL OR NOT?

IMHO the utility itself would be legal, but using the utility may or may not be legal depending on what you use the utility on and which country you happen to be in. In most countries, if you've got a legal original copy of the application then I think you can call it "fair use" and it would be legal to use the utility (but the legal definition for "fair use" in Australia is more specific, so it may or may not be legal where I live). However, I'm not a lawyer, and I am only considering copyright law. EULA's are a completely different issue...

Cheers,

Brendan

Posted: **Sun Oct 26, 2008 12:58 pm**

TheDragon wrote:And suppose I redesign it so it comes out as one big assembly file and reassemble it into my exe format.

And I think the original design will be OK as long as I never assume anything (that's how fatal bugs make their living).

Remember that modern executables are not globs of standalone machine code. Most executables today rely on system services and shared libraries unique to the specific operating system. You can't just expect to disassemble a Windows executable, reassemble it in your executable format, and for it to magically work on your OS. That's the fatal assumption in this case: it's not that simple.

Wine takes the *easy* way by emulating a Windows environment and API, and acting as a layer between the Windows applications and Linux. What you propose to do is the difficult way, which is to actually disassemble then parse every executable and DLL and change all the code and API calls into something that can be directly understood by your OS without any intermediate layer. What is the probability that your OS will have an API that can perform an acceptable majority of what Windows does and emulating how it gets done? And there remains the issue of accurately converting Windows API calls into ones for your OS.

TheDragon wrote:But I think we are getting off topic here... Is this LEGAL OR NOT?

Sadly, though the utility may be legal, its use probably isn't. First, you're circumventing how applications are sold by developers and how they're used to target specific platforms. You're also decompiling and rewriting their programs without their consent and passing the program off as "their" program, though your utility has edited it. You're also inconveniencing the creators of the application, because you're recompiling their application without their consent. How badly the recompiled version performs negatively impacts the creators of the application, though it's technically your utility's fault, not theirs. You could say Wine is acceptable because the application remains the same, and any disparity with how the application performs on Wine and natively on Windows is most likely due to an inaccurate emulation of the Windows environment by Wine. You should let the creators make their application available cross-platform, instead of taking on that task yourself.

Brendan wrote: Alternatively, let's assume that your utility always works perfectly and there's never any legal problems; but nobody every writes any applications for your OS because it makes more sense to write a Windows application and then convert it to your OS; and that nobody ever uses your OS because all of the applications run on Windows anyway and it's easier to just keep using Windows than to mess around installing an OS that didn't come with the computer.

Ah, now this is something I would have completely missed. If your utility always works perfectly without legal problems, what incentive would developers have to develop specifically for your platform? To them, it would make much more sense to continue developing Windows applications (being the bigger and greater-supported market) and simply leave the option open for users to use your utility to convert their apps to your OS platform. This is a bad thing, because though you've allowed people to run Windows apps on your OS, you'll be stuck with having to continually keep your utility up to speed with Windows, carry a lot of backward-compatibility baggage, and reduce the potential of having developers specifically target your OS.

Because your idea is probably ILLEGAL and its results undesirable, I would strongly advise anyone against doing it.

OSDev.org

Legal Issues

Re: Legal Issues

Re: Legal Issues