Latest Widevine 4.10.2252.0 fails to load

[wagnerch]

It appears Google may have changed the latest Widevine libraries, the size has changed by about 1M, and it is not linking all of the same libraries as it used to (perhaps some stuff is statically linked now). In any case these are the errors, but there isn't enough logging to know the issue. Also the dlerror() message is squashed and never bubbles up.

2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: Unable to load widevine shared library (/storage/.kodi/cdm/libwidevinecdm.so)
2021-05-09 20:29:53.661 T:4807 ERROR : AddOnLog: inputstream.adaptive: OpenDRMSystem failed

Related issues:
CastagnaIT/plugin.video.netflix#1154

Working CDM:

13505.111.0/libwidevinecdm.so:
linux-vdso.so.1 (0xbefbd000)
/usr/lib/libarmmem-v7l.so (0xb6808000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb67df000)
libm.so.6 => /usr/lib/libm.so.6 (0xb6776000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb6763000)
librt.so.1 => /usr/lib/librt.so.1 (0xb674c000)
libnss3.so => /usr/lib/libnss3.so (0xb664f000)
libnssutil3.so => /usr/lib/libnssutil3.so (0xb661c000)
libnspr4.so => /usr/lib/libnspr4.so (0xb65e5000)
libc.so.6 => /usr/lib/libc.so.6 (0xb64a6000)
/usr/lib/ld-linux-armhf.so.3 (0xb6f66000)
libplc4.so => /usr/lib/libplc4.so (0xb6f8f000)
libplds4.so => /usr/lib/libplds4.so (0xb6f8b000)

Non-working CDM:

13816.64.0/libwidevinecdm.so:
linux-vdso.so.1 (0xbedb9000)
/usr/lib/libarmmem-v7l.so (0xb5dd7000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb5dc4000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb5d9b000)
librt.so.1 => /usr/lib/librt.so.1 (0xb5d84000)
libm.so.6 => /usr/lib/libm.so.6 (0xb5d1b000)
libc.so.6 => /usr/lib/libc.so.6 (0xb5bdc000)
/usr/lib/ld-linux-armhf.so.3 (0xb6f78000)

[wagnerch]

ARM, LibreELEC

[dagwieers]

This affects all ARM-based Linux systems (not Android systems). And what is worse, it appears Google will be revoking older Widevine CDM versions as of 2021-05-31, so we have 3 weeks to get a fix out, or all Widevine-encoded content will stop working. https://www.widevine.com/news

[wagnerch]

This appears to be the dlerror:
cannot allocate memory in static TLS block

At least with testing a simple C program to just do a dlopen:

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv)
{
    void *dl = dlopen("libwidevinecdm.so", RTLD_LAZY);
    if (!dl) {
        char *msg = dlerror();
        fprintf(stderr, "ERROR: %s\n", msg);
    }
}

[matthuisman]

Do we have access to 4.10.2252.0 for other platforms?
I know 4.10.2209.0 works fine on Windows and Linux x86_64 for example.

See Linux and Chrome OS list different versions...
So maybe 4.10.2252.0 is just for Chrome OS and is now more closely linked - that is where IA helper extracts it from after all.

https://dl.google.com/widevine-cdm/versions.txt also lists 4.10.2209.0/1 as latest

If thats the case, it would mean we need to find a new source for a Linux ARM build of Widevine blob.
Raspberry Pi has a version, so be interested to see if that gets updated...
Did anyone manage to get more info from them where they were getting it from?

[wagnerch]

I think libwidevinecdm0 comes from Ventz. It's not fully clear whether it is an official Google agreement. My guess is they may be pulling it from the same sources.

https://blog.vpetkov.net/2020/03/30/raspberry-pi-netflix-one-line-easy-install-along-with-hulu-amazon-prime-disney-plus-hbo-spotify-pandora-and-many-others/

[matthuisman]

