[20160906]修改口令在内存中.txt

[20160906]修改口令在内存中.txt

--昨天测试了在内存中修改数据块的信息,突然想到如果我修改在内存中数据块sys.user$的口令的hash值,是否可以骗过系统认证,使
--用自己定制的口令。相关链接:http://blog.itpub.net/267265/viewspace-2124466/=>[20160904]在内存修改数据.txt

--仔细想想不对,我能修改sys.user$的口令的hash值在内存中数据块,但是user名要作为数据字典加入共享池中,我仅仅修改数据块显
--然没用,但是在unxi下一切皆文件,如果我直接修改内存块的对应信息是否可行呢?测试看看。

1.环境:
SYS@book> @ &r/ver1

PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

--另外注意要使用asmm自动内存管理,这样/dev/shm可以看到一个一个文件。(如果使用手动管理设置memory_target=0.先搁置一边).
--差别是如下:
$ ls -l /dev/shm/ora_book_*|wc
    153    1224   13346

SCOTT@book> column SPARE4 format a62
SCOTT@book> select password, spare4 from sys.user$ where name = 'SCOTT';

PASSWORD                       SPARE4
------------------------------ --------------------------------------------------------------
0EDE56329E1D82EA               S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
--当前的口令是book.

--如果口令是tiger,显示如下:(这步可以先做,确定下来)
SYS@book> select password, spare4 from sys.user$ where name = 'SCOTT';
PASSWORD                       SPARE4
------------------------------ --------------------------------------------------------------
F894844C34402B67               S:332623D5C1D6892E193E237C07028356C9E6E45E93A94AD331E059B88EEE

--我的测试就是修改口令为tiger.检查使用tiger口令来连接scott用户。

2.使用strings检索
$ strings ora_book_* | grep 2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
>S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl
S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
>S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl
>S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl

$ grep 2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF ora_book_847*
Binary file ora_book_84738051_100 matches
Binary file ora_book_84738051_147 matches
Binary file ora_book_84738051_91 matches

--可以确定口令信息就在这3个"文件"中。

--以其中一个文件为例:

$ strings -t d ora_book_84738051_100 | grep 2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
3557487 >S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl
--//前面的数字就是偏移量 ,实际上口令的长度62,而前面有一些字符比如>,我使用bvi加入了一些余量,选择长度64.

--// -b 表示开始 -s 表示长度。
$ bvi -b 3557487 -s 64 ora_book_84738051_100

--替换S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
--    S:332623D5C1D6892E193E237C07028356C9E6E45E93A94AD331E059B88EEE
--如果熟悉vi,使用bvi很简单,按tab键移动到左边,移动到单词S开头处,按R(事先copy和paste要修改的字符串),直接替换就ok了。

--其他"文件"如法炮制修改。其中ora_book_84738051_91存在2处。

$ strings -t d ora_book_84738051_91 | grep 2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF
2697155 >S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl
2697327 >S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EFl

$ bvi -b 2697155 -s 64 ora_book_84738051_91
$ bvi -b 2697327 -s 64 ora_book_84738051_91

3.修改完成检查:
$ strings ora_book_* | grep 2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF

--已经没有字符串2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF。
--测试:

$ rlsql scott/tiger
SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 6 08:31:14 2016
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

--^_^,已经把口令变成了tiger。而对应的数据块并没有修改。

SCOTT@book> select rowid,password, spare4 from sys.user$ where name = 'SCOTT';
ROWID              PASSWORD                       SPARE4
------------------ ------------------------------ --------------------------------------------------------------
AAAAAKAABAAAADVAAC 0EDE56329E1D82EA               S:332623D5C1D6892E193E237C07028356C9E6E45E93A94AD331E059B88EEE

--在内存的数据块已经修改.

SCOTT@book> @ &r/rowid AAAAAKAABAAAADVAAC
    OBJECT       FILE      BLOCK        ROW ROWID_DBA            DBA                  TEXT
---------- ---------- ---------- ---------- -------------------- -------------------- ----------------------------------------
        10          1        213          2   0x4000D5           1,213                alter system dump datafile 1 block 213 ;

--通过bbed观察数据块:
BBED> set dba 1,213
        DBA             0x004000d5 (4194517 1,213)

BBED> x /rccc *kdbr[10]
rowdata[0]                                  @1879
----------
flag@1879: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@1880: 0x02
cols@1881:   22

col    0[5] @1883: SCOTT
col    1[2] @1889: ..
col   2[16] @1892: 0EDE56329E1D82EA
col    3[2] @1909: ..
col    4[2] @1912: ..
col    5[7] @1915: xq.....
col    6[7] @1923: xt.....
col    7[7] @1931: xs.....
col    8[7] @1939: xs.....
col    9[1] @1947: .
col   10[0] @1949: *NULL*
col   11[2] @1950: ..
col   12[0] @1953: *NULL*
col   13[0] @1954: *NULL*
col   14[1] @1955: .
col   15[1] @1957: .
col  16[22] @1959: DEFAULT_CONSUMER_GROUP
col   17[0] @1982: *NULL*
col   18[1] @1983: .
col   19[0] @1985: *NULL*
col   20[0] @1986: *NULL*
col  21[62] @1987: S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF

--依旧是旧的口令在数据块中。
SCOTT@book> alter system checkpoint ;
System altered.

--退出bbed在观察,看到一样。
BBED> x /rccc *kdbr[10]
rowdata[0]                                  @1879
----------
flag@1879: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@1880: 0x02
cols@1881:   22

