Oracle database block checksum XOR algorithm explained

Recently I’ve started to write my own clone of BBED to have something handy and useful in extreme cases when you have to go deep and fix stuff on low level (I have only like 2 such cases a year but each time it is really fun and a nice money 😉 )

When I’ll finish the tool, it will be available on my GitHub. Maybe as an option for ODBV or a separate tool? I haven’t decided yet but I’ll cover it with a blog post for sure!

Meanwhile, I want to share with you my investigation on calculating a block checksum.
Quoting from a documentation:

A number calculated by the database from all the bytes stored in a data or redo block. If the DB_BLOCK_CHECKSUM initialization parameter is enabled, then the database calculates the checksum for every data file or online redo log block and stores it in the block header when writing to disk. The database can use the checksum value to check consistency.

This checksum in a database block is stored on 16th byte. Let’s check it with BBED:

As you can see the value is 0x40e0 so 13710. Please note that BBED shows the hex values format in a human-readable manner like in a Big Endian system. Since I’m doing this on Intel, the actual hex value in a datafile is written as "E040″.

BBED can calculate a checksum with command "sum" and apply it to a block with a command "sum apply". Let’s check what will happen if I’ll change the value in a database block at a low level without putting the appropriate checksum.

Now we can see that BBED is showing me the changes correctly, but when I’ll try to read a block from Oracle:

BBED will also show us that a checksum in a block is different than it shout be:

Now we know what the checksum should be and how to trigger BBED to count it – it’s debugging time!!!

Firstly I’ll attach to my BBED process with a GDB and I’ll set a watchpoint. In assembler, a result from a function has to be set on one of the registers. The CPU documentation will tell which register to observe. In most of the cases on Intel and AMD it will be RAX:

After executing a sum command in a BBED I’ll see a set of functions that returned with a specified value – of course, I’m interested only in the first one:

I’ve consulted Frits and he told me that this kcbhxoro launches sxorchk, which is doing the work. But sxorchk never fires when we count a checksum from BBED. Let’s check kcbhxoro:

As you can see, calling sxorchk is conditional and it can be skipped by highlighted instructions – and it happens in our case.

The first interesting thing is a little loop in here:

We are xoring the value from the memory address stored in the RDI registry with a value of RDX registry – the result is put in RDX.
Then we increment value on EAX registry – EAX is used here as a loop counter. Do you see the last line of the above output? This is a conditional jump. First, we are comparing values on ESI and EAX and if EAX is below the ESI – we are jumping back to offset 43 to the xor.

So ESI contains the value of the loop spins. The counter is calculated here:

From the documentation we know, that RSI is a register used to pass the second argument to functions. So we can see here, that the second argument is shifted by 5 bits to the right – shifting right by 5 bits is the equivalent of diving the argument by 2**5 – so 32.

Ok, so let’s make a breakpoint at the shr command and check the values of the registers:

Great! So we know that RDI contains the address in a memory where data begins (I know it because in assembler dump I see that RDI is used in brackets). The RSI, on the other hand, contains value 8192. If I will shift it right by 5 bits it would be equivalent to dividing it by 32 – so after this operation, I should have value 256 on the RSI.

Let’s check it.

Awesome! So it works. Now I’ll check what data is stored on the addres from the RDI. To do it, I’ll use "examine" command:

Since the result of an XOR is being put in an RDX registry, the portion of 8 bytes will be used as a chunk – RDX is a 64bit registry. Format "g" in examine command means: "g(giant, 8 bytes)". You can see this with "help x".

Let’s check right now the contents of this block:

Remember that GDB shows hex values in a human format (the same as big-endian) but on Intel, we have a small-endian format. So if you’ll reverse bytes, you will see that the values are actually the same.

Conclusion? RDI contains the address to memory with my database block! Awesome!
So the main loop looks like this:

• XOR 8 bytes from memory address, stored in RDI with RDX
• Increment counter on EAX
• XOR 8 bytes from memory address (+8B offset), stored in RDI with RDX
• XOR 8 bytes from memory address (+16B offset), stored in RDI with RDX
• XOR 8 bytes from memory address (+24B offset), stored in RDI with RDX
• add 32B to the value of RDI – so the pointer will shift 32B
• already did this 256 times? No? Jump to the begining

After that, we have some more fun:

Put value of RDX into RCX

Shift value at RCX 32b to the right.

XOR RCX and RDX – put the result in RDX

Put value of RDX into RSI

Shift value at RSI 16b to the right.

XOR RSI and RDX – put the result in RDX

Put 16bits (2 bytes) of value stored in RDX into EAX and fill empty bits with 0. The EAX is a register used as 1st return register. So retq (return instruction) will return value stored on this register.

There is one more thing to check – the value of a checksum is stored at 16B of a block and has 2B. It makes no sense including it into checksum calculation. So let’s compare the value of the in-memory block with actual one:

This is block stored in memory:

And here is the value from the disk:

Awesome! So those 2B are filled with zeros in memory. Now we can write our checksum code in Python and check it:

Result from BBED:

Result from my Python script:

That’s it! And what about sxorchk function? A brief look into it shows that it does the same calculations in a different manner. So my guess is, that sxorchk is just a highly optimised version of kcbhxoro and while Oracle DB is calling this function, the argument is being passed to inform kcbhxoro that I want to use in fact sxorchk – and BBED is using just the old API. But this is just a guess.

I’d like to thank Frits Hoogland for his insights on this subject 🙂

Hope to show you the new clone of BBED soon!
Cheers!

P.S.
This is a very nice article to read if you want to understand GDB usage and formatting: https://www.recurse.com/blog/7-understanding-c-by-learning-assembly