Dependency on old version of OpenSSL

[kaarposoft]

I have tried running memprocfs on Ubuntu 23.10 desktop.

However the command memprocfs -device forensics/memdumpX64.dmp fails with

[SYMBOL]   Functionality may be limited. Extended debug information disabled.
[SYMBOL]   Partial offline fallback symbols in use.
[SYMBOL]   For additional information use startup option: -loglevel symbol:4
[SYMBOL]   Reason: Could not load PDB required file - libpdbcrust.dll/so.

The reason seems to be, that libpdbcrust.so depends on an old version of OpenSSL:

ldd mem_release/libpdbcrust.so 
    linux-vdso.so.1 (0x00007ffcc2718000)
    libssl.so.1.1 => not found
    libcrypto.so.1.1 => not found
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fcfaf601000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcfaf5fc000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcfaf5f7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcfaf5f0000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcfaee00000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcfaf638000)

According to https://www.openssl.org/source/ All older versions (including 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used.

On Ubuntu 23.10 desktop a newer version is used:

find /usr/lib -name "libssl.so*"
/usr/lib/x86_64-linux-gnu/libssl.so.3

openssl version
OpenSSL 3.0.10 1 Aug 2023 (Library: OpenSSL 3.0.10 1 Aug 2023)

May I suggest to update the OpenSSL dependency to version 3.0.x

According to https://www.openssl.org/source/ the 3.0 series which is a Long Term Support (LTS) version and is supported until 7th September 2026

For the record: If I install OpenSSL libraries with apt-get install libssl-dev and then build the package with cargo build --release and copy the resulting libpdbcrust.so to the memprocfs directory, memprocfs works!

ldd pdbcrust/target/release/libpdbcrust.so 
    linux-vdso.so.1 (0x00007ffeb84bc000)
    libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fa2f8dac000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fa2f8800000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa2f8d88000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2f8400000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa2f8fc9000)

[ufrisk]

I feel I'm caught between a rock and a hard place here. If I compile this rust binary on Ubuntu 23.10 to satisfy the OpenSSL requirement it will at the same time stop working on older releases and people will complain about that.

And I can't really support pre-compiled binaries for each Linux version there is either.

I should probably add a note about it in the guide and let people which wish to use it compile it themselves.

With Ubuntu 24.04 I suspect I'd probably have to do two separate Linux releases anyway unfortunately.

[kaarposoft]

Yes, this is a rock as well as a hard place ))-:

I think the best move is to get memprocfs into the package managers.

But that needs maintainers for each distro.

I would not mind trying to become a maintainer for memprocfs in ubuntu (debian, really), but what about the others?

[ufrisk]

Having MemProcFS in Debian / Ubuntu would be very nice indeed. It's by far the most common distro with the largest user base :)

There are probably a few things I should fix / take care before thinking about pushing ahead though.

1) I've got lots of tiny changes in Version 5.8 currently, I should push this up to 5.9 first. This would be very easy.

2) Currently the symbols will be downloaded to the Symbols folder relative to vmm.so by default. If this folder is not writable it will fail. This path is already possible to override for the user, but I feel I would have to make a sane default for it before pushing ahead with a package. Either I could put the default path in a config file (relative to vmm.so) or I could just hard code it. Config file would probably be better?

3) info.db is a sqlite database which is frequently updated after each patch tuesday. It contains Yara rules (which aren't updated very often) and cached offsets to important Windows data structures. It's no super biggie if it gets old on an Internet connected PC since the downloaded Symbols would just be used instead. It will however have to be updated after next Windows release (24H2). I should make the path to info.db user-settable (currently it's loaded relative to vmm.so). Also potentially include some auto-update functionality but that would be a bit messy. It might be better to just making it user-settable and throw a warning if its older than 2 months or so would be fine probably.

Also, the whole thing is designed for all files to be kept more or less in the same directory. I know this goes a bit against the Linux philosophy with separate dirs for the libraries but it have also been very convenient for me to distribute in this way.