← Back to context

Comment by jchw

7 years ago

Interesting, but I’d really like it if they actually pointed out some examples. There may in fact be stolen source code or at least it is possible some stolen source code was referenced in ReactOS - there’s virtually no way to prove that it didn’t happen - but one human’s observation could be very flawed and represent a view extrapolated from a small subset of stolen code. How much of the code could they have possibly read?

It’s also worth noting that large portions of ReactOS come from Wine and I’m sure those portions have plenty of internal NT structures too.

The bits about NT not being documented are bordering silly, though. The lack of documentation has certainly never stopped anyone. Stardock for example does some very interesting and very undocumented things, as do many (most?) DRM and obfuscation engines.

Personally, I think that if ReactOS has really stolen substantial amounts of code, then it genuinely didn’t pay off and probably was not that useful.

20 comments

jchw

Reply
thom_nic  7 years ago

I was curious, and since the author of this answer provided links to what they called leaks [1], it's not difficult to download both the leak and ReactOS source [2] and look for similarities. So, out of curiosity, that's what I did.

I started poking at some source files at random in ntoskernel, and it only took a minute to get some "hits" from the ReactOS source:

    $ rg InitializeContextThread
    ./ntoskrnl/ke/thrdobj.c:872:        KiInitializeContextThread(Thread,
    ./ntoskrnl/ke/powerpc/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/i386/thrdini.c:92:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/amd64/thrdini.c:36:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/ke/arm/thrdini.c:53:KiInitializeContextThread(IN PKTHREAD Thread,
    ./ntoskrnl/include/internal/ke.h:464:KiInitializeContextThread(

    $ rg NpxFrame
    ./ntoskrnl/ke/i386/v86vdm.c:473:    PFX_SAVE_AREA NpxFrame;
    ./ntoskrnl/ke/i386/v86vdm.c:480:    NpxFrame = &StackFrame->NpxArea;
    ./ntoskrnl/ke/i386/v86vdm.c:481:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
    ./ntoskrnl/ke/i386/v86vdm.c:485:    RtlCopyMemory(KiGetThreadNpxArea(Thread), NpxFrame, sizeof(FX_SAVE_AREA));
    ./ntoskrnl/ke/i386/v86vdm.c:510:    PFX_SAVE_AREA NpxFrame = &StackFrame->NpxArea;
    ./ntoskrnl/ke/i386/v86vdm.c:512:    ASSERT((ULONG_PTR)NpxFrame % 16 == 0);
    ./ntoskrnl/ke/i386/v86vdm.c:551:    RtlCopyMemory(NpxFrame, V86Frame->ThreadStack, sizeof(FX_SAVE_AREA));

Now that said, I have no idea what I'm looking for, or if this is significant. But since we have the source for both, it seems we can do better than speculate w/r/t how much code is similar between them. I know that does not prove copying but I think the author's point can't be blindly dismissed.

[1] https://github.com/Zer0Mem0ry/ntoskrnl

[2] https://sourceforge.net/projects/reactos/files/ReactOS/

  • jchw  7 years ago

    I do not wish to view the leaked copies of Windows source code, unfortunately. It does have potential legal ramifications, in the United States. If someone who doesn't care can attempt to audit it, that would be absolutely great.

    That said, KiInitializeContextThread isn't 'secret' enough to not appear, it is a well-known bit of internals. Here you can find some docs about it on Microsoft's own website, albeit I have no idea if this is present anywhere on there anymore.

    https://web.archive.org/web/20151214014944/http://www.micros...

    • fiblye  7 years ago

      If Microsoft cared, they wouldn’t be hosting that on their very own servers.

      GitHub belongs to Microsoft. They could pull that down at any time just because they feel like it. But they haven’t. That’s a pretty solid sign that there’s not any legal consequence to viewing it.

      2 replies →

  • codedokode  7 years ago

    I tried googling for KiInitializeContextThread and there are lot of search results for this name. For example, a presentation in Chinese dated 2005 year described process creating and mentions this function: [1]

    The sequence of events that happens inside KeInitThread() can be obtained from reverse engineering. If you compare the code of this function in WRK [2] and in Reactos [3] code, you'll see that while they do similar things, the code is not the same.

    Regarding NpxFrame, I don't know why this name is used in KiExitV86Mode, but if you compare functions KiInitializeContextThread in WRK and in Reactos, you'll see that in WRK the variable is named NpxFrame [4], and in Reactos a similar variable is named FxSaveArea (which matches structure FX_SAVE_AREA). The variable named NpxFrame in Reactos is used in other function, KiExitV86Mode.

    [1] https://slideplayer.com/slide/6561298/

    [2] https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/thredo...

    [3] https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/t...

    [4] https://github.com/Zer0Mem0ry/ntoskrnl/blob/a1eded2d8efb0716...

    [5] https://github.com/reactos/reactos/blob/893a3c9d030fd8b078cb...

  • tastroder  7 years ago

    I'm confused about those examples. Both symbols seem to be referenced in quite a few web resources that aren't dumps of that research kernel and either github search is a bit broken or I can't seem to find many of those in your [1] repository.

hermitdev  7 years ago

I have a book on my shelf somewhere about NT internal APIs; I forget the title or publisher as ive not looked at in nearly 20 years (thought it was interesting at the time, in practice I've hardly done more than glance at it). It's not officially sanctioned, and IIRC, there were notices that these were not considered public APIs and could change at any time without warning. It was from the Win2000 era, so who knows how relevant it is anymore.

Regarding the reverse engineering, ReactOS may be in a legal grey area. If they're disassembling, there might be some legal issues, bit I dont know, I'm not a lawyer and dont follow Reactor development closely (just checking progress from time to time when mentioned here or other places).

  • jchw  7 years ago

    ReactOS only officially allows clean-room reverse engineering. Sadly I don't know the best canonical documentation for this, so here's a blog post from 2006.

    https://www.reactos.org/reset-reboot-restart-legal-issues-an...

    • hermitdev  7 years ago

      Sadly that link is currently erroring out for me with a database error.

      There is also a difference between stated policy and what actually ends up happening (not that I'm making any accusations, because I'm not). But what happens publicly isn't necessarily representative of what happens privately.

      I mean, I can't contribute to it, because I have seen some source or disassembled components of Windows over the years. But excepting my public declaration of that here and now, who is to know?

      1 reply →

jacobush  7 years ago

Well said. I don't know if ReactOS has stolen code in it, but the Quora has some very shallow accusations. Besides, there are many ways of reverse engineering. Didn't Compaq famously have one team writing documentation for another team implementing? With the doc team scavenging info wherever they could.