Professional Documents
Culture Documents
using BBED
ver. 1.0
Contents
Introduction ...................................................................................................................................... 3
Preparation ....................................................................................................................................... 4
Data access ....................................................................................................................................... 5
Final comment ................................................................................................................................ 14
Bibliography .................................................................................................................................... 14
Introduction
The following document describes my work related to check if it is possible to read and write data
which are placed inside ASM structures.
An idea of that article comes to my mind when I recall that Oracle has been shipped with a Binary
Block Editor which is an internal Oracle tool to view and edit database block. I was trying to read
data files based on ASM but with no luck. So I decide to investigate it a little bit deeper.
This article is an example only and I cant take responsibility for any damages of your databases. Do
not edit database block on production or other important system without assistance from Oracle
Support.
Preparation
First problem appear on very beginning there is no BBED in 11g. But with little help from Miladin
Modrakovic blog I have solve it. Now I got a tool BBED was running so what I needed was a data to
view.
There second problem appeared database file had been placed on ASM and not a file system.
BBED is a very old tool and it not working with ASM. There are two possibilities to fix that I could
use a RMAN to copy a data file from ASM into file system but this is not a good idea if your files are
big and you want to see a live data. Second option is to copy only a required database blocks
(related to data which you want to see) directly from ASM into file system and then view it.
But how to copy only some block from ASM into file system ? ASM is based on disks, so if we now
where the data are placed we can use dd command to copy them. Some important information
about ASM structure I have found in Luca Canali presentation for UKOUG. After I read it I was ready
to perform some tests. Here are results of my work.
Data access
Now I need some information related to table structure and location of the table.
Type
---------------------------NUMBER
VARCHAR2(100)
VARCHAR2(20)
SQL>
SQL> select name from v$datafile where file#=4;
NAME
-------------------------------------------------------------------------------+DATA/pioro/datafile/users.262.689687725
From above queries I have got enough information to find a database blocks related to
SECRET_TABLE and I have a table structure too.
This is a time to find a database blocks on disks. Lets start with some ASM research. All information
about ASM has been taken from Luca Canali presentation thanks.
Information which should be kept in mind is that AU size is equal to 1MB and database block size has
been set to 8 kB.
ASM file number a part of database file name and in that case this number is 262. So what is a first
allocation unit (AU) for that file ?
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
SQL> select min(AUNUM_KFDAT) from X$KFDAT where fnum_kfdat=262;
MIN(AUNUM_KFDAT)
---------------2697
Now I have information about first AU in data file, so using a information from dba_extents I can find
a allocation unit where SECRET_TABLE exist. To do that I need to recalculate number of a first block
in table into number of allocation unit offset. Block number is equal to 3456 so after multiplication
with database block size (8 kb) I have a bytes offset where table begin in datafile, if I truncate that
number into number of AU (remember 1 AU = 1MB) we will find a number of AU where first block of
table exist. If we do that same with a last block from extend (block_id+blocks) we will find a last AU.
SQL> select AUNUM_KFDAT from X$KFDAT where AUNUM_KFDAT >= (select
min(AUNUM_KFDAT)+trunc(3465*8/1024) from X$KFDAT where fnum_kfdat=262)
2 and AUNUM_KFDAT <= (select min(AUNUM_KFDAT)+trunc((3465+8)*8/1024) from
X$KFDAT where fnum_kfdat=262);
AUNUM_KFDAT
----------2724
After that I need to translate a disk and group number into physical disk name
SQL> select name, path from v$asm_disk where group_number=1 and disk_number=0;
NAME
PATH
------------------------------ -----------------------------DATA
ORCL:DATA
SQL>
Because I dont know which block of table contain my rows I have to display all blocks
dd if=/dev/VGora/tabaza bs=8k count=8 skip=348681 | strings
[root@piorovm ~]# dd if=/dev/VGora/tabaza bs=8k count=8 skip=348681 | strings
8+0 records in
8+0 records out
65536 bytes (66 kB) copied, 0.000390783 seconds, 168 MB/s
Jim Smith
4444-2222-3333-5555,
Marcin Przepiorowski
4444-1111-2222-3333
[root@piorovm ~]#
Where I have seen that information? O yes in my SECRET_TABLE. But how to check what is it ?
I have to create a file which is a copy of database block used by my table.
dd if=/dev/VGora/tabaza bs=8k count=8 skip=348681 of=secure_table.bbed
After that I can prepare a dummy file for BBED which has a information about my datafiles.
Where
-
I will check my table using a brilliant BBED documentation provided by Graham Thornton. Because I
dont know which block is filled by data I have to check all if block is empty a BBED can exist but
dont worry and check other one
8041
8005
@8105
BBED> x /r
rowdata[0]
---------flag@8105: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8106: 0x01
cols@8107:
3
0x2c
@8105
col
0[2] @8108: 0xc1 0x03
col
1[9] @8111: 0x4a 0x69 0x6d 0x20 0x53 0x6d
col
2[19] @8121: 0x34 0x34 0x34 0x34 0x2d 0x32
0x33 0x33 0x33 0x33 0x2d 0x35 0x35 0x35 0x35
0x69
0x32
0x74
0x32
0x68
0x32
0x2d
Because I know what a structure of table is I can display it in more human readable format.
BBED> x /rncc
rowdata[0]
---------flag@8105: 0x2c (KDRHFL, KDRHFF, KDRHFH)
lock@8106: 0x01
cols@8107:
3
col
col
col
@8105
0[2] @8108: 2
1[9] @8111: Jim Smith
2[19] @8121: 4444-2222-3333-5555
What else I can do with data? I can change it and try to put inside DB again. Lets try.
First of all BBED has be started in edit mode
10
BBED> p *kdbr[0]
rowdata[36]
----------ub1 rowdata[36]
@8141
0x2c
This is first row from table. I will change a first 4 digits of credit card number from 4444 to 0000.
BBED> d /v
File: secure_table.bbed (4)
Block: 8
Offsets: 8141 to 8191 Dba:0x01000008
------------------------------------------------------2c010302 c102144d 61726369 6e205072 l ,.....Marcin Pr
7a657069 6f726f77 736b6913 34343434 l zepiorowski.4444
2d313131 312d3232 32322d33 33333301 l -1111-2222-3333.
069792
l ...
<16 bytes per line>
8169
11
Change of data
BBED> m /c 0000
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: secure_table.bbed (4)
Block: 8
Offsets: 8169 to 8191
Dba:0x01000008
-----------------------------------------------------------------------30303030 2d313131 312d3232 32322d33 33333301 069792
<32 bytes per line>
Now a last part I have to copy that block back. Just to make you aware database can blow up with
ORA-00600 during that operation.
I dont need copy back all tables block but only one which I have changed. I need to generate a file
with my block. It was block number 8 (set dba 4,8) so last block allocated to that table.
dd if=secure_table.bbed of=myblock bs=8k skip=7 count=1
First block table was 348681 and I need to add 7 to point dd exactly to last table block
dd if=/oracle/app/product/11.1.0/db_1/bin/myblock of=/dev/VGora/tabaza bs=8k
count=1 seek=348688
12
If I have compared it to first result of my query I can see that CARDNUM has been changed from
4444-1111-2222-3333 into 0000-1111-2222-3333
SQL> select id, name, cardnum from pioro.secret_table;
ID NAME
CARDNUM
---------- --------------------------------------------------------------------------------------------------- -------------------1 Marcin Przepiorowski
4444-1111-2222-3333
2 Jim Smith
4444-2222-3333-5555
SQL>
There is no entries about that activities in redo logs, audit table, undo tablespace nowhere.
13
Final comment
If you are working as DBA always remember that people who have access to files, block devices or
any storage where tour DB exist can be potential intruder and can change a data without
authorization.
Bibliography
All my work was based on these excellent papers, blogs and presentations:
-
Luca Canali, CERN IT - A Closer Look inside Oracle ASM UKOUG Conference 2007
14