You're probably on the right track looking at raw pages instead of waiting for Berkeley DB to stop sulking and behave properly. Once wallet.dat gets even slightly scrambled, the logical structure starts lying to you, while the page-level artifacts are often still honest enough to work with. I've seen cases where the header damage looked dramatic, but the useful bits were still sitting in leaf or overflow pages just fine, and the real problem was the parser trusting broken metadata a little too much. If you go down the custom Python route, I'd focus less on rebuilding the database in the formal sense and more on carving records cleanly and validating page boundaries. Berkeley DB loves to reward optimism with garbage.
The part that usually bites people is not the mkey blob itself, it's the temptation to assume one recovered structure means the surrounding fields are sane. They often aren't. If the nID or adjacent bookkeeping is rotten, you can end up with something that looks plausible enough to waste a whole weekend.
I'd work from multiple read-only copies, compare page distributions, and treat every recovered ckey or mkey candidate like hostile input until it survives consistency checks. Pywallet and friends tend to tap out because they still want the DB to be a database. At this stage it's closer to digital paleontology with a hex editor and a bad attitude.
