一. 前言
wrap iname=plain.sql oname=encrypted.plb
因为代码被加密了，所以其细节被隐藏了，而且Oracle不提供解包装设备。但是我们可以编写我们自己的unwrap程序。
Oracle为了防止自己的对象程序源码泄露，也对其做了wrap处理。因为许多PACKAGE、PROCEDURE等程序本身可能存在SQL注入漏洞，但是如果得不到源码，对其进行审计是很困难的。这样wrap在一定程度上也起到了保护作用。
这里随便找一个Oracle的PACKAGE为实例，这里我们找到dbms_hs包程序，其代码如图所示：
很明显代码被加密了。
Oracle加密的原理就是先对源码进行lz压缩lzstr，然后对压缩数据进行SHA-1运算得到40位的加密串shstr，然后将加密串与压缩串拼接得到shstr+lzstr，然后对拼接后的字符串进行Oracle双字符转换（转换表）。最后将转换后的字符串进行base64编码，最终得到wrap的加密串。
关于LZ压缩，这里用老外提供的一个JAVA包，代码如下：
create or replace java source named MY_COMPRESS
as
import java.io.*;
import java.util.zip.*;
public class MY_COMPRESS
{
public static String Inflate( byte[] src )
{
try
{
ByteArrayInputStream bis = new ByteArrayInputStream( src );
InflaterInputStream iis = new InflaterInputStream( bis );
StringBuffer sb = new StringBuffer();
for( int c = iis.read(); c != -1; c = iis.read() )
{
sb.append( (char) c );
}
return sb.toString();
} catch ( Exception e )
{
}
return null;
}
public static byte[] Deflate( String src, int quality )
{
try
{
byte[] tmp = new byte[ src.length() + 100 ];
Deflater defl = new Deflater( quality );
defl.setInput( src.getBytes( “UTF-8″ ) );
defl.finish();
int cnt = defl.deflate( tmp );
byte[] res = new byte[ cnt ];
for( int i = 0; i < cnt; i++ )
res[i] = tmp[i];
return res;
} catch ( Exception e )
{
}
return null;
}
}
/
alter java source MY_COMPRESS compile
/
create or replace package mycompress
is
function deflate( src in varchar2 )
return raw;
–
function deflate( src in varchar2, quality in number )
return raw;
–
function inflate( src in raw )
return varchar2;
–
end;
/
create or replace package body mycompress
is
function deflate( src in varchar2 )
return raw
is
begin
return deflate( src, 6 );
end;
–
function deflate( src in varchar2, quality in number )
return raw
as language java
name ‘MY_COMPRESS.Deflate( java.lang.String, int ) return byte[]‘;
–
function inflate( src in raw )
return varchar2
as language java
name ‘MY_COMPRESS.Inflate( byte[] ) return java.lang.String’;
–
end;
/
这里deflate函数实现LZ压缩，而inflate则实现解压。
首先，我们以一小段PL/SQL代码来测试分先加密字符串的结构，这里我先讲程序加密处理。如图所示，这里将create PACKAGE a代码wrap之后变成了如下代码
为了进一步测试，分析其加密字符串中的结构，我们利用如下代码：
with src as
( select ‘PACKAGE a’ txt from dual )
, wrap as
( select src.txt, dbms_ddl.wrap( ‘create ‘ || src.txt ) wrap from src )
Select rtrim( substr( wrap.wrap, instr(wrap.wrap, chr(10), 1, 20 ) + 1 ),chr(10) ) from wrap;
这段代码获得加密串，如图所示
进一步对这段代码做base64解码，获得经过Oracle双字符转换后的字符串，如图所示：
因为字符串是由两部分组成，先经过LZ压缩，然后经过SHA-1处理，然后再将SHA-1字符串和压缩字符串拼接得到，因为SHA-1总共40位，所以40位以后的全为经过Oracle双字符转换的压缩串，也就是308399B8F5339FF5BF5CB891A6A6CBBFE1DC
当wrap完成sha-1字符串和压缩字符串的拼接之后，紧接着会对照一个字符代替表进行Oracle双字符转换。这个表可能是Oracle的商业机密，所以官方没有给出该表的信息。
但是，既然我们已经得到了经过字符转换之后的LZ压缩串，同时我们可以通过前面提到的JAVA包得到纯净的LZ压缩串，通过对比这两个字符串，我们便可以推算出这个转换表。
在使用这个java包时，涉及到一个压缩级别参数，这个等级参数不一样，压缩得到的字符串完全一不样。有人可能要问，这样搞岂不是没法得到替换表了吗？是的，但也不完全正确。因为可供选择的等级参数有限，我们可以从０等级开始一个一个进行测试，经过测试发现，ORACLE用的是“9”等级。所以我们用以下代码对比两个字符串：
with src as
( select ‘PACKAGE a’ txt from dual )
, wrap as
( select src.txt, dbms_ddl.wrap( ‘create ‘ || src.txt ) wrap from src )
, subst as
( select substr( utl_encode.base64_decode( utl_raw.cast_to_raw( rtrim( substr( wrap.wrap, instr(wrap.wrap, chr(10), 1, 20 ) + 1 ),chr(10) ) ) ), 41 ) x
, mycompress.deflate( wrap.txt || chr(0),9 ) d
from wrap )
select to_number( substr( x, r * 2 – 1, 2),’xx’ ) wrapped
, to_number( substr( d, r * 2 – 1, 2),’xx’ ) zipped
from subst
, ( select rownum r from dual connect by rownum < 19 );
结果