Comment by 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.
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...
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.
Well, my paranoid 99% says that they could keep it online on purpose so that all people viewing it fall in a legal disadvantage position. Removing that code would achieve nothing in secrecy today compared to the legal leverage they can get tomorrow by keeping it online.
For what it's worth, it's not just Microsoft who care. You're not allowed[1] to contribute to Wine if you've ever seen the leaked Windows source code. I think it's weird that they consider your mind to be "tainted" forever, but whatever. I guess they want to be cautious.
(You're also not allowed to contribute to the Wine CRT if you've ever seen the CRT source that's legally distributed with the Windows SDK.)
[1]: https://wiki.winehq.org/Developer_FAQ#Who_can.27t_contribute...
Just going to throw this out there, if Microsoft cared that anyone viewed it, wouldn't they have taken it down by now?
I don't think Microsoft cares that much, but I'm sure they view it for what it is: illegal, unauthorized usage of their intellectual property. (I'll hold off on my personal views of 'intellectual property' and whatnot; I'm not a lawyer, and those opinions are hardly relevant to the reality here.)
Still, even if Microsoft doesn't care, Wine Project and ReactOS care. My employer might care. There are unfortunately legal implications that exist, and if people want to play by the books they have to at least do the basic due diligence.
If you genuinely just don't care, you can lie to them and claim you never saw the original code, and attempt to cloak any code theft to make it indistinguishable from clean-room reverse engineering. Nothing stops you from doing that. Hell, the trouble is that it really can't be proven for sure. Even holding the positions I do on forums wouldn't prove my own innocence in such a situation, though maybe it helps build a case.
4 replies →
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...
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.