ROT13-Encoded Names (Mercury Obfuscation)

NVIDIA uses ROT13 as a lightweight obfuscation layer for a specific subset of internal identifiers in nvlink v13.0.88. The encoding is concentrated on Mercury-related content (SM100+ Blackwell codename MERCURY -> ZREPHEL), SASS instruction mnemonics held inside per-architecture opcode tables, configuration knob/option names, and a small set of ELF section-name suffixes used to annotate SASS-level metadata. The decoder function at sub_1A40AC0 is SIMD-vectorized, processing 16 bytes at a time via SSE _mm_load_si128 intrinsics, and is invoked at table-initialization time to convert an encoded string-pool entry into its plaintext form in a fresh heap allocation. This page catalogs every confirmed category of ROT13-encoded content with spot-verified decode tables keyed by string-pool address.

Correction notice (P050c-3 / P083). A prior version of this page claimed the 151 compiler pass names in the master phase table at 0x2443000--0x2445000 were ROT13-encoded, using BevYbbcHaebyyvat -> OriLoopUnrolling as an example. Direct verification against nvlink_strings.json shows that these pass names are stored as plaintext, not ROT13. The token BevYbbcHaebyyvat does not exist anywhere in the binary; only the plaintext OriLoopUnrolling is present, and it lives at 0x24434b0 -- inside the exact address range that had been labelled "ROT13 phase table". The pipeline order and pass list itself remain accurate, but the encoding-format claim was wrong and has been removed. See the Compiler Pass Names (Plaintext, Not ROT13) section below for the corrected treatment.

Purpose of ROT13 in the nvlink Binary

ROT13 is not a cryptographic cipher -- it is a self-inverse Caesar shift that any reader can undo by hand. Its role here is to prevent casual strings(1) dumps from trivially revealing Mercury internals: grepping a raw nvlink binary for MERCURY or WGMMA returns nothing, but grepping for ZREPHEL or JTZZN reveals the encoded form. The obfuscation is applied to exactly those identifiers NVIDIA wanted to keep out of trivial keyword searches -- most prominently Mercury (Blackwell) builtin templates, Mercury compiler-pass option names, SASS opcode mnemonics inside packed per-arch tables, and knob/option strings. Truly public-facing identifiers (R_CUDA relocation names, EIATTR constants, elfLink error messages, compiler pass diagnostic names in "After <PassName>" output) are stored as plaintext because they appear in linker error output, nvdisasm disassembly headers, or documented tool interfaces.

Overview

The total ROT13-encoded count is approximately 30,000+ entries, dominated by the 644 ZREPHEL_* templates, ~1,287 knob names, and the SASS opcode tables. Bulk counts for individual subsets are verified in the Confidence Assessment section at the end of this page; only the 644 ZREPHEL_* figure and the 22 Mercury passes are exhaustively counted -- other subsets are plausible estimates.

ROT13 Decoder Function

Address: sub_1A40AC0 (15,629 bytes, 449 decompiled lines)

The decoder implements a classic ROT13 substitution cipher with SIMD acceleration:

1. Scalar preamble -- processes unaligned head bytes one at a time: A-M maps to N-Z (+13), N-Z maps to A-M (-13), same for lowercase
2. SIMD loop -- loads 16 bytes via _mm_load_si128, applies vectorized ROT13 using packed byte comparisons and conditional adds/subtracts
3. Scalar epilogue -- handles remaining tail bytes after the last aligned 16-byte boundary

The input is copied to a fresh heap allocation (capacity rounded to next power of 2), decoded in-place, then returned. All SASS opcode mnemonic lookups flow through this function during table initialization.

SASS Opcode Mnemonics

Three per-architecture opcode table constructors populate ROT13-encoded instruction mnemonic tables. Each entry is a (name_ptr, name_length) pair starting at offset +4184 within the table object.

Core Arithmetic

FP16/BF16 (Tensor-path)

Uniform Register (SM75+)

Bitwise/Logic

Memory Operations

Control Flow

Warp Synchronization (SM90+ Mercury)

Matrix Multiply (Tensor Core)

SM100+ Blackwell Matrix Ops

SM100+ Unified Tensor Core (UTC)

Barrier/MBarrier

Texture/Surface/Sampling

Special/Miscellaneous

Data Conversion

TTU (Thread Tracing Unit / Graphics)

UDP (Unified Data Path / SM100+)

Mercury Passes (22 ROT13 Boolean Options)

All 22 Mercury-specific passes are registered in ctor_007 at addresses 0x425A40--0x426080. Each is a boolean enable/disable flag stored at a bit offset within the global options structure. The prefix ZREPHEL decodes to MERCURY -- the Blackwell (SM100+) codename.

Related global switches (also ROT13-encoded):

Mercury Builtin Instructions (644 Templates)

The 644 ZREPHEL_* strings are SASS instruction templates for SM100+ (Blackwell) hardware intrinsic operations. Each template encodes a specific operand pattern (source register types, destination types, synchronization modes). Organized by operation family:

Compiler Pass Names (Plaintext, Not ROT13)

The master phase table at 0x2443000--0x2445000 contains 151 plaintext pass name strings defining the full compilation pipeline order, cross-referenced from an adjacent pointer table starting around 0x2443ff0. These are the same names emitted in "After <PassName>" diagnostic output. They are stored as plaintext, without any ROT13 encoding -- a prior version of this page incorrectly listed them as ROT13.

