SyscallTables for Windows Build Research and Table Composition

Build-Specific Windows Syscall Reference Data

SyscallTables addresses a narrow Windows reverse-engineering problem: syscall identifiers and service-table layouts can change between Windows releases, so a mapping from one build cannot safely be assumed valid for another. The repository organizes syscall information by architecture, Windows generation, build number, and kernel module. It includes x86-64 `ntoskrnl` and `win32k` tables, x86-64 IUM data for selected builds, and ARM64 `ntoskrnl` and `win32k` tables for Windows 11 23H2 and 24H2.

The documented x86-64 coverage begins with Windows 2003 SP2 build 3790, also identified as Windows XP 64. It continues through Vista, Windows 7, Windows 8, several Windows 10 releases, Windows Server 2022, and multiple listed Windows 11 releases. Builds 19042, 19043, 19044, and 19045 are explicitly marked as identical to Windows 10 20H1 build 19041. That equivalence is useful when selecting a lookup, but it should not be generalized to other builds without evidence in the repository.

The intended users are security researchers, kernel reverse engineers, and developers of low-level Windows tooling. These users may need a readable cross-build index for static analysis, documentation, or tooling. Ordinary application developers usually have little reason to depend on this repository because it does not expose an application programming interface. It also does not present itself as a wrapper that invokes Windows syscalls at runtime. Its documented value is organized reference data plus a process for composing new tables from dumped lists.

The repository is most useful when build identity is part of the research problem. A Windows image number gives the tables a stable selection key, but it does not prove that a running computer has the same image. The README does not document runtime build detection or validation against a live system. That work belongs in the surrounding analysis process.

X86-64, ARM64, and Module Coverage

Coverage differs substantially by architecture and component. For x86-64, the README lists `ntoskrnl` service tables for Windows XP x64 and releases from Vista through multiple Windows 11 targets. It also lists `win32k` service tables, beginning with Vista and Windows 7 and continuing through Windows 10, Windows Server 2022, and listed Windows 11 builds. A smaller IUM section covers Windows 10 20H1 build 19041, Windows 11 DEV build 25276, and Windows 11 25H2 build 27823.

ARM64 coverage is narrower. The README lists `ntoskrnl` and `win32k` tables for Windows 11 23H2 build 22631 and Windows 11 24H2 build 26100. That makes architecture selection a concrete first check. A researcher cannot use the x86-64 table as an ARM64 substitute, even when the Windows names match.

The x86-64 data is organized under paths such as `data\Composition\X86_64\NT6\ntos`, `data\Composition\X86_64\NT10\ntos`, and `data\Composition\X86_64\W11\ntos`. Corresponding `win32k` directories use the same generation structure. ARM64 files appear under `data\Composition\ARM64\ntos` and `data\Composition\ARM64\win32k`. IUM data is placed below the x86-64 NT10 and W11 trees.

Recent-looking entries carry an explicit qualification. Several Windows 11 rows have a July 2026 annotation directing readers to issues 3, 5, and 6 for more information. The main README does not explain the contents or status of those issues. This matters for anyone treating a listed build as a finalized mapping. The repository entry establishes inclusion, but it does not replace checking the linked project discussion for that build.

Dump Utilities and Composer Data Flow

The documented workflow has three stages. First, a C utility scans a supplied Windows image and writes a syscall list. The README associates `scg` with `ntoskrnl` and `wscg64` with `win32k`. Its run examples, however, invoke `scg64.exe`, including one for a `win32u` DLL. That naming difference should be resolved against the files under `src` and the binaries produced by the build rather than inferred.

Second, the generated text must be stored under its build number. The target directory must contain an `ntos` subdirectory for `ntoskrnl.exe` tables and a `win32k` subdirectory for `win32k.sys` tables. This naming rule is the join key used to associate a dumped list with the repository's build-oriented organization.

Third, `sstc.exe`, the C# composer, reads those lists and combines them. By default it reads the `Tables` directory. A different root can be selected with `-d`, but the directory still needs the expected `ntos` and/or `win32k` children. The `-w` option requests a combined `win32k` table. Without `-h`, the composer produces markdown table output; with `-h`, it produces HTML.

This architecture separates extraction from presentation. The C code handles image-oriented input, while the composer handles aggregation and output formatting. That separation is practical for adding new build files, but it also means a successful dump is not enough. Incorrect placement or naming can exclude a file from the intended table, and the README does not define a validation command that checks every expected build directory before composition.

Building SyscallTables on Windows

SyscallTables does not document a package-manager installation or a complete one-command build. The README directs developers to the repository and identifies Microsoft Visual Studio as the build environment. Obtain the repository from its GitHub source page, inspect `src`, and use the solutions or project files that are present there. The README does not name those files, so inventing a solution path or restore command would be misleading.

The composer source is written in C#. According to the README, it requires Microsoft Visual Studio 2022 or higher and NET 10 or higher. Visual Studio 2026 is recommended. The `scg` and `wscg` source code is written in C. Its documented requirement is Visual Studio 2022 with SDK 19041 or higher, with the 2026 SDK or latest SDK recommended.

