Mateusz Jurczyk, a Google Project Zero security researcher, writes about Windows internals, kernel vulnerabilities, and exploitation, and publishes syscall tables.
HN commenters cite it for its Windows syscall tables and detailed write-ups of the ATMFD vulnerability and exploit, calling them excellent, though the PDFs are hard going.
"Generating Software Tests" (https://www.fuzzingbook.org/) is pretty great (independent of your programming language) - arguably a must read for anyone interested in software testing.
John Regehr (the author of the blog post) has written more great posts:
- How to Fuzz an ADT Implementation - https://blog.regehr.org/archives/896
- Better Random Testing by Leaving Features Out - https://blog.regehr.org/archives/591
- Tricking a Whitebox Testcase Generator - https://blog.regehr.org/archives/672
- Fuzzers Need Taming - https://blog.regehr.org/archives/925
- Levels of Fuzzing - https://blog.regehr.org/archives/1039
- API Fuzzing vs. File Fuzzing: A Cautionary Tale - https://blog.regehr.org/archives/1269
- Reducers are Fuzzers - https://blog.regehr.org/archives/1284
In terms of software, DeepState (https://github.com/trailofbits/deepstate) may be a good place to start for C and C++. Relevant links:
- Fuzzing an API with DeepState: https://blog.trailofbits.com/2019/01/22/fuzzing-an-api-with-deepstate-part-1/, https://blog.trailofbits.com/2019/01/23/fuzzing-an-api-with-deepstate-part-2/
- NDSS 18 paper, "DeepState: Symbolic Unit Testing for C and C++": https://www.cefns.nau.edu/~adg326/bar18.pdf
In terms of choosing among fuzzing solutions,
https://blog.trailofbits.com/2018/10/05/how-to-spot-good-fuzzing-research/ is also worth a read -- as well as the article it refers to, http://www.pl-enthusiast.net/2018/08/23/evaluating-empirical-evaluations-for-fuzz-testing/. For a…
> relatively little investment compared to migrating to an OS on another kernel
One of the more beautiful aspects of Windows is you actually rarely interact with the kernel at all. That portion of the OS could (and in practice often is) switched out and replaced without the user-facing portions being aware.
If you look at the list of NT system calls [0] you can see how frequently they've changed. The only programs that can safely talk to the kernel are core OS components, which in turn provide a user-facing stable ABI through the use of DLLs.
The fact Wine is running on a separate kernel is essentially 100% transparent to all but a handful of programs that intentionally poke the kernel, either for undocumented functionality or to e.g. detect tampering.
This is why IMO for running application software, Wine will always be superior. Linux is a really good kernel for almost everything, and with io_uring the last big deficit (async i/o) may be fixed.
ReactOS's remaining advantages are driver support for Win2k, and the whole explorer shell and start menu environment. If someone really wanted to, I bet you could run ReactOS's shell on top of Wine, fullscreened on Linux...
[0] https://j00ru.vexillium.org/syscalls/nt/32/
EDIT:
A thought I had after finishing this. Another benefit of ReactOS's architecture vs Wine is you could, in principle, directly copy at least some system-level DLLs/software from Windows (2000/XP) and get something akin to Windows 2003/XP running on a…
A value in the range between -4095 and -1 indicates an error, it is -errno.
The syscall/errno stuff has always seemed unusual, inelegant, and inefficient --- instead of just returning a negative error code directly, the function returns the vague "an error has occurred" -1, and you have to then check errno separately after that. It only adds insult to injury when you realise that the kernel itself isn't doing it, but the syscall wrappers. And thanks to POSIX standardising this mechanism, the alternative will likely never get much adoption; of course, if you write your own syscall wrappers like this article, then you can skip that bloat.
For now this guide is linux-only, but I will be writing a windows version when I feel like firing up a virtual machine.
Unfortunately the Windows syscalls are not officially documented and even less stable than on Linux, changing even between service packs.
http://j00ru.vexillium.org/ntapi/
http://j00ru.vexillium.org/ntapi_64/
At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years:
https://filippo.io/linux-syscall-table/
Linux is exceptional in that it has stable syscall numbers and guarantees stability. This is largely why statically linked binaries (and containers) "just work" on Linux, meanwhile Windows and Mac OS inevitably break things with an OS update.
Microsoft frequently tweaks syscall numbers, and they make it clear that developers must access functions through e.g. NTDLL. Mac OS at least has public source files used to generate syscall.h, but they do break things, and there was a recent incident where Go programs all broke after a major OS update. Now Go uses libSystem (and dynamic linking)[2].
[1] https://j00ru.vexillium.org/syscalls/nt/64/
[2] https://go.dev/doc/go1.11#runtime
libav was the fork [1], and libav is dead now [2,3] (and many developers returned to ffmpeg).
libav was forced to rename their project because Fabrice Bellard, still owner of the trademark and the ffmpeg.org domain, did not hand it over. ffmpeg put in much effort retain compatibility with libav, mostly by merging all their changes wholesale, while libav ignored ffmpeg, including and most crucially, their security fixes [4].
[1] http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
[2] https://www.libav.org/
[3] https://www.phoronix.com/news/FFmpeg-Back-In-Debian
[4] https://j00ru.vexillium.org/2014/01/ffmpeg-and-the-tale-of-a-thousand-fixes/
> Windows gets this right and is able to iterate faster on kernel interfaces as a result.
The only place that'd have any bearing is for modified syscalls. Newly added obviously aren't an issue, And looking at syscalls removed, it's because they removed whole subsystems that never had anyone using it. Those would probably not even get upstreamed into the mainline kernel to being with.
I'm not seeing any evidence of what you're saying while looking at how the NT syscall layer has changed over the past couple decades.
https://j00ru.vexillium.org/syscalls/nt/64/