¿Dónde puedo almacenar (y administrar) la información de la licencia de la aplicación?

Estoy desarrollando una aplicación de Windows. Eso requiere que los usuarios se registren para usarlo … Ahora, estoy almacenando mi información de licencia como un archivo en APpData. Pero al eliminar ese archivo, se restablece la fecha de la versión de prueba. Por lo tanto, ahora estoy planeando guardarlo en el registro. Pero, la mayoría de los usuarios no tendrán privilegios administrativos (usuarios limitados) en Windows para acceder al registro. Que puedo hacer ? ¿Dónde puedo guardar mi número de serie y fecha?

En mi opinión, el punto es que debes cambiar la forma en que administras tu licencia. Escribí un proyecto ( alojado en git ) para demostrar algunas de las técnicas que se describen aquí.

Dónde

Si eliminan el archivo de datos de licencia, entonces se reinicia la prueba. No inicie la aplicación si el archivo no existe y créelo con una acción de instalación la primera vez que se instale.

Ahora se enfrenta a un segundo problema: ¿qué sucede si desinstalan y reinstalan la aplicación? El segundo paso es mover este archivo a la carpeta de datos de la aplicación (por ejemplo Environment.SpecialFolder.CommonApplicationData ). Esto es un poco más seguro (porque los datos de la aplicación no se eliminarán cuando se desinstale) pero aún es posible que los encuentren y eliminen manualmente. Si los usuarios con privilegios bajos instalan la aplicación, no hay mucho que pueda hacer (no puede tratar de ocultar la licencia en algún lugar del Registro).

Ahora es un juego entre ustedes y las cookies . Ellos ganarán, siempre. Solo harás que la vida de usuarios legítimos sea más difícil, así que lee cum grano salis . Donde puede almacenar datos de licencia:

  • Registro . Pro: fácil de hacer. Contras: fácil de descifrar y para usuarios con pocos privilegios, es válido solo para un usuario por vez. Una clave de registro (en una base por usuario) puede ocultarse de alguna manera si tiene \0 en su nombre. Echa un vistazo a esta buena publicación.
  • Archivo . Pro: fácil de hacer e IMO un poco más seguro que Registry. Contras: fácil de descifrar (pero puedes ocultarlo más, ver más adelante).
  • Aplicación en sí (agregando datos a su ejecutable, algunas palabras sobre eso en esta publicación ). Pro: más difícil de detectar. Contras: un antivirus puede ver esto como … un virus y una actualización de la aplicación también pueden eliminar la licencia (por supuesto, si no se maneja esta situación correctamente), por lo que su código y despliegue serán más complicados.

¿Cómo esconder la licencia en un archivo?
Si va con un archivo (no importa dónde esté ubicado), puede considerar hacer que las cookies tengan vida (un poco) más difícil. Dos soluciones vienen a mi mente ahora:

  • Flujos de datos alternativos . El archivo se adjunta a otro archivo y no lo verán solo con una búsqueda en el Explorador de Windows. Por supuesto, hay utilidades para administrarlos, pero al menos tienen que buscarlo explícitamente.

  • Ocultarlo dentro de los datos de la aplicación (un bitmap, por ejemplo, usando esteganografía ). Simplemente no saben sus datos de licencia, ¿qué es más seguro? El problema es que pueden descomstackr fácilmente su progtwig C # para ver lo que hace (consulte el párrafo sobre Ofuscación de códigos ).

Probablemente muchos otros (la fantasía aquí es nuestra maestra) pero no lo olvides … los crackers lo encontrarán (si realmente quieren) así que debes equilibrar tu esfuerzo.

Cómo

Al mantener su esquema de licencia, ahora se encuentra en una ruta muerta. La decisión que debe tomar es si el riesgo que utilizan prueba más tiempo de lo permitido es mayor que el riesgo de que dejen de usar su aplicación debido a la protección aburrida.

