The Portable Freeware Collection Forums

Just submitted to DB
http://www.portablefreeware.com/index.php?id=2713

100% Stealth portable AFAICT.

Thanks but maybe you should send pockethash.exe to VirusTotal first to resolve the warning issue

Also, we do not have a member/user by the name hexatomium... please fix the "Suggested by" field.

Thanks for checking!

What kind of warning do you get?
According to VirusTotal, it's clean, so I'm a little confused:
https://www.virustotal.com/en/file/c18a ... /analysis/

I have fixed the "suggested by" field and put my own username, as the author is a friend of mine.

Avast blocks the download.
Avast is prone to false positives on portable versions of standard software. Normally OK on standard freeware
Suggest you resolve this somehow

JohnW wrote:Avast blocks the download.
Avast is prone to false positives on portable versions of standard software. Normally OK on standard freeware
Suggest you resolve this somehow

What is the detection name, or the reason given?
I will submit a false positive report to Avast.
FPs are more and more of a PITA for small indie devs.
Code signing sometimes helps, but is costly.

Avast describes the infection as DRep

flatfly wrote:Thanks for checking!

What kind of warning do you get?

Avast Web Shield blocks it; DRep (DomainRep).

See https://forum.avast.com/index.php?topic ... msg1164286


Tested PocketHash v1.03: Portable

Please consider removing the link that "opens the homepage of PocketHash."

I am Baas wrote:Please consider removing the link that "opens the homepage of PocketHash."

The next version will look something like this (and will support SHA-256 as well). Does that look better to you?

flatfly wrote:Does that look better to you?

Looks good. Can I also make a few suggestions?

First, referencing my favorite simple hasher for a long time Hash:

• Copy button for the entire output
• Log file style output window

... I don't know that it makes sense to duplicate that exactly, but a copy button next to each of the hashes and then a copy all button at the bottom of all of them might be worthwhile.

Second, if you're okay with some configuration (ability to change settings):

• The ability to swap out for a given set of hashes
• Support for CRC32 and all the SHAs

I say this because haven't seen any clear standard show up for whether 256 is enough for 512 or SHA3 or what. At the same time, I've never seen never seen MD4, Whirlpool, or any of the hundreds of other algorithms so I think you can safely leave all the others out.

I can mockup something if that sounds interesting.

PocketHash at version 1.17, screens:

PocketHash version 1.17 - without hex preview (animated image):



PocketHash version 1.17 - with hex preview (animated image):



To use PocketHash safely I blocked VirusTotal using hosts file:

PocketHash version 1.17 - without hex preview - virustotal blocked (animated image):



PocketHash version 1.17 - with hex preview - virustotal blocked (animated image):



I would like to thank the developer for adding several enhancements I suggested.

Since we're debating this, the ability to write a specific hash directly to file in a standard fashion is my foremost requirement.

All the copy buttons are fine and dandy for irregular use, but wouldn't it be more convenient if you dropped a file (or a set) on Pockethash and get a '[same_filename].md5' straight away containing the corresponding hash ready for later verification, for example?

Regarding webfork's doubts on the best choice of hashing standards, let me refer back to Wikipedia's article on "Hash function security summary", based on which I advocate that crc32, md5 and SHA-1 must be retained for historical reasons, but that SHA256 is now the absolute baseline for anyone concerned with this.

Also note that more obscure standards can be freely added to the mix but most of them are currently considered severely impaired from a security point of view.

Lastly, I agree with smaragdus that VirusTotal checking should be made optional: no one wants to be submitting a log of all their hashing operations to a Google subsidiary on a permanent basis.

Midas wrote: ↑Sat Jun 23, 2018 4:57 am Regarding webfork's doubts on the best choice of hashing standards, let me refer back to Wikipedia's article on "Hash function security summary", based on which I advocate that crc32, md5 and SHA-1 must be retained for historical reasons, but that SHA256 is now the absolute baseline for anyone concerned with this.

Hash function security matters only if you're concerned about the possibility that someone has intentionally replaced the file with something malicious but retained the hash (which, AFAIK, is only a theoretical possibility, and no one has actually carried out such an attack in the wild). If you're only checking if the file has corrupted during the download, MD5 or even CRC32 is fine.

Sidenote: I like the icon the user selected.

Midas wrote: ↑Sat Jun 23, 2018 4:57 amI agree with smaragdus that VirusTotal checking should be made optional: no one wants to be submitting a log of all their hashing operations to a Google subsidiary on a permanent basis.

Agreed. As useful as VirusTotal checks are, it's ideal to make them available but disabled by default. An increasing number of connection points are used by Google, so just submitting them outside adds to a user profile.

SYSTEM wrote: ↑Sat Jun 23, 2018 6:04 amIf you're only checking if the file has corrupted during the download, MD5 or even CRC32 is fine.

Agreed. Corruption checks are fairly easy for computers and even ancient algorithms (like CRC32) are more than adequate. It's that files can be crafted by computers to appear legitimate is the major threat and really only SHA-256 is (currently) considered safe.

Midas wrote: ↑Since we're debating this, the ability to write a specific hash directly to file in a standard fashion is my foremost requirement.

I solved my own problem with md5deep: check the script at viewtopic.php?t=24253...