Mensajes

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

no sé si funcionaria, pero porqué no pruebas instalando el pack de runtimes de VB?

kizar, si se puede crackear. Quizás no se pueda cojer la clave, pero sí se puede crackear, simplemente sisando un/unos bytes.

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...

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...

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.  :-

http://usuarios.lycos.es/lbytes/KiZaR´s%20CrackMe%20-%20Patch%20coded%20by%20Lympex.zip

inicia el contador a 0

juas! demasiado facil, unos 15 mins xD voy a hacer el patch

mira la propiedad "MouseIcon" del label

Código [Seleccionar] Expandir


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