c# - studio - Protegiendo el código en un libro de Excel?

upload excel c#

Question

Quiero producir un libro de Excel que contenga fórmulas patentadas y otra propiedad intelectual. Lo más probable es que produzca este libro en Visual Studio 2010 con C #.

¿Qué tan protegido está el código dentro de estos proyectos? ¿Los mismos problemas con la reflexión en C # todavía se aplican a estos proyectos de libro de trabajo? Si es así, ¿existen herramientas de ofuscación específicamente para este tipo de libros?

Para agregar a esta pregunta, ¿qué pasa con el buen ''ole VBA? ¿Hay una manera de proteger ese código también si tuviéramos que ir por la ruta VBA?

Answer 1

Como han sugerido otras respuestas, la seguridad de VBA en Excel 2003 (.xls) es defectuosa; una contraseña es solo una pequeña molestia, la mayoría de las veces para el desarrollador. En mi opinión, está mejor que nunca con VSTO, incluso si la seguridad de VBA en Excel 2007+ (.xlsx) es mucho mejor, sin mencionar el IDE de VBA que no ha visto mejoras en siglos (aunque no es tan cierto con el complemento VBE adecuado -en ... ).

Una solución podría ser escribir el código sensible en una biblioteca separada a la que llama su proyecto VSTO; en lugar de fórmulas complejas, podría exponer funciones que aparecerían como "cajas negras" (es decir, una abstracción de la funcionalidad de la fórmula); la forma en que se implementa no está disponible para nadie sin el código fuente, y sin el dll, el libro no se pudo calcular (sería #NAME? todo el lugar).

Por ejemplo, en lugar de =some proprietary formula returning a Smurf , los usuarios verían =Smurf(SomeTableColumnName, SomeRangeName, SomeRangeReference, SomeCellReference) . Por supuesto, esto tiene un costo de rendimiento, así que solo haría esto por cosas que es realmente importante proteger.

Creo que un usuario que logra extraer las fórmulas propietarias de una biblioteca así en el lado, merece salir con ellas; entre eso y Alt + F11, hay un gran paso; El código de propietario está tan "protegido" como cualquier otro ensamblado .net.

ACTUALIZAR

Aún sin utilizar bibliotecas de terceros, si el código de propietario no necesita la interoperabilidad de Excel, una solución quizás mejor sería crear la función en VBA (es decir, dejar la parte de interoperabilidad de Excel dentro de Excel) y pasar solo los tipos primitivos (VBA Integer = > .net Int16 ; VBA Long => .net Int32 , cadenas, etc.) a una biblioteca visible para COM que ni siquiera necesita usar la interoperabilidad de Excel; será interoperabilidad COM en lugar de interoperabilidad de Excel y el impacto del rendimiento se reduciría significativamente, aunque todavía está presente (sigue siendo el código administrado .net "hablando" a COM no administrado).

La responsabilidad del código VBA sería leer y escribir a / desde las hojas de trabajo, y la función de la biblioteca visible para COM sería implementar los cálculos que se realizarán a partir de los valores pasados ​​por el código VBA; por supuesto, el código VBA sería fácilmente accesible para el usuario (Alt + F11), pero nuevamente no pudieron acceder a la implementación del cálculo real. Y luego, el código VBA podría estar protegido por contraseña, y los resultados del cálculo sin la DLL serían 0 ''o #VALUE! , dependiendo de cómo se implemente el código VBA.

La clave es dejar los específicos de Excel en Excel y hacer que la biblioteca .net retire donde puede hacer referencia a los ensamblajes de interoperabilidad de Excel; por ejemplo, la función VBA tomaría una referencia de celda, tomaría su valor (quizás validarlo) y lo pasaría. al ensamblado .net, que devolvería otro tipo primitivo que VBA devolvería a Excel.

Otra ventaja es que el código de la biblioteca con los cálculos de propiedad podría reutilizarse, si alguna vez tuviera que "convertir" el libro de Excel, por ejemplo, en una aplicación web.

Answer 2

Para referencia futura: aquí hay 2 nuevos productos innovadores para ayudar a resolver su problema exacto:

1) https://HiveLink.io : - Al usar HiveLink, puede crear una versión "liviana" de su hoja de cálculo, que le da a sus usuarios pero no contiene ninguna de sus VBA sensibles o fórmulas de cálculo. Retira la propiedad intelectual de la hoja de cálculo liviana y envía invitaciones para que los usuarios descarguen esta hoja de cálculo. Cuando los usuarios ingresan sus datos de entrada, HiveLink entrega los datos a su hoja de cálculo original para procesar los datos y luego devuelve los resultados al usuario automáticamente.