Evidence of plaintext storage (spot-checks from nvlink_strings.json, all type=0 = ASCII string pool entry):

The string-pool region for these pass names spans 0x24433f7 (OriSanitize, first entry) to 0x2443dc1 (DebuggerBreak, last entry). The previous wiki version listed BevYbbcHaebyyvat as the ROT13 form of OriLoopUnrolling; direct grep against nvlink_strings.json returns zero matches for that encoded token -- it does not exist anywhere in the binary. Only the plaintext OriLoopUnrolling (decoder-output form) is present, and it sits at 0x24434b0 -- inside the exact address range the old "ROT13 phase table" claim named. The root cause of the original error was noticing the address range and assuming the uniform CamelCase naming scheme implied ROT13, without verifying that the stored bytes were actually encoded.

Why plaintext and not ROT13? These names are emitted verbatim into "After <PassName>" diagnostic messages and --verbose/timing output. Obfuscating them would require either a decode step on every diagnostic print (wasteful) or a dedicated plaintext mirror table (redundant). Mercury-specific options (the 22 ctor_007-registered booleans with the Zrephel... prefix) are ROT13-encoded because their names are only consulted at option-parsing time, but the master phase-table names are consulted on every timing dump and diagnostic emission.

The 151 plaintext pass names in pipeline order (grouped by phase) are catalogued in ptxas/peephole.md (for the Ori* family) and ptxas/overview.md (for the full master phase table). Only the encoding classification is corrected here; the pipeline order, pass count, and pass-name list themselves remain accurate in those pages.

ROT13-Encoded ELF Section Name Annotations

Four ELF section-name suffix annotations are stored ROT13-encoded in the binary as isolated string-pool entries. These annotate SASS-level metadata for memory ordering and data format constraints. All four are verbatim confirmed in nvlink_strings.json:

Mercury debug section name prefix (.nv.merc -> .ai.zrep)

A related but partially runtime-assembled family of 22 Mercury debug section names uses the ROT13 prefix .ai.zrep (= .nv.merc) plus a DWARF section suffix. Only one representative fragment -- .ai.erfreirqFzrz.bssfrg at 0x1f245d7 (= .nv.reservedSmem.offset) -- exists as an isolated string-pool entry. The 22 individual debug section names (.nv.merc.debug_info, .nv.merc.debug_line, etc.) are not present as standalone strings in the string pool; they are built at runtime via concatenation of the ROT13 prefix with a DWARF suffix and ROT13-decoded on demand.

The mapping for reference (prefix is stored and decoded at runtime):

Confidence for this runtime-assembled family is LOW -- the ROT13 mapping is mechanically correct (trivially inverse-checkable), but the individual encoded forms are not verifiable via string-pool dumps alone and require decompiler confirmation of the concatenation site.

Selected Knob/Option Names

Over 1,287 ROT13-encoded configuration knob names control the compiler's behavior. Listed here organized by subsystem with selected highlights:

Register Allocation Knobs

Scheduling Knobs

Code Sinking Knobs

Loop Optimization Knobs

Texture/Speculation Knobs

AdvancedSB (Scoreboard) Knobs

Disable Flags (64 identified)

Selected flags that disable specific optimizations:

Cross-References

• Mercury Overview -- Mercury architecture and the ZREPHEL codename
• Mercury Compiler Passes -- detailed analysis of the 22 Mercury passes
• Scheduling -- tepid scheduler and scoreboard management
• Register Allocation -- RegAlloc knobs and spilling
• Peephole -- Ori* pass family and optimization passes
• SM100 Blackwell -- SM100+ architecture features
• Pipeline Overview -- master phase table and compilation pipeline

Confidence Assessment

ROT13 is a self-inverse substitution cipher (A<->N, B<->O, ..., M<->Z). Mapping correctness for any given (encoded, decoded) pair is mechanically checkable, so HIGH confidence requires both: (1) the encoded form found verbatim in nvlink_strings.json, and (2) the listed plaintext being the correct ROT13 inverse. This page was revised under P083 to remove an incorrect claim that the 151 compiler pass names at 0x2443000--0x2445000 were ROT13-encoded; they are stored as plaintext.

Spot-check verification (14 entries from nvlink_strings.json):

All 14 ROT13 spot-checks verified at HIGH confidence. The former BevYbbcHaebyyvat / OriLoopUnrolling entry has been removed from the spot-check table; the token does not exist in the binary (see the Compiler Pass Names section for the plaintext treatment at 0x24434b0).

Plaintext verification (strings previously claimed to be ROT13):

Every spot-checked pass name inside 0x24433f7--0x2443dc1 is present in nvlink_strings.json as plaintext, and none of the previously-claimed ROT13 forms exist anywhere in the binary. The encoding-format claim for this region is definitively refuted.

Bulk verification:

Revision history

• P050c-3 -- added initial Confidence Assessment; detected and flagged that compiler pass names at 0x2443000--0x2445000 are plaintext, not ROT13.
• P083 -- full page rewrite to remove the incorrect "ROT13 compiler phase table" section and replace it with an explicit plaintext catalogue with spot-verified addresses. Purpose section added. Overview table restructured to distinguish ROT13 from plaintext categories. Mercury debug section names relabelled as "runtime-assembled from ROT13 prefix + suffix" to reflect that the 22 individual forms are not present as isolated strings.