| |
|
121
|
Programación / Programación Visual Basic / Re: Limitar las Instalaciones
|
en: 6 Febrero 2006, 22:50 pm
|
|
yo creo que la inseguridad en estos sistemas de protección está más que demostrada. Cuantos serials encontramos para Window$, productos macr0media, compañías antivirus... Crees que nosotros aquí a lo "casero" podemos diseñar un sistema eficaz en un porcentaje más alto que los de ellos? No estoy tachando a nadie de nada, y si lo estoy haciendo, a mi el primero, pero lo mas que se puede hacer es hacer las comprobaciones con muchas funciones definidas en el codigo, y cifrarlo, para que cualquier cracker nobel no sepa crackearlo enseguida. cambiar el nombre a las dependencias, etc. En fin, solo despistar. Es mi opinion
|
|
|
|
|
124
|
Programación / Programación Visual Basic / Re: Limitar las Instalaciones
|
en: 5 Febrero 2006, 14:30 pm
|
|
antes dije que para evitar eso, se debería de agregar al registro.
Me he dado cuenta, buscando soluciones a algunos problemas de este funcionamiento, que es igual de inseguro. Lo único que se puede hacer, es ocultar las strings en el código. Si se hace eso, este funcionamiento si puede ser bueno. Cuando cargue el programa principal, que busque entre los procesos a ver si esta el fichero, si no está, se cierra y le decimos que se ha detectado un error y debe reiniciar.
El problema: La comparación puede debuggearse y ver qué string compara... Le podríamos poner un antidebugger, pero no es dificil saltarlo...
|
|
|
|
|
125
|
Programación / Programación Visual Basic / Re: Limitar las Instalaciones
|
en: 5 Febrero 2006, 14:17 pm
|
|
si, pero no se accede a él directamente. El usuario no sabe que ese fichero pertenece al programa. No sabría dónde buscar. Lo que dices se puede crackear igualmente, lo que yo dije antes, si el usuario no sabe que el exe es del programa, dónde busca para crackear?. Otro problema es que el programa principal no podría verificar la existencia del archivo, para no tener vinculación con él. En el caso de que lo encontrara, el programa ni se enteraría que no existe...
|
|
|
|
|
126
|
Programación / Programación Visual Basic / Re: Limitar las Instalaciones
|
en: 5 Febrero 2006, 02:06 am
|
|
no sé si es eficaz o no, e incluso puede ser inestable... pero no se podría hacer lo siguiente?:
1- Cuando el programa se ejecute, escribir en la memoria de un proceso una variable, cercada por dos strings constantes
2- Crear un archivo que lea dicha dirección de memoria, y guarde dicha variable en un registro que contenga las veces que se ha iniciado. Después de esto, que borre la variable de esa dirección de memoria.
Así podríamos:
1- Desviar la atención del cracker, ya que el programa no accede directamente a ningun archivo ni parte del registro
Puntos débiles:
1- Que el proceso en el que hemos escrito la variable, se cierre. Aunque sea un proceso necesario (explorer.exe) hay veces que se cuelga, (en el caso de explorer.exe, windows lo vuelve a ejecutar)
Soluciones:
P1- Leer la variable con un intervalo pequeño
Notas:
1- El fichero que lee la memoria, debe de estar agregado al registro, para no ser llamado directamente desde nuestro programa
No sé, es una solucion un poco paranóica que se me ha ocurrido. :-
|
|
|
|
|
130
|
Programación / Programación Visual Basic / Re: Proteger un programa
|
en: 3 Febrero 2006, 22:02 pm
|
Private Const LOWER_LIMIT As Long = 48
Private Const UPPER_LIMIT As Long = 125
Private Const CHARMAP As Long = 39
Public Function MIROT39(ByVal sData As String) As String
If Trim(sData) = "" Then
Exit Function
End If
Dim sReturn As String
Dim nCode As Long
Dim nData As Long
Dim bData() As Byte
ReDim bData(Len(sData)) As Byte
bData = StrConv(sData, vbFromUnicode)
For nData = 0 To UBound(bData)
nCode = bData(nData)
If ((nCode >= LOWER_LIMIT) And (nCode <= UPPER_LIMIT)) Then
nCode = nCode + CHARMAP
If nCode > UPPER_LIMIT Then
nCode = nCode - UPPER_LIMIT + LOWER_LIMIT - 1
End If
End If
bData(nData) = nCode
Next nData
sReturn = StrConv(bData, vbUnicode)
MIROT39 = sReturn
End Function  |
|
|
|
|
|
| |
|
Mostrar Mensajes