Lo bueno de este enfoque es que no es posible realizar ingeniería inversa con la reflexión de .NET o incluso con el código de ensamblaje, ya que elimina el código completamente de su computadora. Esta es la opción más segura, y excelente si su modelo se adapta al diseño de ida y vuelta de entrada / salida, no tan bueno si necesita un código interactivo del lado del cliente que suceda instantáneamente. Si necesita un código interactivo del lado del cliente rápido, normalmente esto es menos sensible, y puede usar la protección del libro de trabajo, o incluso compilar el código básico usando algo como el Compilador de Excel DoneEx , y tener protección usando una combinación de Compilador de Excel y HiveLink.

2) http://FCell.io : Esto le permite crear código .NET directamente en la hoja de cálculo. Incluso viene con una ventana de editor de código en la hoja de cálculo, algo así como reemplazar el editor de código VBA existente con un editor de código .NET. El modelo de objetos en el editor de código es un poco menos completo que el normal, pero también puede crear paneles de tareas e incrustarlos en el libro de trabajo para su distribución, ¡de modo que sus usuarios ni siquiera necesiten instalar nada! No estoy seguro de qué tan seguro está incrustado su código en el libro de trabajo, pero estoy 100% seguro de que la gente puede obtenerlo si es lo suficientemente importante para ellos.

Otros comentarios Re Mat''s Mug respuesta útil:

Re: costo de rendimiento: en realidad, es posible que note un aumento significativo en el rendimiento al implementar cosas en .NET, especialmente si utiliza múltiples subprocesos, lo que Excel no hace en absoluto con UDF o macros. He visto ganancias de 100x al reescribir algunos de los códigos de mis clientes en bibliotecas .NET (para cálculos de procesamiento pesado). También puede resultarle mucho más fácil mantener y mejorar el código .NET que VBA. He hecho mucha conversión de código VBA y funcionalidad a código .NET y nunca he tenido un problema de rendimiento notable cuando se realiza correctamente.

Re: ¿Los usuarios que merecen obtener acceso reflejando las bibliotecas .NET? - Estoy totalmente en desacuerdo con esto. Es extremadamente fácil obtener acceso al código .NET mediante la reflexión, tal vez incluso más fácil que descifrar las contraseñas débiles de Excel . Si realmente tiene cálculos confidenciales que desea proteger, entonces es mejor usar algo como HiveLink para eliminar completamente la posibilidad de ingeniería inversa, o usar la ofuscación para hacerlo mucho más difícil / extremadamente molesto. Para la ofuscación yo uso CryptoObfuscator ($) y Dotfuscator ($$$). No compartiría el código VBA modelo sensible de mis clientes en las bibliotecas .NET para sobresalir sin esto. También a veces uso CryptoLicensing para permitirles controlar quién puede acceder a su funcionalidad DLL mediante la creación de licencias para cada usuario.

Re: Dejar el código VBA responsable de escribir / leer desde / hacia la hoja de trabajo, también estoy muy en contra de esto. Recomendaría dejar el menor código posible en VBA y realizar una llamada de alto nivel a .NET, dejando la lectura / escritura en el complemento .NET. Use el rango con nombre en su hoja de trabajo para identificar sus entradas / salidas y ubicaciones de datos, y luego defina esos rangos con nombre como constantes en su biblioteca .NET. En tu biblioteca puedes leer fácilmente desde rangos y escribir a rangos. Es mucho más limpio y fácil de mantener de esta manera.

