In SSL/TLS, what is hashed is the handshake messages, i.e. the unencrypted contents. The hash input includes the 4-byte headers for each handshake message (one byte for the message type, three bytes for the message length); however, it does not contain the record headers, or anything related to the record processing (so no padding or MAC). The "ChangeCipherSpec" message (a single byte of value 1) is not a "handshake message" so it is not included in the hash input.
Each handshake message may be split over several records; similarly, a single record may contain several handshake messages. This splitting and merging has no impact on the hashing process.
This is actually specified in the RFC:
All of the data from all messages in this handshake (not
including any HelloRequest messages) up to, but not including,
this message. This is only data visible at the handshake layer
and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in
Section 7.4, exchanged thus far.
Mandatory note: it must be stated that designing a protocol such as SSL/TLS is very hard; a lot of some details can be wrong and jeopardize security. The actual TLS got it wrong in several points, and this triggered a lot of trouble (see this answer). Defining your own protocol, and making your own implementation, are OK for purposes of learning or simply having fun, but I urge you to reconsider any velleity at deploying such things for production use.