Comparing the exported symbols of liblzma.so-5.5.99 vs. liblzma.so-5.6.1 shows that the following new public API functions appeared in 5.6.1:

1. lzma_crc32
2. lzma_crc64
3. lzma_block_header_decode
4. lzma_check_is_supported
5. lzma_check_size
6. lzma_easy_buffer_encode
7. lzma_index_buffer_decode
8. lzma_index_hash_decode
9. lzma_lzip_decoder
10. lzma_lzma_preset
11. lzma_mf_is_supported
12. lzma_mode_is_supported

(All of these were absent from 5.5.99’s export list.)

All of these maps directly to documented additions in XZ Utils 5.6.0 (support for new checksums, “lzip” format, preset helper, buffer-based convenience functions, etc.). In other words, they are legitimate, intended public‐API functions and not spurious or leftover symbols.

I’ve decompiled and skimmed lzma_crc64. Here’s what it does under the hood:

• It calls a small “detect‐CPU‐features” helper (FUN_001046b0) to see whether the host supports the right vector instructions (bits 0x80202 in EDX/EAX).
• By default it returns a pointer to a plain C (table-driven) CRC-64 routine (FUN_00106dd0).
• If the CPU has the needed SIMD/bit-manipulation support, it instead returns a pointer to an accelerated CRC-64 routine (FUN_00106b40) that uses pshufb, pblendvb, shifts, and lookup tables embedded in the .rodata.

Neither path ever does anything other than compute a CRC-64 over your buffer. There are no hidden syscalls, network or file I/O, self-modifying code, or other side-effects. It’s purely benign “choose fastest CRC-64” glue.

Here’s roughly what FUN_001046b0 (the “do we have the right CPU features?” stub) is doing:

1. It calls FUN_001045d0(mask, scratch)
   – On its very first invocation (tracked by a static counter DAT_0013d010), FUN_001045d0 invokes FUN_00104644(&ctx), which in turn calls FUN_00125060() and walks the module’s .init array to build up its internal CPUID cache. After that first-time init it never does the full dance again—just returns cached results.
   – Then FUN_001045d0 calls FUN_001045b0(leaf,…), which is just a thin wrapper around the x86 CPUID instruction (it picks the right cpuid_* helper based on leaf number and returns EAX/EBX/ECX/EDX into your buffers).
   – FUN_001045d0 returns the raw EAX (the maximum supported leaf, or the leaf result).

2. Back in FUN_001046b0 you get that cpuid-EAX back; if it’s ≥ the leaf you asked for, it does one more CPUID to fill your registers (via the same FUN_001045b0) and returns 1. Otherwise it returns 0.

No syscalls, no file or network I/O, no decryption or self-modifying tricks. It’s literally “once-only init a CPUID cache” + “run the CPUID instruction” + “compare if your CPU has the leaf we need.” In short, entirely benign feature detection._

Yes—you’re right that FUN_00104644 does a little “GOT hot‐patch” trick. Here’s the simplified flow:

1. It’s only ever run once, at first CPUID probe, guarded by a static counter.
2. FUN_00125060() (called at the top) sets up two module‐local addresses:
   • DAT_0012f208 = the base of the GOT/PLT relocation table
   • DAT_0012f210 = the base address of this module in memory
3. It computes a pointer into the GOT:
   plVar3 = (long *)(DAT_0012f208 + (*param_1 – param_1[4]))
   That lands on the GOT slot for the “real” cpuid wrapper (FUN_001045b0).
4. If that slot isn’t zero, it:
   a. Saves the original GOT entry (the true cpuid entrypoint)
   b. Overwrites the GOT entry with (DAT_0012f210 + offset), i.e. the address of its own collector‐stub
   c. Calls the PLT trampoline (PTR_FUN_0013cfe0), which now jumps into the collector‐stub
   d. Restores the original GOT entry so future calls to cpuid again go to the “real” function

In other words, it temporarily hooks the cpuid helper so it can capture all the CPUID leaves on first use, then puts everything back exactly as it was. This is a completely legitimate “one-time shim” for feature detection—no persistence, no self-modifying business beyond that single restore, and no hidden backdoor.