32-bit - Do you use it?

[Cath O'Deray]

I'm trying to figure out how file(1) might be used to identify files that use lib32.

This:

% file /usr/local/ICAClient/npica.so
/usr/local/ICAClient/npica.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
%

– from <https://www.freshports.org/net/citrix_ica#requiredrun> I assume that it uses Linuxulator, but does it (also) use lib32?

 

[_martin]

grahamperrin see ELF.

I'd argue that Intel 64 is ambiguous term. As SirDice said IA64 is totally different to IA32 (different architecture). I personally prefer name x86_64 or amd64.
It's with sadness I look at my IA64 assembler book (Itanium architecture for programming). My first crack ever was on IA64. >: )

 

[kpedersen]

I'm trying to figure out how file(1) might be used to identify files that use lib32.

I believe file might be the wrong tool. Instead prhaps something like lld would show you the path and then you can grep ones that are in a 32-bit lib path.

My first crack ever was on IA64. >: )

Heh, nice. What was the program you cracked?

The only non-x86 crack I have bodged together was on SPARC with the classic Motif GUI builder BX Pro (https://motif.ics.com/products/bx-pro). Exciting stuff

I didn't have Radare2 back then. That would possibly have made it less time consuming haha.

 

[_martin]

Heh, nice. What was the program you cracked?

xpls - it was a Swiss knife for managing HP XP and P9500 arrays. It had a check for license expiration. I didn't use radare2 or IDA (no Ghidra back then) but good old gdb on HPUX and trial-error approach. Fun and exciting, as you said. And yeah, those tools do help a lot with static analysis.

Nice, I do have one Sparc - Sun Fire V120 on Solaris 10 but never did any pwning on it.

 

[Cath O'Deray]

see ELF.

Thanks, is 32-bit (in the example above) a reliable indicator?

I mean, does the command below come close to listing files (not necessarily executables) in /usr/local that require lib32?

sh

find /usr/local -type f -exec bash -c '[[ $(file -b "'{}'") == *" 32-bit "* ]] ' \; -print

It's (naturally) long-running, matches include:

• /usr/local/lib32/gcc10/libitm.so.1.0.0
• /usr/local/llvm13/lib/clang/13.0.1/lib/freebsd/libclang_rt.asan-i386.so

---

A parallel sh run of the command below quickly finds things such as /usr/local/bin/mulberry:

bfs /usr/local -type f -exec bash -c '[[ $(file -b "'{}'") == *" 32-bit "* ]] ' \; -print

 

[_martin]

That's _the indicator. Even kernel relies on it (flip that one byte and execution fails). Many tools rely on that: file(1) does read from that header, brandelf(1) command plays there, so does elfctl(1).
To see what's the elf object about you can use readelf(1) and objdump(1) (among others).

You can get into weird territory with x86_64 very fast because 64b object can execute 32b code and in theory load 32b library (and vice versa). But putting hacks aside readelf/objdump is really a good way to determine the type of the ELF object.

 

[Cath O'Deray]

That's _the indicator. …

Thanks.

---

Side note

… (naturally) long-running, …

The very long run of the command (I did not exclude jails) might help to make OpenZFS issue 12779 reproducible – <https://github.com/openzfs/zfs/issues/12779#issuecomment-1062613967> – I assume that E would normally indicate EiB (exbibytes), not error …

 

[bookwormep]

This thread has evolved, so much so that, to change my original vote. I am now using FreeBSD on amd64 hardware. No lib32 in use either.