The signature is of a hash of the portion of the executable before the code signing block. Best practice is to have both the installer and the application signed.
You can study some details by looking at this:
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463180.aspx
EDIT: OK, now that I'm off the mobile device and on a real keyboard, I can elaborate.
As noted in the document to which I referred you, the hash that gets signed is generated as to the entire executable file except for two excluded portions (a) the total file checksum; and (b) the certificate tables. These cannot be incorporated into the hashing because of the chicken or egg problem (e.g., these fields are dependent on the content of the attribute certificate table, and thus their values are not fixed until the certificates/signatures are prepared and appended).
As for the attack surface/scenarios, we see once again why it is so important to have good crypto primitives, and ALSO to use best practices. I suppose that in theory an attacker could create a malicious version of a software application, and then roll it into an installer and include some carefully calculated data to generate a hash collision with an existing real MD5 certificate from the application vendor, attaching that existing certificate/signature to the compromised executable. If you only checked the installer you might get fooled. This is why MD5 cannot be trusted for this sort of application anymore. It is also why, in addition to checking the installer, you should check the application program itself.
Windows 7 accepted MD5 hashes for code signing, whereas Windows 8 and up requires SHA1 or better. (For what it's worth, I dug around my program files and old installers just now and only found one from 2008 or so that used MD5 for the signature hash. 2nd edit: I take that back, I also found a relatively recent version of Winzip using MD5).