The installer is an even messier piece of code.

    #!/bin/bash
 
    TOP_INSTALL_DIR=/
 
    echo "Stopping FFRelay"
 
    monit stop ffrelay
    sleep 3
    killall -9 -q ffrelay
    echo "Extracting Software Files..."
    tar --directory $TOP_INSTALL_DIR  -xvf ./*relay*.tar
 
    echo ""
    echo "Running Post-Installation Steps..."
 
    SECONDS=1
    MAX_SECONDS=10
 
    while [ "$SECONDS" -lt "$MAX_SECONDS" ]
      do
           if [ -e "/var/run/ffrelay.pid" ]; then
               sleep 1
           else
               SECONDS=$MAX_SECONDS
           fi
      done
 
 
    echo "Starting FFRelay"
 
    monit start ffrelay
 
    echo ""
    echo "FFRelay Installer done."
    echo ""

They should have just used a .deb

Collisions aren't a major risk with MD5 when you also give someone the file size (even approximate).

Finding a collision in MD5 is costly, finding a collision in MD5 which is within -+10% of the actual size is extremely costly (technically possible, but maybe not in your lifetime).

As to the other reply "because it is zip something something" I disagree. Zip is an extremely good format for crafting fake files which match a checksum. Really any format which can take arbitrary metadata (which is MOST) is pretty easy.

I suspect the reason they use MD5 is because everywhere supports it and it is "good enough," particularly with file size. Plus the person downloading them knows the files are malware, so what could the security services do, inject an even more malware-malware that they then expect the user to run?! Seems dumb. You're likely more at risk from day to day applications installers which aren't digitally signed.

They should definitely not being using MD5 for anything. Even if the people in this thread saying that finding MD5 collisions is hard were correct, and they aren't, why take the risk? The performance benefits aren't large for MD5 over competing hash functions that don't have know systemic weaknesses and MD5 attacks will only get better.

Use SHA256, SHA-3 or MD6 (I like MD6, others may disagree. Disclaimer I worked on proving the differential resistance of MD6).

Collision resistance is more interesting when hashes are used in cryptographic protocols and large amounts of data can be captured, seen and analyzed.

I can't think of a purpose where a collision of a non-malicious sample with a malicious file can be used by an attacker (let alone the same attacker). In addition, there are lots of historical threat data (tactical intelligence) that is based on md5sums. Newer tools support newer checksums, but will more than likely just increase the types of checksums supported, and not deprecate them.

Checksums are less and less useful when the malware can be configured, recompiled and re-assembled for a particular target. There are some good discussions on HN more fuzzy detection techniques that can't be evaded by changing inert parts of the payload, but that is orthogonal to using stronger checksums. Indicator of Compromise data including md5sums can be useful for general security, but because a determined attacker will mutate the files it is better suited to more commodity malware.

Because it would be very hard to find a collision of a file that behaves exactly like a ZipFile.

To make a collision work, you would need to inject the payload into the program, and find a specific blob to put into the zip file, that once compressed and hashed would cause a collision. This isn't computationally efficient.

Now that it's publicly released, it seems like a good idea to install it just to make sure your own systems aren't vulnerable to it.