When applications are code-signed, what parts of the .app bundle does the signature cover? In Mountain Lion, I know that some applications, including all applications on the Mac App Store are digitally signed by the developer, so that if they are modified, the signature will not match, and it will raise all sorts of errors (and the situation will escalate with the next release of the operating system...).

My question is what parts of the .app bundle does the signature cover? If anything in Appname.app/Contents changes (including metadata, like the modified date for the Contents folder), does that break the signature? Is it just the binary in Contents/MacOS? Are the .plists included in the signature? The Resources? As an end user, what can I hack (if anything) without breaking the signature?
TL;DR It's up to the developer to pick which pieces of the app are signed and whether or not tampering with those pieces results in any actions when the app is launched. You have to use trial and error to figure it out on an app-by-app basis.

It is largely up to the developer to decide which components in their application bundle are represented in the seal that gets signed before they deliver their application. Anything in the seal is effectively tamper-proof as it's mostly impossible to modify these things without changing their hash signatures. But that's doesn't actually mean you can't tamper with them.

The Apple Developer guide has this to say about what you should sign:


  You should sign every executable in your product, including
  applications, tools, hidden helper tools, utilities and so forth.
  Signing an application bundle covers its resources, but not its
  subcomponents such as tools and sub-bundles. Each of these must be
  signed independently.
  
  If your application consists of a big UI part with one or more little
  helper tools that try to present a single face to the user, you can
  make them indistinguishable to code signing by giving them all the
  exact same code signing identifier. (You can do that by making sure
  that they all have the same CFBundleIdentifier value in their
  Info.plist, or by using the -i option in the codesign command, to
  assign the same identifier.) In that case, all your program components
  have access to the same keychain items and validate as the same
  program. Do this only if the programs involved are truly meant to form
  a single entity, with no distinctions made.
  
  A universal binary (bundle or tool) automatically has individual
  signatures applied to each architecture component. These are
  independent, and usually only the native architecture on the end
  user's system is verified.
  
  In the case of installer packages (.pkg and .mpkg bundles), everything
  is implicitly signed: The CPIO archive containing the payload, the
  CPIO archive containing install scripts, and the bill of materials
  (BOM) each have a hash recorded in the XAR header, and that header in
  turn is signed. Therefore, if you modify an install script (for
  example) after the package has been signed, the signature will be
  invalid.
  
  You may also want to sign your plug-ins and libraries. Although this
  is not currently required, it will be in the future, and there is no
  disadvantage to having signatures on these components.
  
  Depending on the situation, codesign may add to your Mach-O executable
  file, add extended attributes to it, or create new files in your
  bundle's Contents directory. None of your other files is modified.


Also from here it's not necessarily true that having an invalid signature for an application means it will fail to launch. The page says:


  It is up to the system or program that is launching or loading signed
  code to decide  whether to verify the signature and, if it does, to
  determine how to evaluate the results of that verification.


An application may choose to allow modifications.

Your best bet is a trial-and-error approach with any application you're trying to modify. It may work, it may not. There's no always-true answer that can be given.

If an app has been signed you can look for a Contents/CodeResources file or a  Contents/_CodeSignature/CodeResources file in the bundle. This file lists all the signed components and their expected hash values in the bundle. It's a good place to start understanding what pieces of the application a developer deems critical enough to watch for changes.