3

We have different embedded boxes distributed around the world running TI Arago Linux and each box has a specific application (lets call it binary) running on it. Of this binary there are several compiled versions lying around in the server, as in the box there is always only one at /app/binary.

The issue is, that although we can manage to identify with a md5 hash which binary is installed in the box, we cannot determine which version is currently being executed.

14407 root      2880 S    /app/binary

Is there a common way to determine which version of a binary is currently running based on, for example, the md5 hash of the binary?

marc
  • 2,427

2 Answers2

4

On Linux, you can always find the content of an executable that's currently running by exploring its directory in /proc (as long as you have the appropriate permission). The file /proc/14407/exe is a “magical” symbolic link; you can always read its content, even if the link looks dangling (e.g. because the executable has been deleted). So you can identify the currently running binary with md5sum /proc/14407/exe, if the MD5 checksum lets you identify the version.

Gilles 'SO- stop being evil'
  • 829,060
0

There are probably lots of ways to tackle this. However if you have the PID of the running process, I would use lsof.

In your example, the for the PID 14407 owned by the root user you could do the following to show all the open files for that process:

lsof -p 14407

This will show all the files open. One of those files should be the binary itself. You can filter this output with grep if you know the path where your collection of binaries should reside to simplify the output of lsof.

Once you know which binary file is opened, when the process was started, you can MD5 that file and get your hash of the actual binary loaded when it was run.

However, if your binary was being rebuilt in tree and this original file was overwritten after being executed (i'm thinking of a long running process like a daemon) and the original binary could have changed as a result of a new build, then this method would not be reliable.

111---
  • 4,516
  • 3
  • 30
  • 52
  • Maybe the sentence "Of this binary there are several compiled versions lying around" is somehow confusing. The sentence means that the administartor stores several versions of the binary in the server, but in the box there is always only one at /app/binary. – marc Jan 24 '17 at 15:19
  • Ah, I assume that when a new version is executed it is moved into the proper place before being run? – 111--- Jan 24 '17 at 15:20
  • While not as reliable, the size of the file is listed in the output of lsof, so if these files reliably differ in size that might be a clue. – 111--- Jan 24 '17 at 15:21
  • That's the think. A new version may be overwritten, but the old version is still being executed as it is mapped in memory. – marc Jan 24 '17 at 15:21
  • Size could be the same, so it won't be a reliable way! – marc Jan 24 '17 at 15:22
  • 1
    Check out this answer then – 111--- Jan 24 '17 at 15:27