search

ddvk / remarkable2-framebuffer

remarkable2 framebuffer reversing
MIT License
279 stars 22 forks source link

LD_PRELOAD doesn't work with some binaries from toltec #37

Open Witos opened 3 years ago

Witos commented 3 years ago

reMarkable: /opt/lib/ LD_PRELOAD=/opt/lib/librm2fb_client.so.1.0.0 grep ERROR: ld.so: object '/opt/lib/librm2fb_client.so.1.0.0' from LD_PRELOAD cannot be preloaded (internal error): ignored. Usage: grep [OPTION]... PATTERNS [FILE]... Try 'grep --help' for more information.

reMarkable: /opt/lib/ filewhich grep /opt/bin/grep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /opt/lib/ld-linux.so.3, for GNU/Linux 3.2.0, stripped

LD_PRELOAD works fine with the busybox grep: reMarkable: /opt/lib/ LD_PRELOAD=/opt/lib/librm2fb_client.so.1.0.0 busybox grep BusyBox v1.30.1 (2020-11-04 10:42:32 UTC) multi-call binary. Usage: grep [-HhnlLoqvsriwFE] [-m N] [-A/B/C N] PATTERN/-e PATTERN.../-f FILE [FILE]...

reMarkable: /opt/lib/ file /bin/busybox.nosuid /bin/busybox.nosuid: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=e9c75f6d853dde1bbf974fdf11daa3493f4eadde, stripped

I suspect it's a matter of the interpreter. If it's ld-linux-armhf.so.3, it works fine, if it's /opt/lib/ld-linux.so.3 it shows error.

raisjn commented 3 years ago

wow, thanks for the investigation!

the good news is that /opt/lib/ld-linux.so.3 is an artifact of Entware (i believe). Any packages relying on that interpreter will not be remarkable specific (or even trying to draw to framebuffer), so while this is a noisy error, it isn't affecting actual behavior (usually)

Eeems commented 3 years ago

I'm guessing there is no way to work around this? It's an annoying warning.

raisjn commented 3 years ago

one workaround proposed by @linuscde is to clear LD_PRELOAD path before calling out to binaries from entware that are linked against /opt/lib. this will help suppress some warnings but not all of them.

there is also the question of whether re-linking toltec binaries against the same location (/opt/lib/) will fix things. the main issue is that xochitl is still pointing to /lib. if we can have one client.so for xochitl (and /lib) and one client.so for toltec (and /opt/lib), i think this would resolve things.

Eeems commented 3 years ago

one workaround proposed by @LinusCDE is to clear LD_PRELOAD path before calling out to binaries from entware that are linked against /opt/lib. this will help suppress some warnings but not all of them.

This is a per-application solution though, and not something that rm2fb handles itself.

there is also the question of whether re-linking toltec binaries against the same location (/opt/lib/) will fix things. the main issue is that xochitl is still pointing to /lib. if we can have one client.so for xochitl (and /lib) and one client.so for toltec (and /opt/lib), i think this would resolve things.

That's probably the best idea.