WRAP 是 Oracle 提供的源码混淆工具，非加密，仅防 casual reading；它不阻止专业逆向，需配合权限控制（如禁 SELECT ON USER_SOURCE）和部署策略才能有效防护。
WRAP 工具不是加密，是源码混淆；它不防专业逆向，只挡 casual reading。如果你指望它防止代码泄露，得配合权限控制（如不授 SELECT on USER_SOURCE）和部署策略，否则用 FyUnwrap 一类工具几秒就能还原逻辑结构。
WRAP 命令行执行失败的常见原因
命令看似跑完，但后续在数据库里执行 @xxx.plb 报 pls-00103 或 ora-00900，大概率是输入文件不符合 wrap 的硬性语法洁癖：
-
source.sql必须是 UTF-8 无 BOM 编码（Windows 记事本默认带 BOM，直接废） - 第一行必须是顶格的
CREATE OR REPLACE，前面不能有空格、Tab、空行或注释 - 不能含 SQL*Plus 变量（如
&table_name）、斜杠结尾/、匿名块BEGIN ... END;—— 这些得提前手动清理 - 路径里别有中文、空格或 OneDrive/桌面等同步目录（Windows 下容易触发权限或路径截断）
DBMS_DDL.CREATE_WRAPPED 和 WRAP 的本质区别
DBMS_DDL.CREATE_WRAPPED 看起来更“PL/SQL 化”，但它只是字符串字面量包装器，不做语法校验，也不处理依赖：
- 传入的字符串必须是完整 DDL，包括分号
;和斜杠/，例如：'CREATE OR REPLACE PROCEDURE p AS BEGIN NULL; END; /' - 单个字符串长度不能超 ~32767 字节；包体太长会拼接失败，得切分或改用命令行
WRAP - 调用用户需有
EXECUTEonDBMS_DDL，且目标 schema 可写，否则报ORA-01031 - 返回的是 wrapped 字符串，仍需
EXECUTE IMMEDIATE才真正创建对象 —— 中间没有编译验证环节
加密后还能看到什么？别被“已加密”误导
所谓“加密”，只是让 USER_SOURCE 里显示 PACKAGE BODY WRAPPED，但以下内容依然明文可见：
- 对象名、参数名、返回类型（从
ALL_ARGUMENTS或DBA_PROCEDURES查） - 所有 SQL 文本、字符串常量、异常名（它们在 wrapped 流中未编码，只是位置偏移）
- 注释若没删，也会保留在 wrapped 输出里（部分版本）
-
DBMS_METADATA.GET_DDL返回的是 wrapped 后的 DDL，开头是CREATE OR REPLACE ... wrapped ...，不是原始源码
真正要保护核心逻辑，绕开 WRAP 的替代方案
如果业务算法真敏感，WRAP 不是解法，而是障眼法。可考虑：
- 把关键计算拆到外部：用 Java Stored Procedure（
CREATE OR REPLACE AND RESOLVE JAVA SOURCE）或 C library（CREATE LIBRARY+CREATE FUNCTION ... CALLING CONVENTION C），Oracle 不暴露这些源码 - 用细粒度权限控制：只授
EXECUTE，禁SELECTonUSER_SOURCE/DBA_SOURCE，并关闭SELECT_CATALOG_ROLE - 代码分层：把敏感逻辑藏在底层 package body，上层只暴露抽象接口，减少暴露面
最易被忽略的一点：WRAP 生成的 .plb 文件本身不含数据库连接信息，但一旦导入数据库，其 SOURCE_TEXT 就固化在 SYS.OBJ$ 里 —— 没有备份原始 .sql，出问题连调试依据都没了。