Validación
Si puede asumir que tienen una conexión de red, entonces puede validar la licencia en línea (solo la primera vez que ejecutan su aplicación) usando una ID única (incluso si se trata de Windows 8, puede consultar esta publicación aquí en SO ). La validación del lado del servidor puede ser bastante complicada (si quieres hacerlo de la manera correcta), en esta publicación se explica un ejemplo del flujo del progtwig para gestionarlo de forma adecuada.

Ofuscación / cifrado de datos
Su archivo de licencia / datos ahora se encuentra en un lugar seguro. Apenas los crackers lo encontrarán. Ahora necesitas otro paso: ofuscación. Si los datos de su licencia están en texto plano una vez que encontraron su archivo, es muy fácil cambiarlo. Usted tiene algunas opciones (ordenadas por mayor seguridad y complejidad):

  • Ofuscar sus archivos. Si no pueden entender qué hay dentro de un archivo con un editor de texto simple (o incluso un editor hexadecimal), entonces necesitarán más tiempo y esfuerzo para descifrarlo. Por ejemplo, puede comprimirlos: consulte esta publicación sobre la ofuscación de archivos XML con compresión . Tenga en cuenta que también una simple encoding base64 ofuscará sus archivos de texto.
  • Cifrelos con un algoritmo simétrico. Incluso uno muy simple funcionará bien, aquí solo intentas ocultar los datos. Vea esta publicación para un ejemplo. No veo una razón para preferir este método a una ofuscación más simple.
  • Cifrelos con un algoritmo asimétrico . Este tipo de cifrado es un gran paso en complejidad y seguridad, y será (muy) útil solo si un servidor / entidad externa proporciona un token de licencia. En este caso, ofuscará la licencia firmada con su clave privada. La aplicación del cliente validará la firma con su clave pública e incluso si el cracker encuentra este archivo (y descomstack el código para leer la clave pública) aún no podrán cambiarlo porque no tienen clave privada.

Tenga en cuenta que la ofuscación / encriptación de datos se puede utilizar junto con la esteganografía mencionada (por ejemplo, para ocultar el archivo de licencia encriptado dentro de una imagen).

Code ofuscación
Si no está utilizando la firma de licencia con encriptación asimétrica, el último paso es ofuscar su código. Hagas lo que hagas, podrán ver tu código, verificar tu algoritmo y solucionarlo. ¡Qué triste que estás implementando el manual de instrucciones! Ofender con un Obfuscator si lo desea, pero lo que sugiero es mover su verificación de licencia en un lugar menos obvio.

  • Coloque todo su código relacionado con la licencia en una DLL separada. Firme (tenga en cuenta que los ensamblados firmados se pueden decomstackr y volver a comstackr para eliminar la firma, incluso hay herramientas para hacerlo casi automáticamente).
  • Empaquetarlo dentro de los recursos ejecutables (con un nombre no tan obvio) y no implementar DLL.
  • Administre el evento AppDomain.AssemblyResolve , cuando se necesite su DLL en tiempo de ejecución, desempaquetará en la memoria y devolverá su flujo de bytes. Vea más sobre esta técnica en esta publicación de Jeffrey Richter .

Me gusta este método porque verán que hay una verificación de licencia, pero … no encontrarán el código de licencia. Por supuesto, cualquier buen cracker resolverá este problema en 10 minutos, pero estarás (un poco más) a salvo de los aleatorios .

Conclusiones

Para resumir un poco, esta es una lista de lo que puede hacer para proporcionar una verificación de licencia más sólida (puede omitir uno o más pasos, por supuesto, pero esto reducirá la seguridad):

  • Divida su código de verificación de licencia en dos conjuntos (uno para realizar la verificación y administrar la licencia y el otro para proporcionar una interfaz pública para ese motor).
  • Signo fuerte todas sus asambleas.
  • Inserte su ensamblaje de Motor de Licencia dentro de su conjunto de Interfaz de Licencia (vea la sección de Ofuscación de Código ).
  • Cree un servidor de licencias que administre sus licencias. Tenga cuidado de hacerlo seguro, de tener una conexión segura y autenticación segura (consulte la sección Validación ).
  • Guarde el archivo de licencia localmente en un lugar seguro (consulte la sección Dónde ) y encripte con un algoritmo de cifrado asimétrico (consulte la sección Ofuscación de datos ).
  • A veces, valide la licencia con su servidor de licencias (consulte la sección Validación ).

