Una funcionalidad utilizada algunas veces para proteger la propiedad intelectual es la encriptación. En SQL Server podemos crear funciones, vistas, procedimientos almacenados añadiendo la opción “WITH ENCRYPTION” para que no se muestre el texto claro de su definición. Si leemos la explicación sobre dicha opción en los BOL vemos que ha cambiado desde SQL 2000 a 2005/2008 pero su esencia es la misma:
SQL 2000:
ENCRYPTION indicates that SQL Server converts the original text of the CREATE PROCEDURE statement to an obfuscated format. Note that obfuscated stored procedures can be reverse engineered because SQL Server must de-obfuscate procedures for execution. In SQL Server 2000, the obfuscated text is visible in the syscomments system table and may be susceptible to de-obfuscation attempts.
SQL 2005/2008:
Indicates that SQL Server will convert the original text of the CREATE PROCEDURE statement to an obfuscated format. The output of the obfuscation is not directly visible in any of the catalog views in SQL Server. Users that have no access to system tables or database files cannot retrieve the obfuscated text. However, the text will be available to privileged users that can either access system tables over the DAC port or directly access database files. Also, users that can attach a debugger to the server process can retrieve the decrypted procedure from memory at runtime. For more information about accessing system metadata, see Metadata Visibility Configuration.
Como podéis ver, se hace hincapié en que lo que se está haciendo es una ofuscación y no una encriptación real. La diferencia es muy notable y el problema es que quizás la sintaxis debería haberse definido como “WITH OBFUSCATION”. La ofuscación es una práctica que busca hacer algo más complicado de entender mediante la aplicación de algún algoritmo que dificulte su lectura mientras se mantiene el funcionamiento original. Esto es aplicable en general a cualquier tipo de código fuente, ensamblado, etc. La encriptación sin embargo lo que busca es prevenir a aquellas personas no autorizadas (normalmente que no conozcan una clave) de poder obtener el código original. La encriptación requiere pues que además de un algoritmo específico se proporcione información secreta adicional.
Una vez visto esto, podemos ver que el algoritmo de ofuscación SQL Server 2000 se ha mantenido en 2005/2008. Por tanto, modificando únicamente algunas tablas de sistema involucradas, nombres de columnas, etc. se puede utilizar el mismo mecanismo de “desofuscación” que se utilizaba para SQL Server 2000. Este tema se ha tratado más de una vez en los newsgroups de SQL Server, por ejemplo en este thread se discute sobre ello: http://www.derkeiler.com/Newsgroups/microsoft.public.sqlserver.security/2006-08/msg00286.html
Como prueba de concepto únicamente, hemos modificado uno de los scripts que se comentaba en dicho thread para aplicar las operaciones XOR y funcionara en SQL Server 2005/2008. El script no pretende ser completo ni funcionar en todos los casos (procedimientos de > 4 KB por ejemplo) aunque la idea de la debilidad de la ofuscación queda evidente como método para proteger la propiedad intelectual.
La prueba ha consistido en crear un procedimiento almacenado sencillo ofuscado y desofuscarlo:
use tempdb
GO
CREATE PROCEDURE secreto
WITH ENCRYPTION
AS
SELECT ‘misecreto’
GO
EXEC dbo.sp__procedure$decrypt ‘dbo.secreto’,0
Y este es el resultado:
Text
—————————-
CREATE PROCEDURE secreto
WITH ENCRYPTION
AS
SELECT ‘misecreto’
El código debe ser ejecutado desde una conexión privilegiada (DAC). En el siguiente enlace tenéis el script: decrypt_encrypted_procedures.sql
