Mensajes

Buenas amigos, estoy con un programita hecho con Delphi XE7 de 64 bits y todo sería más sencillo con un decompilador de Delphi que soporte esa versión. He probado idr y solo soporta 32 bits. ¿Saben de alguno que me pueda ayudar?

Pues si lo solucioné. La cosa es que yo me mareaba intentando atacar a la función RaiseException que es la que usan para el truco antidebug y que lo usan para enviar un mensaje al debugger. Si hay debugger no da ninguna excepción porque el debugger la gestiona y por ahí es por dónde te pilla ya que precisamente el chico bueno lo tiene en un seh. La cosa es que no hay que hacer nada a RaiseException, simplemente puse un condicional en donde gestiono OutputDebugString y si tengo activado el truco para evitar ese antidebug devuelvo DBG_EXCEPTION_NOT_HANDLED y listo, ya con eso ni se entera y entra en su manejador y ya no me pilla 😬

Creo que he conseguido solucionarlo. Cuando lo confirme mañana lo explico. Me ayudaron en el grupo de Telegram de x64dbg donde me orientaron por dónde debía entrarle.

Hola amigos, uno de los trucos que quiero implementarlo en mi clase para crear loader debuggers es saltarse la protección antidebugger para Windows 10 basada en RaiseException para provocar evento OutputDebugEvent. Lo que hace es que si no hay debugger no se envía el mensaje y da una excepción que la aplicación controla y si hay debugger no se produce excepción y por ahí nos pilla. Os pongo un código de ejemplo:

Código [Seleccionar] Expandir

void __stdcall _OutputDebugStringW(LPCWSTR lpOutputString)
{
        char outputDebugStringBuffer[1000] = {0};
        WideCharToMultiByte(CP_ACP, 0, lpOutputString, -1, outputDebugStringBuffer, sizeof(outputDebugStringBuffer), 0, 0);

        ULONG_PTR args[4];

        //unicode
        args[0] = (ULONG_PTR)wcslen(lpOutputString) + 1;
        args[1] = (ULONG_PTR)lpOutputString;

        //ansi for compatibility
        args[2] = (ULONG_PTR)wcslen(lpOutputString) + 1;
        args[3] = (ULONG_PTR)outputDebugStringBuffer;

        __try
        {
                RaiseException(0x4001000A, 0, 4, args);//DBG_PRINTEXCEPTION_WIDE_C
                ShowMessageBox("DBG_PRINTEXCEPTION_WIDE_C -> Debugger detected");
        }
        __except(EXCEPTION_EXECUTE_HANDLER)
        {
                ShowMessageBox("DBG_PRINTEXCEPTION_WIDE_C -> Debugger NOT detected");
        }
}
La cosa es ¿Como puedo implementar un truco para saltarse esa protección? Se me ocurrió poner un bp en esa api y estando en ese bp devolverle EXCEPTION_EXECUTE_HANDLER ¿Alguna sugerencia?

Buenas amigos, estoy liado creando una clase de C++Builder x64 y estoy añadiéndole trucos anti antidebug y me encuentro con algo raro. Si modifico el PEB y cambio el valor de BeingDebuger ya no me da excepción de handle invalido al usar CloseHandle con un handle invalido y si no modifico el valor de BeingDebuger en el PEB ya si me da la excepción por handle invalido. Esto se resume con que si hago que no me detecte a través de BeingDebuger y usa el truco de handle invalido con CloseHandle me pillaría ya que al no darme la excepción en el debuger no podría controlarla.
¿Es normal eso?¿A alguien más le pasó?

Bueno esto va para largo ya que lo estaba haciendo con la clase tdebugger que hicimos guan de dio y yo y me he dado cuenta que no posee la opción de desatacheo con lo que me pondré a ello y de paso haré también para poder obtener información del proceso ya el el depurador tiene toda la info pero desde el proceso no puedo acceder a ella.

Mmmm lo miraré gracias

Eso ya lo hago usando un botón en mi loader debuger cuando ya se muestra la ventana del DialogBoxParam pero quiero que lo haga de forma automática y para ello tengo que tener ya la ventana y el cuadro de texto y al hacerlo tanto el loader como la aplicación se quedan congelados. No puedo esperar a que muestre la ventana porque es como un MessageBox y se queda a la espera de una acción y hasta que esa acción no se haga no recupero el control en el loader debuger. No se si me explico.
No tengo ahora el pc delante pero imagina esto:
call DialogBoxParamA
test eax,eax

Imagina que ese call es el encargado de mostrar el mensaje y yo quiero modificar el TEdit, pues bien la idea sería poner un bp en la siguiente línea pero eso no sirve porque la siguiente línea no se ejecuta hasta que se cierre el cuadro de diálogo con lo que no me es posible enviarle nada desde ahí.

El tema es algo más complejo porque enviar texto ya sé cómo enviarlo pero lo que tengo entre manos es otra cosa.
Tengo un loader debugger el cual lanza una aplicación y cazo el serial correcto y quiero enviarlo automáticamente al TEdit y que no tenga que enviarlo yo dando a un botón.
El caso es que la ventana se crea con DialogBoxParamA y tengo el punto donde el programa lo llama para mostrarlo pero una vez ejecuta esa línea ya se queda esperando una respuesta con lo que no me vale poner un bp en la siguiente línea y enviar el serial desde ahí.
Probé a, estando parado en el call que crea el cuadro de diálogo, poner un bp en FillRect y cuando para ya salgo de esa función con el TEdit que se muestra en el cuadro de diálogo pero si envío el serial en ese momento se me congela tanto el depurador como el programa.
¿Alguien me puede ayudar a encontrar el punto correcto para poder enviarle el serial al TEdit?
Gracias por adelantado.

Adjunto lo que llevo hasta ahora: https://mega.nz/#!p4MDHYoK!8iJCvwdKIqYDzkfpQoKvdJEagIZbU0gReBpqRpEP-Jk
Por ahora quitados los delegates, descifrado, resueltas las strings, y vaciado el constructor de <Module>.cctor.
Me falta reparar los recursos que los tengo dumpeados con megadump, reparar las constantes que la verdad no se ni que son pero supongo que tendrá que ver con las funciones extrañas y clases que no vienen mucho a cuento y que tienen pinta de ser cosa de uno de los ofuscadores, y tambien me falta limpiar las clases y delegates que ya no sirvan. La verdad es que aunque lo resuelva no voy a poder depurarlo en mi pc porque desde que instalé visual studio ya no me deja y me da un error que por lo que he leido es porque el ejecutable fue creado en una maquina con framework 4.5 y yo tengo 4.0 y tengo xp y en xp no se puede instalar el 4.5. Lo que no entiendo es porque funcionaba bien hasta que instalé Visual Studio si seguia sin tener el framework 4.5