Al crear cualquier biblioteca de extensión para Excel en la que desee llamar a la funcionalidad externa de VBA, debe hacer que su biblioteca sea visible. Hay varias formas de hacerlo: Recomiendo encarecidamente evitar tener que registrar su biblioteca con la lista de COM de Windows usando regsvr32, ¡evítelo a toda costa!

La mejor manera de registrar su biblioteca es cargarla con ExcelDna , que le permite cargar su DLL dinámicamente cada vez que inicie Excel, sin tener que definir permanentemente cada clase con una interfaz COM en el registro (pesadilla cuando actualiza las versiones). Terminas creando un archivo XLL, que puede tener el DLL empaquetado dentro, y puedes decirle a Excel que cargue el XLL cada vez que se inicie al colocar una clave en el registro. El beneficio es que esto no requiere que almacene toda la interfaz COM en el registro, por lo que es muy fácil administrar nuevas versiones.

Por lo tanto, su código VBA podría ser algo como:

Sub Button_Click()
    Call ThisWorkbook.EnsureLibraryInitialized
    Call ThisWorkbook.MyLibrary.ReadRangesAndWriteResults(someInputParam)
End Sub

Tenga en cuenta que VBA buscaría este método ReadRangesAndWriteResults en tiempo de ejecución. Si expone el método para el tiempo de compilación en VBA, entonces tendrá que registrar su firma de interfaz COM en el registro, ¡vale la pena evitarlo a toda costa!

Este módulo de libro de trabajo:

Public MyLibrary as Object

public sub Workbook_Open()
    EnsureLibraryInitialized
End Sub

public Sub EnsureLibraryInitialized()
    Dim addin As COMAddIn
    If MyLibrary is Nothing Then
        For Each addin In Application.COMAddIns
            If InStr(addin.Description, "MyLibrary.COMHelper") Then
                If addin.object Is Nothing Then
                    ''complain it can''t connect to library, tell user to reinstall it
                Else
                    Set MyLibrary = addin.object
                Exit For
            End If
        Next
    End if
End Sub

Re: Excel Interop y bibliotecas .NET - Good points Mat''s Mug, esto puede ser una pesadilla cuando se usa el Microsoft.Office.Interop.Excel normal. Debido a que está accediendo al código nativo desde un entorno .NET administrado, debe asegurarse de que los objetos del contenedor COM de .NET se limpien correctamente o de lo contrario se producirán procesos de Excel / zombie incluso después de cerrar Excel y parece que ha desaparecido / cerrado (mira en el Administrador de tareas, ¡podrían estar ahí!)

La mejor manera que he encontrado para manejar esto es usar NetOffice , que es básicamente un clon del modelo de interoperabilidad de Excel pero creado para administrar de manera segura todos estos problemas para usted. También es mejor tener en cuenta el buen manejo seguro de los objetos COM, por ejemplo, here y here .

¡Buena suerte!

Answer 3

Si guarda el libro de trabajo con una contraseña para abrir como XLSB (tenga en cuenta esto NO protege la estructura del libro de trabajo, etc.) el libro se cifra con un cifrado razonablemente seguro (más sólido en Excel 2013).
Pero el usuario tiene que proporcionar una contraseña para abrirla, lo que no es adecuado para algunos escenarios de uso.

Todas las demás formas de protección de Excel son relativamente débiles.

El código de seguridad en Excel se realiza mejor utilizando un C ++ XLL.
La siguiente mejor opción es una DLL VB6 (pero ahora es una tecnología muerta y no funcionará en Excel de 64 bits)
El siguiente mejor es .NET ofuscado, pero realmente necesita usar el tipo de interfaz .NET XLL provista por Addin Express o XL DNA para evitar las características de rendimiento deficientes de .NET Interop y VSTO.