A diferença nas somas de verificação binárias que você descreveu provavelmente se deve ao pré-teste. Distribuições Linux baseadas no RHEL, como o CentOS e o Fedora, têm o prelinking ativado por padrão. Veja como um artigo do LWN.net de 2009 explica o conceito por trás do prelink:
Linux programs typically consist of a binary executable file that refers to multiple shared libraries. These libraries are loaded into memory once and shared by multiple executables. In order to make that happen, the dynamic linker (i.e. ld.so) needs to change the binary in memory such that any addresses of library objects point to the right place in memory. For applications with many shared libraries—GUI programs for example—that process can take some time.
The idea behind pre-linking is fairly simple: reduce the amount of time the dynamic linker needs to spend doing these address relocations by doing it in advance and storing the results. The prelink program processes ELF binaries and shared libraries in much the same way that ld.so would, and then adds special ELF sections to the files describing the relocations. When ld.so loads a pre-linked binary or library, it checks these sections and, if the libraries are loaded at the expected location and the library hasn't changed, it can do its job much more quickly.
No entanto, se as bibliotecas forem sempre carregadas no mesmo local de memória, os invasores podem tentar direcionar esses locais com código mal-intencionado, razão pela qual a distribuição de prelink do Redhat distro é feita regularmente com a opção -R ). Uma conseqüência de alterar os locais da memória é que a soma de verificação dos arquivos executáveis binários será alterada. Portanto, se você estiver usando um verificador de integridade de arquivos como o AIDE, será alertado sobre um binário "alterado" quando, na verdade, a única alteração ocorrida é o ASLR via prelink -R .
Referências: link