The dump utilities also depend on Zydis, described by the README as an x86 and x86-64 disassembler and code-generation library. The top-level repository contains `.github`, `LICENSE.md`, `README.md`, `data`, and `src`. The README does not document a separate vendored Zydis directory, a package reference, or a dependency acquisition command. Dependency setup therefore needs to be taken from the project configuration in `src`.

This build path is most suitable for engineers already using Windows-native development tools. The documentation does not provide Linux, macOS, or cross-compilation instructions. It also does not define where built executables should be installed. After building, keep `scg64.exe`, any applicable `wscg64` binary, and `sstc.exe` distinct from the data directory because the composer consumes text files rather than the composed HTML tables.

First SyscallTables Generation Workflow

The README's first example generates a syscall list from an `ntdll` DLL associated with build 7600 and redirects the output into `table7600.txt`.

scg64.exe c:\wfiles\ntdll\ntdll_7600.dll > table7600.txt

The reader should see a text file named for the target build. The workflow requires that filename to reflect the build rather than the arbitrary redirect name. Place the file in the appropriate `ntos` directory described by the README.

A second example processes a `win32u` file and writes `win32u_11.txt`. Because the usage text associates `wscg64` with `win32k`, inspect `src` and the compiled utility names before treating this example as the canonical command for that module.

scg64.exe c:\wfiles\win32u\win32u_11.dll > win32u_11.txt

After adding build-numbered files under `Tables`, run `sstc -w` to request a combined `win32k` table. Without `-h`, the expected format is markdown.

sstc -w

Add `-h` when HTML is required.

sstc -h

A custom input root can be selected with `-d`.

sstc -h -d OnlyW10

The two options can also be combined for HTML output from the `win32k` path.

sstc -h -w

The README does not specify a fixed generated filename or describe rollback after a failed run. Inspect the selected output directory and compare the generated rows with the build-named input files.

Coverage Gaps and Direct Extraction Alternative

SyscallTables is the wrong tool when the required build, architecture, or module is absent. ARM64 coverage consists of only the two Windows 11 releases named in the README, and IUM support is limited to three builds. Researchers must verify their exact target rather than selecting a nearby release and assuming its table applies.

It is also unsuitable as a runtime resolver. The documented tools read files and generate tables; they do not query a live Windows process, detect its active build, or return a callable syscall address. Any live-system identification and validation must occur elsewhere.

The Windows-specific toolchain is another boundary. The documented build process depends on Visual Studio and a Windows SDK, and the examples use Windows paths and executable files. The README does not provide Linux or macOS instructions. A project that only supports cross-platform development may find that dependency too restrictive.

Direct image extraction is the practical alternative for a single target. Start with the supplied image, run the appropriate dump utility, inspect the resulting list, and keep that result beside the analysis. This approach avoids maintaining or consulting a broad historical dataset and does not require composing unrelated releases. SyscallTables offers a different approach by preserving reusable build files and combining multiple inputs into HTML or markdown. Choose direct extraction for isolated build work. Choose SyscallTables when cross-build lookup, comparison, or repeated presentation is part of the assignment.

Neither route removes the need to establish provenance. The README does not explain how every listed image was validated or how a user should resolve conflicting entries. For less established Windows builds, review the repository files and the issue links before relying on a generated row.

Maintenance, Release Scope, and License Review

The repository is not archived. Its last push was on 2026-09-04, and the release list includes v1.0.0 dated 2025-07-12. The README contains July 2026 annotations and lists several Windows builds associated with that period. These facts show that repository content and covered Windows targets can change, but they do not establish a fixed update schedule or a formal support window.

Upgrade cost depends on the use case. A reader who only consults HTML tables may notice added or corrected builds with little integration work. A tool that copies repository data into its own database may need to review build additions, changed annotations, directory layout, or composer behavior. The README does not provide a migration guide, schema version, or compatibility policy for existing consumers.

The repository identifies its license as `BSD-2-Clause`. Anyone embedding tables, modifying source, or redistributing generated output should inspect `LICENSE.md` for the actual copyright and license notice. The existence of a permissive license does not remove the obligation to preserve required notices. This is a source-level review, not legal advice.

The next concrete check for an adopter is simple: locate the exact architecture and build under `data\Composition`, confirm the appropriate `ntos` or `win32k` table, and build the C utilities or C# composer only if fresh input composition is required. SyscallTables is suitable as a build-indexed reference for projects that need repeated Windows syscall comparison, provided its listed coverage is accepted as the adoption boundary.

Editorial conclusion

Adopt SyscallTables when build-specific Windows syscall mappings are central to cross-build research, especially when comparing x86-64 or ARM64 releases. Do not treat it as a runtime syscall API or a substitute for artifacts from the exact target build. Verify first that the required architecture, build, module, and service table are present, then inspect `LICENSE.md` before redistributing composed or modified tables.

Frequently asked questions

Official sources

1. hfiref0x/SyscallTables on GitHub
2. Issues
3. License: BSD-2-Clause
4. README
5. Releases