col    0[5] @1883: SCOTT
col    1[2] @1889: ..
col   2[16] @1892: 0EDE56329E1D82EA
col    3[2] @1909: ..
col    4[2] @1912: ..
col    5[7] @1915: xq.....
col    6[7] @1923: xt.....
col    7[7] @1931: xs.....
col    8[7] @1939: xs.....
col    9[1] @1947: .
col   10[0] @1949: *NULL*
col   11[2] @1950: ..
col   12[0] @1953: *NULL*
col   13[0] @1954: *NULL*
col   14[1] @1955: .
col   15[1] @1957: .
col  16[22] @1959: DEFAULT_CONSUMER_GROUP
col   17[0] @1982: *NULL*
col   18[1] @1983: .
col   19[0] @1985: *NULL*
col   20[0] @1986: *NULL*
col  21[62] @1987: S:2B8D7DCC974D7ADF61D50A28F54E8C021D8998A639D1A93B8AC20FFB50EF

--重新启动数据库:
$ rlsql scott/book
SQL*Plus: Release 11.2.0.4.0 Production on Tue Sep 6 08:39:21 2016
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

--又回到使用原来的口令book。

时间: 2024-09-20 20:01:12

[20160906]修改口令在内存中.txt的相关文章

[20140928]数据库建立在内存中.txt

[20140928]数据库建立在内存中.txt --单位正好到了几台新机器,内存128G. --测试一下dbca slient建立数据库,因为完成后可以丢弃,把数据库建立在内存中. # mkdir -p /mnt/ramdisk # mount -t tmpfs -o size=8G tmpfs /mnt/ramdisk # su - oracle --检查环境变量是否设置正确 $ env | grep -i oracle USER=oracle LD_LIBRARY_PATH=/u01/app

修改内存-汇编中使用debug更改内存中的内容问题

问题描述 汇编中使用debug更改内存中的内容问题 为了学习汇编,我经常使用debug中的指令修改主板内存中存的数据,我想问的是,我这样总是修改联系的话会不会使电脑内存出现问题呢?有牛人说虽然我们经常修改的是那些可以修改的内存内容,但是有的机器甚至连主板ROOM内容都能修改,这样练习练习岂不是我们很有可能将来得换一块主板?哈哈,不知道我说的哪里有问题,请大神指教!谢谢 我是在虚拟机中安装操作系统,在用debug修改内存内容的,也不知道这样做是不是会影响虚拟机中的系统的正常性能,反正是不会影响原本

如何实现对象在内存中的修改和恢复

问题描述 如何实现对象在内存中的修改和恢复.比如有个类型:classStudent{publicstringName{get;set;}}为类型Student创建一个对象student,这时的student为原始对象.现在对student的属性Name做了如下修改:student.Name="csdn":然后我想把student的状态恢复回去,也就是student.Name为空.我的想法是在进行修改属性Name的操作前student对象在一块内存中,开始地址是0x12345678,然后

用C#修改delphi程序里在内存中的变量值

问题描述 请教各位大侠,想用C#去修改delphi写的程序中在内存中一个变量值,变量名知道,请问有什么办法没? 解决方案 解决方案二:有人吗?顶一顶解决方案三:有没吗?再顶顶

PHP 直接在共享内存中存储数据集

共享内存是一种在相同机器中的应用程序之间交换数据的有效方式.一个进程可创建一个可供其他进程访问的内存段,只要它分配了正确的权限.每个内存段拥有一个惟一的 ID(称为 shmid),这个 ID 指向一个物理内存区域,其他进程可在该区域操作它.创建并提供了合适的权限之后,同一台机器中的其他进程就可以操作这些内存段:读取.写入和删除. 这表明使用 C 语言编写的应用程序可与使用其他语言(比如 Java 或 PHP)编写的应用程序共享信息.它们都可以共享信息,只要它们可访问和理解该信息.共享内存在针对大

使用SharpZipLib压缩打包多个内存中的文件

SharpZipLib是C#写的开源压缩解压缩组件,最近项目上遇到一个需求:根据用户选择的项目生成CSV文件并下载,后来改为同时生成2个CSV文件下载下来.想到的解决办法就是将2个CSV文件打包成一个Zip文件,然后供用户下载. SharpZipLib可以通过很简单的代码就将多个文件打包成一个zip包,形如: using (ZipFile zip = ZipFile.Create(@"E:\test.zip")) { zip.BeginUpdate(); ZipEntry e=new

如何定位并删除内存中的内容?

问题描述 如何定位并删除内存中的内容? 例如剪切板中的内容是存储在内存中的,那么我该怎样才知道它到底存储在哪一部分并且删除它呢? 解决方案 内存中的数据,你如果能够知道地址,那么可以访问地址来修改数据等.但是还要看地址是否允许写 解决方案二: 删除它很简单,清空剪贴板或者设置点别的就可以了.

Linux内存中的Cache真的能被回收么?

在Linux系统中,我们经常用free命令来查看系统内存的使用状态.在一个RHEL6的系统上,free命令的显示内容大概是这样一个状态: [root@tencent64 ~]# free total used free shared buffers cachedMem: 132256952 72571772 59685180 0 1762632 53034704-/+ buffers/cache: 17774436 114482516Swap: 2101192 508 2100684  这里的默

Linux 内存中的 Cache 真的能被回收么?

Linux 内存中的 Cache 真的能被回收么? 在 Linux 系统中,我们经常用 free 命令来查看系统内存的使用状态.在一个 RHEL6 的系统上,free 命令的显示内容大概是这样一个状态: [root@tencent64 ~]# free total used free shared buffers cached Mem: 132256952 72571772 59685180 0 1762632 53034704 -/+ buffers/cache: 17774436 11448