Announcement

Collapse
No announcement yet.

Glibc 2.36 Dropping DT_HASH Has Been Breaking Easy Anti Cheat Games With Steam Play

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by splitcells.net View Post
    Events according to my understanding:
    1. Under certain build configs, glibc would accept DT_HASH and DT_GNU_HASH.
    2. The new version only accepts DT_GNU_HASH under the build configs of 1.
    3. Some projects, still had binaries with DT_HASH only.
    4. glibc was updated (on fast updating distributions like Arch) and therefore, the binaries of 3. could not be processed by glibc anymore.

    1: https://github.com/bminor/glibc/blob...DJUST_DYN_INFO
    2: for example: do_lookup_x: https://sourceware.org/git/?p=glibc....0;hb=HEAD#l350
    From my understanding EAC was directly reading DT_HASH, and so a glibc update that removed it from glibc broke EAC.

    Comment


    • #62
      Originally posted by Jaxad0127 View Post

      From my understanding EAC was directly reading DT_HASH, and so a glibc update that removed it from glibc broke EAC.
      Yeah, that's right.
      The glibc functions may even support the old hash tables.
      This is more important for other software implementing libc or parts of it (like binutils which adjusted its functionality a time ago).

      So the more correct way to put it, would be:
      1. Under certain build configs, glibc would accept/provide DT_HASH and DT_GNU_HASH.
      2. The new version only provides DT_GNU_HASH under the build configs of 1.
      3. Some projects, relying on libc and not glibc, still had binaries, that required other binaries having DT_HASH still being present.
      These affected projects relied on the binaries being provided by the OS/environment.
      4. glibc was updated and the software directly depending on it was rebuilt with the config of 1.
      The rebuild removed DT_HASH of the binaries, so that software like EAC could not access it any more.

      Comment


      • #63
        Originally posted by carewolf View Post
        It is not glibc API, but it is ELF API, which glibc has exported, but forgot to think of as their API.
        no, it's not an elf api either(hint: api is bound at compile time). it's implementation details and you shouldn't depend on implementation details

        Comment


        • #64
          Originally posted by pal666 View Post
          no, it's not an elf api either(hint: api is bound at compile time). it's implementation details and you shouldn't depend on implementation details
          It's an ELF ABI instead of an API and an interface provided by glibc,
          which is controlled by command line options.

          Even the developers see it as an ABI change: https://sourceware.org/git/?p=glibc....becb58f569ed24 1e8e95c568f03c

          The comment indicates that --hash-style=both was used to maintain
          compatibility with static dlopen, but we had many internal ABI
          changes since then, so this compatiblity does not add value anymore.‚Äč
          PS: After the accident, the ABI doc was made up to date.
          The DT_GNU_HASH, was added 2 days ago to the documentation: https://sourceware.org/git/?p=gnu-ga...a1566b53bb7e58
          Last edited by splitcells.net; 27 August 2022, 02:34 PM.

          Comment


          • #65
            Originally posted by splitcells.net View Post
            It's an ELF ABI
            it's not an abi either, because it's not an application interface
            Originally posted by splitcells.net View Post
            Even the developers see it as an ABI change
            they don't, you are misinterpreting your quote
            abi change would be if for example DT_GNU_HASH will change its value from 0x6ffffef5 to something else.
            complaints about glibc not using DT_HASH are akin to complaints what some program isn't using printf and someone's hook is failing now. nobody promised you that, so you can't depend on it being true in future
            Last edited by pal666; 28 August 2022, 02:40 AM.

            Comment


            • #66
              Originally posted by pal666 View Post
              it's not an abi either, because it's not an application interface
              they don't, you are misinterpreting your quote
              abi change would be if for example DT_GNU_HASH will change its value from 0x6ffffef5 to something else.
              complaints about glibc not using DT_HASH are akin to complaints what some program isn't using printf and someone's hook is failing now. nobody promised you that, so you can't depend on it being true in future
              So changing the value of DT_GNU_HASH changes the ABI,
              while deleting DT_GNU_HASH does not change the ABI?

              Comment

              Working...
              X