I'll answer this based on my experience with the CBMC compiler. I never used HitmanPro, malwarebytes anti-exploit or Microsoft's EMET but I do not see any reason why they would do things completely differently from CBMC.
Known exploit protection
If we look at the malwarebytes anti-exploit video (kindly researched by OP), we see that MBAE could find an exploit by identifying a downloaded malicious file. That is exactly how a modern anti-virus program works: it checks the signature of a known malware (or "exploit payload" if you want to call it that way) and stops its execution if it matches.
In that specific case we can argue that Anti-Exploit is simply a re-branded name for an Anti-Virus program. In theory you can argue that AV (Anti-Virus) only checks signature of files, whilst AE (Anti-Exploit) checks the payload (e.g. whiled downloading a file) You can also argue that AEs searches for CVEs whilst AVs search for malware signatures. But all modern AVs perform all that: they are updated when CVEs come out, they check signatures of network traffic (downloaded files) and they do that in real-time. So I'll argue that, from that video, we can conclude that AEs are simply AVs rebranded.
Yet, there is more: AEs promise to be able to find zero-day exploits. And that would be different from AVs.
You can't find a zero-day exploit in a program without running the program. But running a dodgy program is unwise. This is because, if there is an exploitable point in the runtime environment, running a program may exploit exactly that breach. Sandboxing is an option, but sandboxes often have breaches of their won. So, how can we execute a program without executing it? Symbolic execution to the rescue.
As I said at the beginning of the answer I'll use CBMC, a tool I needed at some point in the past. It performs symbolic execution, but it is a research tool. And no one really argues that symbolic execution can find all possible problems a program may have.
CBMC is a C compiler (and has a commercial version for VHDL too) that does not compile a program into machine code. Instead it compiles the program into a language called GOTO, which is a simplified symbolic representation of the program. Then a GOTO processor (part of CBMC) is used to run the symbolic representation of the program.
A symbolic representation is much easier to reason about, and the program can be run assuming a wide range of inputs. For example, one of the things that CBMC/GOTO catches well in C programs are buffer overflows.
Now, CBMC works on C and VHDL programs, but the same can be done with assembly. Although it would not be as accurate as constructing a symbolic representation from the source code (since disassembly is not perfect), it would allow to execute the symbolic representation of the program and check for coding mistakes.
Buffer overflows are the easiest things that one can think that can be found in the assembly as well, but other possibilities may include unchecked input (input is tracked in a symbolic representation, at least in CBMC) or opening network sockets (since it is a known syscall).
Disclaimer: I do not know how an AE is actually built, but if I had to build something that can find a zero-day exploit automatically symbolic execution would be the path I'd try. Symbolic execution does not come without issues (known to the open research community, some non-disclosed sources may have found solutions to some of them):
- SE does not find all problems, e.g. interaction between different configurations is often not found.
- SE is rather slow.
- Intel or ARM (or any other) disassebmly is never perfect, and disassembly problems reflect into SE results.