Quote from: pooya87 on Today at 07:25:23 AM

I am not the most familiar with wallet.dat but it looks like the 0x43000130 should be considered a variable even if it appears similar for everyone.

I mean, yeah, I get the direction you're thinking in. (Because I started by thinking in that same direction.)

The thing is, the DB-wise item value (my search pattern) and the item key (your search pattern) are not in the order you'd expect (they're reversed, as in, if you find the key-pattern then you have to jump backwards to find its corresponding value-pattern). It's a very subtle point, but by basing the search on the item value (which is what I chose to do), I'm avoiding having to dig deeper into Berkeley DB's source code to confirm on my own that there's an order-wise relationship between keys and values that will always be true).

I wrote my pattern in a peculiar way (4300 0130) because the pattern should always start on a 4-byte boundary (that is, typical-hex-view-wise, it will both always start on a 2-byte column, and never start on an odd column that might split the pattern across two lines). Also, if you're examining the wallet using something like Sublime Text's binary view, then the search pattern you enter (after Ctrl+F) is actually a text pattern (as in, if you change the spacing and search for 43 00 01 30, or 43000130, then you'll get no matches).

The 4-byte pattern that I settled on obviously isn't enough on its own to confirm a match: it's important to examine all of the uncolored parts in my previous post, and to check that they're the same, too (I skipped describing those parts, but I understand in detail what each of them do). With a fully-matched pattern, it's reliable enough for the purpose, I think. (That is, the whole procedure is basically saying: "On a 4-byte boundary, find the byte values 67, 0, 1, and 48, then make sure that there's a byte with the value 8 at a specific point after that, then make sure that there are four zero bytes at a specific point after that, and finally, make sure that the whole thing ends with a zero byte".)