What is the magic number for a Berkeley DB v9 Btree with a native byte order? Is there any specific length on magic numbers or any easy way to identify them?
Asked
Active
Viewed 1,209 times
3
-
1What makes you think there *is* a "magic number"? Do you know the binary format of the data-files well enough to know that there is such a number, but don't know the actual number? If you know the binary files that well, then you should know where the number is, and therefore could find it out yourself. And can't you just download the source code and look? It *is* dual-licensed with one license being an open-source license, or don't you want to make an Oracle account? How about looking at an older, pre-Oracle, versions? – Some programmer dude Aug 17 '15 at 06:35
-
1I know it has one because of the *nix file command. That's how it identifies files and as far as the reason for wanting it I need it to do a file carve on a disk with a seriously messed up filesystem. – Scoopta Aug 17 '15 at 06:40
-
There appears to be an entry in the source code for the Linux `file` command for Berkeley DB Btree magic numbers. From Ubuntu/Debian `apt-get source file` to get the `file` source code then look in `./file-5.14/magic/Magdir/database`. I don't care quite enough to decode the format of this text input file to `file` but maybe you do. – Paul Aug 17 '15 at 06:45
-
@Paul apt tells me it can't find a source package for it :/ to Google – Scoopta Aug 17 '15 at 06:52
-
@Scoopta I tried running against a bare ubuntu 15.04 and found I needed to `apt-get update; apt-get dpkg-dev` first and then `apt-get source file`. Note that `dpkg-dev` will install `patch`, `gcc`, etc... – Paul Aug 17 '15 at 06:56
-
@Paul Alright I'm on mint so if I did the same thing I'll probably be good. – Scoopta Aug 17 '15 at 06:57
-
@Paul so unless I'm interpreting this wrong the Berkeley DB magic number is 0x00053162. But the DB I'm using for reference doesn't contain that and yet the `file` command still accurately reports it as a Berkeley DB. Am I missing something? – Scoopta Aug 17 '15 at 07:15
-
If you don't want to look through the Berkeley DB source, why not use the source for the `file` command, or it's magic-number database? And it doesn't have to be a *single* magic number `file` looks for, it can look for multiple values at different locations. – Some programmer dude Aug 17 '15 at 07:57
-
@JoachimPileborg yes I know that. I'm looking at the `file` source right now trying to decipher it. Although I'm still slightly confused haha. – Scoopta Aug 17 '15 at 07:59
1 Answers
2
As you've found it's 0x00053162
. I'm assuming by native byte order, you mean x86 native byte order? If you hexdump the file, you'll see it in bytes 12-15, byteswapped (as 3162 0005, because it's x86):
hexdump blah.db | head -1
0000000 0001 0000 9fbc 0009 0000 0000 3162 0005
0000010 0009 0000 1000 0000 0900 0001 0000 0000
The version is in the next uint32_t
, bytes 16-19. Here, it's 0009 0000
, which is version 9 in little endian-speak. In fact, that whole sequence of bytes starting at offset 12 looks to be a struct __db_bt_stat
, the content of which is given in the manpage for db_stat
(or Db::stat
) available here: http://www.mit.edu/afs.new/athena/astaff/source/src-9.0/third/db/docs/api_cxx/Db/stat.html

Mike Andrews
- 3,045
- 18
- 28
-
Thank you so much. I didn't realize x86 was byteswapped. That makes so much sense now. – Scoopta Aug 17 '15 at 23:04