Adición: Dongle de protección de software
Un pequeño apéndice sobre las llaves de hardware (llaves de protección de software ). Son una herramienta invaluable para proteger su software, pero debe diseñar su protección con más cuidado. Puede suponer que el hardware en sí mismo es altamente seguro, pero los puntos débiles son su conexión con la computadora y la comunicación con su software.

Imagine que simplemente almacena su licencia en la llave, un cracker puede usar un USB externo (suponiendo que su SPD es USB) para compartir la misma llave con varias computadoras. También debe almacenar alguna identificación única de hardware dentro de la clave, pero en este caso el punto débil es la conexión (el hardware puede ser emulado por un controlador de software). Es un crack bastante fácil y esta falsa sensación de seguridad ( “Estoy usando Software Protection Dongle, mi software es seguro” ) hará que su aplicación sea aún más vulnerable (porque corre el riesgo de olvidar otras protecciones básicas para simplificar la administración de licencias).

El costo frente a los beneficios de una protección deficiente diseñada con SPD debería hacer que considere utilizar un pen drive USB normal. Cuesta 1 $ en lugar de 15/20 $ (o mucho más) para un SPD y tiene el mismo nivel de protección contra las cookies casuales . Por supuesto, no detendrá a un cracker serio, pero también un SPD mal diseñado no lo detendrá.

Una verdadera protección (suponiendo que no se está ejecutando en un dispositivo habilitado para DRM ) es un dongle que también puede ejecutar su código . Si puede mover algunos algoritmos básicos (al menos para descifrar archivos de soporte vitales y dynamics) a la clave, entonces para descifrar su software necesitarán crackear el hardware. Para un dongle medio decente, esta es una tarea muy, muy difícil. Con más cuidado diseñe esto y más código ingrese en la clave y más estará a salvo.

En cualquier caso, debe tener dudas acerca de las campañas de marketing: la protección del software con un dongle no es más fácil. Puede ser (mucho) más seguro, pero no es tan fácil como dicen los vendedores. En mi opinión, el costo de protección plug-n-play es demasiado alto en comparación con sus beneficios (beneficios = cuánto hará que la vida de los crackers sea más difícil).

Desafortunadamente, dondequiera que almacene información de la licencia en la máquina de un cliente está abierta a abuso (¡porque es su máquina!).

La única forma segura de hacer esto es hacer que su progtwig se registre con un servicio remoto, obviamente esto requiere mucha sobrecarga.

Mi propio enfoque es que si los clientes se meten con su clave de licencia, entonces deben esperar problemas y no tienen la obligación de ayudar. Me aseguraría de que tu clave contenga información sobre la máquina en la que se está ejecutando (para evitar simplemente copiar la clave), pero de lo contrario, mantenlo muy simple.

Al investigar las licencias yo mismo encontré una filosofía que cumplo: alejas a más clientes potenciales con configuraciones complicadas y difíciles de licenciar que las que pierdes por piratería.

Mi sugerencia es que invierta su lógica: en lugar de permitir que se elimine una clave de licencia para reiniciar la versión de prueba, ¿por qué no obligarlos a tener una clave de licencia para desbloquear la aplicación completa?

Si va a escribir a HKEY_CURRENT_USER , no necesitará derechos administrativos. por otro lado, escribir en HKEY_LOCAL_MACHINE requiere derechos administrativos.

asegúrese de abrir la tecla para escribir para llamarlo así

 RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\YourAppPath", true); 

si eso no funciona para usted, hay un truco para escribir al final del archivo ejecutable, pero eso es otra cosa.