QUE NO CAMBIEN LA EXTENSION DE MIS ARCHIVOS EXCEL

[wilmervera]

saludos... quisiera saber si es posible evitar que algún malintencionado cambie la extensión de mis archivos excel (xlsx, xlsm, xlam, etc.) ya que me paso que cambiandolo a archivo.zip pudieron abrir el vbaProject.bin con un editor hexadecimal y así deshabilitaron la contraseña del proyecto y tuvieron acceso a todo mi trabajo, con lo que me ocasionaron un grave perjuicio. O si no, que medidas de seguridad (a mas de las ya conocidas como contraseñas de acceso y escritura) puedo tener para que no plagien mi trabajo. gracias por la respuesta 

 

[digitalboy]

Olvídalo @wilmervera cuando uno programa sobre VBA/Excel se debe estar consciente que muy difícilmente se puede proteger al 100% el código. Yo por lo menos se tres maneras de crakear el código de una macro.

Lo se si podrías hacer es quizás ofuscar el código VBA para hacerle un poco mas difícil la lectura aquellos que accedan a tu código. Si quieres mas protección tendrás que usar otro lenguaje de programación que te genere ejecutables.

Saludos!

[wilmervera]

mmmm... te agradezco mucho por tu respuesta... eres muy amable... intentare hacer lo que me dices como sugerencia... saludos.

[Haplox]

No quiero meterme mucho en esto @wilmervera , porque mi antigua afición por el cracking () se quedó muuuuy atrás, pero si VB no ha cambiado mucho, incluso sus ejecutables eran de lo más sencillo de crackear (contraseña, timecheck, etc, etc)

Y no mucho menos cualquier ejecutable de cualquier lenguaje, solo con un buen depurador de código máquina y un poco de paciencia....

Lo mejor siempre fue los compresores de ".exe", que encriptaban código al desensamblar, eliminaban líneas o las confudían, etc. Pero ya digo que hace muuuucho de esto.

En todo esto de la ingeniería inversa, según avanzan los métodos de protección, avanzan las técnicas de crackeo. Es como una pescadilla que se muerde la cola.

Te aconsejaría que lo pusiese lo más difícil posible, siempre que el agresor no sea muy hábil,. Pasarse al código libre es otra opción (), pero eso depende de lo que cada uno pretenda obtener.

[Abraham Valencia]

Hola a todos:

Creo que si se usa Excel y VBA hay que ser conscientes de que los niveles de seguridad del código/módulos no es la mejor; claro, eso tampoco significa que sea mala y en general, desde mi punto de vista, el usuario promedio no sabrá como "romper" ciertas contraseñas o birlar ciertas medidas de seguridad. Una "mezcla" de varias de ellas puede resultar al menos "algo" difícil  en general: Usar complementos, usar siempre la contraseña del proyecto VBA, proteger hojas y/o el libro, etc. Como comento, los usuarios promedio no podrán con eso.   Aunque yo en general, cuando uso VBA, no lo protejo, personalmente no tengo problema en que lo vean y claro, si de algo de trabajo se tratase,  cuando he hecho algo para otros, dejo en ellos la decisión de protegerlo. 

Sobre qué puede ser útil, claro, una opción que no convierte en ejecutable y que permite seguir manejando el archivo de Excel como tal, es no usa VBA, sino VSTO. De ese modo los códigos usados no puede ser vistos de ningún modo. Claro, eso involucra que se tenga que "instalar" el archivo para poder usarlo, aunque ese proceso de instalación es básicamente registrar (de forma automática) las librerías, objetos ActiveX,  etc., que usará el archivo Excel.

Saludos

Abraham Valencia

[digitalboy]

Ya lo han dicho dos expertos... @Haplox y @avalencia olvidate de la protección @wilmervera!!! Lo único posible es como se dijo complicar las cosas para que al supuesto ladrón de códigos le tome tiempo el crakeo.

Quieres mayor protección? Programa en lenguajes que generen un ejecutable o programa aplicaciones web.

Saludos!