¿Hay algún beneficio en el uso de WRAP de Oracle para ofuscar el código PL / SQL?

Hay desenrolladores disponibles para el código incluido con el mecanismo de Oracle 10g y 11g. Estos incluyen tanto un "desvinculador" en línea como el código fuente de un desenvolvente escrito en Python.

Como tal, el ajuste hará poco para evitar que alguien con ese nivel de acceso obtenga el código fuente.

Se pueden obtener indicadores adicionales de la naturaleza del código utilizando las vistas * _DEPENDENCIES, a través de una traza de SQL o el uso de DBMS_TRACE.

Las vistas de dependencia mostrarán qué tablas y otros objetos pueden llamarse desde el programa, ya sea directa o indirectamente. La traza de SQL mostrará los SQL ejecutados como resultado de una llamada particular a un procedimiento. Esto puede incluir 'variables de enlace', por ejemplo, mostrando la sal utilizada en una llamada de cifrado. El DBMS_TRACE generalmente no está instalado, pero cuando está instalado y habilitado, se puede usar para rastrear la ruta tomada a través del código, en términos de números de línea y llamadas de procedimiento / función.

Para evitar que se analice el código, el primer recurso debe ser utilizar paquetes. Con los procedimientos y funciones, la totalidad del código está disponible para cualquier usuario de la base de datos que haya recibido permiso para ejecutar el programa. Con los paquetes solo están disponibles la especificación (nombre del programa y nombres de los tipos de datos / argumentos) y el código real en el cuerpo solo es visible para el propietario del programa y para aquellos con altos privilegios de base de datos (normalmente DBA).

Parece que el ajuste de texto de origen de PL / SQL no es útil para eliminar los medios técnicos para leer el código de PL / SQL, sino para lograr uno o más de los siguientes objetivos.

1. Para disuadir a los desarrolladores de software novatos de confiar en implementaciones en lugar de interfaces para paquetes y tipos. Por lo tanto, el ajuste del texto de origen podría tender a evitar problemas de compatibilidad con versiones anteriores cuando se revisen esas implementaciones.
2. Para respaldar una afirmación de que si alguien leyera esas implementaciones, esa persona transgrediría la ley DMCA en los Estados Unidos, o al menos demostraría una intención de leer esas implementaciones frente a medidas que están claramente destinadas a rendir Difíciles de leer.
3. Para evitar que las personas que son bastante informales sobre la tarea y que tienen recursos muy limitados obtengan el texto del programa.