@yiming: It's actually pretty simple, although there is indeed a twist since the K5.
Let's start with the basics (and what the hack actually relies on):
There's *one* full size cover in the file. It's a simple metadata (exth) field with a pointer to one specific image resource in the mobi. This is what the Kindle shows when you 'Go To > Cover', this is what the hack uses, and this is what Calibre uses if you ask it to use the cover from this file.
Some files may *NOT* have one. Nothing we can do about it. (That's not to say that there won't be a full screen, or nearly full screen image near the beginning of the book, but, technically, it's not the cover. You also sometimes see this (ie. a second cover at the beginning of the book) even in books with a proper 'metadata' cover).
Looking for such 'extra' covers is clearly out of scope in this case (we'd have to unpack every image, identify all of them, and 'guess' which one looks like a good fit for the cover based on its size. That's a job for a human (ie. fix your metadata ^^)
Now, since the K5, there's also a twist with the Cover View. The mobi file also bundle a thumbnail, that's flagged in the metadata the exact same way as the cover. AFAIK, both Calibre and KindleGen will make sure that this thumbnail matches the metadata cover. Thing is, the Kindle will only use it for the Cover View in a very specific case:
When there's no ASIN set in the metadata (and, with JBPatch only, when the ASIN is 'invalid' [ie. is not an ASIN, but an UUID]).
When there's a (valid) ASIN set, the Kindle will do a simple HTTP request to Amazon to download it. This thumbnail (downloaded from Amazon) might not actually match the cover in the file (it usually uses the latest cover, if the publisher updated it).
Annnd, that should cover everything. Hope it helps
TL;DR: The hack *needs* the metadata to be correct. Trying to do guesswork when it isn't is too expensive resource-wise, and out of scope, IMHO