i dont think they would take it from there to be honest. They are quite big org and seem to do things "by the book".
Ventz was probably pulling it from Chrome OS as well - that seems to be the only actual source.

Just tried using my Widevine pull script, and still no Linux ARM builds - only Darwin ARM64 and the others.

I wonder if those Chrome blobs are using newer version of one of the linked libs or something like that?

[wagnerch]

I know it's not a special build for Raspberry Pi, it has the same sha1 as the one pulled from ChromeOS. But that may not really indicate much of anything.

[matthuisman]

just had a thought over herE:
#679 (comment)

We are sure the blobs aren't AARCH64 now?
Is the HW they pulling from 32 or 64 bit?
Maybe latest Chrome OS has switched fully to 64 bit.
We did just get a ARM64 build for Darwin / MAC... so wouldn't be huge surprise Chrome OS followed

[wagnerch]

They are not, it's still armhf. You can tell because it has a dependency on the armhf dynamic linker:
/usr/lib/ld-linux-armhf.so.3 (0xb6fb3000)

If you compile with:
arm-linux-gnueabihf-gcc-8 -Wall -o wvdl wvdl.c -ldl -Wl,--no-as-needed ~/libtcmalloc.so.4.5.3

The last 2 arguments are forcing a link to libtcmalloc.so.4 even though it is not needed by the C program, and run with LD_DEBUG=all you see it gets past linking and calls init in libwidevinecdm and results in a segmentation fault. My guess is Chromium is linking libtcmalloc.so.4, so the symbols are already loaded and TLS is already allocated, and malloc() has been replaced at this point before they dlopen(libwidevinecdm.so). Don't know though. I noticed there are 4 new global symbols:
0080efc0 g D google_malloc 00000000 Base .protected __start_google_malloc
0080e688 g D malloc_hook 00000000 Base .protected __start_malloc_hook
00812c70 g D google_malloc 00000000 Base .protected __stop_google_malloc
0080efbc g D malloc_hook 00000000 Base .protected __stop_malloc_hook

These are related gperftools (which includes tcmalloc). Not really an expert on all of this dynamic linker & ELF binary stuff. But could't really go much further than that.

LD_DEBUG=all LD_LIBRARY_PATH=/storage:/storage/.kodi/userdata/addon_data/script.module.inputstreamhelper/backup/13816.64.0/ ./wvdl

      3705:     calling init: /usr/lib/librt.so.1
      3705:
      3705:
      3705:     calling init: /storage/.kodi/userdata/addon_data/script.module.inputstreamhelper/backup/13816.64.0/libwidevinecdm.so
      3705:
Segmentation fault

[matthuisman]

thanks for confirming :)

[wagnerch]

BTW, this is what 1679 looks like through the same program (through the point where the segfault happens):

      3715:
      3715:     calling init: /usr/lib/librt.so.1
      3715:
      3715:
      3715:     calling init: /storage/.kodi/userdata/addon_data/script.module.i
nputstreamhelper/backup/13505.111.0/libwidevinecdm.so
      3715:
      3715:     opening file=/storage/.kodi/userdata/addon_data/script.module.in
putstreamhelper/backup/13505.111.0/libwidevinecdm.so [0]; direct_opencount=1
      3715:
      3715:
      3715:     calling fini: /storage/.kodi/userdata/addon_data/script.module.i
nputstreamhelper/backup/13505.111.0/libwidevinecdm.so [0]
      3715:
      3715:
      3715:     calling fini: /usr/lib/libnss3.so [0]

[matthuisman]

anyone got a copy of the new blob that they can upload and send me?
Nevermind - i've just downloaded the chrome os :)

[matthuisman]

so, opening that new blob in text editor, there is all the below text in it near the top that older versions dont have
are we sure this blob is good??
has anyone got a chrome book to try?
Has google messed up?

Error text from top of blob (just opening with notepad):
https://pastebin.com/raw/KDHfY8QL