si, con cobein habiamos visteo que al final era cdecl por eso mismo.  es decir que con ReadDataFromTPM ya estamos listos (y funcionando).

Pero en el pastebin esta OTRA funcion, que es una que NO se cuantos parametros tiene. Teoricamente es 1 solo, un puntero a un array, pero no le cambia ningun byte. Estamos hablando de ReadCertFromTPM.

saludos

Nop. Como es CDECL, el RETN no tiene nada... es decir, si uno prepara el stack previo a la llamada, uno mismo debe hacer pop por cada parametro. Entonces la DLL no los quita del stack al volver...

En fin, el desensamblado (parcial, solo de la funcion que no se si estoy pasandole bien los argumentos) esta aqui:
http://pastebin.com/yb5Jeu7y

No esta entero. Pero es igual a la funcion por la cual cree el post.

La dll por si te interesa, esta aca
http://www.mediafire.com/?c8movap40k83qra

Si no estan instalados los drivers, va a tirar error al llamar a cualquier funcion, ya que no se carga siquiera.

Ninguno. es un RETN solo. Ademas, el IDA decia bp-based frame... por ende, es CDECL.
Era un poco ambiguo para mi (primera vez que me pasa esto, sin que el VB diga lo de "Convencion de llamadas no valido").

En fin, ahora resta descubrir la declaracion de una funcion que exporta, pero no esta declarada en el codigo de C#.

No, yo me referia a la declaracion de C#... no dice CDECL (y las llamadas a APIs comunes, se declaran igual... por eso, pense que era STDCALL).
2º, en el RETN no se eliminaban los parametros, pero arriba del RETN habia varios POP, que luego vi que no tenian nada que ver con el stack... Misteriosamente el VB no decia nada de la convencion de llamadas (normalmente lo hace)...

Bueno, creo que ya esta. Probe con el modulo cCDECL de Paul Caton, y no explota. Esto fue gracias al IDA, porque no veia que se popearan los parametros, o que se usara retn xxx.

Gracias y disculpas por la molestia...
Proximamente vamos a estar probando esto en el foro de seguridad, referido a las Netbooks del Gobierno (argentina) y otras netbooks basadas en Intel Classmate. Gracias

@Karcrack:

Si la declaracion del C# esta asi, yo asumo que es stdcall. Ademas, llamo a otras funciones que NO llevan parametros y devuelven siempre lo mismo (y no joden el stack).
Ademas NO ES ActiveX:



PD: la DLL mencionada NO ESTA hecha en C#... La aplicacion que la usa, SI.

Voy a probar de hacer algo en C# que llame a esa dll, para ver que onda... Realmente me tiene atonito esto

Hola , gracias por responder @Karcrack y @RHL.

Probe de las 2 formas recien (antes ya las habia probado), y sigue explotando.


La dll la puedo subir, no hay drama.
El tema es que no funciona si no se ejecuta bajo una Classmate netbook (por el acceso a drivers del TPM).

Basicamente ya no entiendo mas nada!!! O bien el codigo fuente en el que me estoy basando esta mal, o no se. (Tecnicamente esta bien, ya que esa aplicacion funciona).

Me es dificil andar debugueando con el olly, porque las llamadas en C# se generan en el framework, y no en el .exe principal.

Gracias

Buenas, la pregunta es simple. Tengo una api declarada en C# (en una clase).. y la quiero pasar a VB6. Es stdcall por lo que probe, asi que no habria dramas.
El tema es que usa un puntero a un array de bytes, y probe de mil y 1 formas y sigue crasheando.

        [DllImport("TPMCtrl_WinBond.dll")]
        public static extern unsafe int ReadDataFromTPM(byte* UserData);

probe con cada caso de estas declaraciones:

Private Declare Function ReadDataFromTPM Lib "TPMCtrl_WinBond.dll" (UserData As Any) As Long
Private Declare Function ReadDataFromTPM Lib "TPMCtrl_WinBond.dll" (UserData As Byte) As Long
Private Declare Function ReadDataFromTPM Lib "TPMCtrl_WinBond.dll" (ByVal UserData As Byte) As Long
Private Declare Function ReadDataFromTPM Lib "TPMCtrl_WinBond.dll" (UserData As Long) As Long
Private Declare Function ReadDataFromTPM Lib "TPMCtrl_WinBond.dll" (ByVal UserData As Long) As Long
 
Private Declare Function VarPtrArray Lib "msvbvm60.dll" Alias "VarPtr" (Var() As Any) As Long
 
Private c_bvUserData(24)       As Byte
 

con sus respectivos varptr al array de bytes (en los casos que hay ByVal). tambien probe con VarPtrArray, y lo mismo... hasta hice un odl: (obviamente era 1 solo, no todos juntos)

y sigue crasheando...

Recalco que, el error NO ES DE CONVERSION DE LLAMADAS NO VALIDO (se ve que no es cdecl).
el tamaño del array de bytes esta bien, viene de esto:

private byte[] m_UserData = new byte[0x18];

y originalmente se llama asi:

        public unsafe void GetUserData()
        {
            fixed (byte* numRef = this.m_UserData)
            {
                try
                {
                    ReadDataFromTPM(numRef);
                }
                catch
                {
                    throw;
                }
            }
        }

apreciaria ayuda...
saludos

Gente, para que esto siga adelante:
o bien se puede hacer ingenieria inversa a la bios (como propuse yo).
o se puede implementar un microcontrolador que emule el TPM y que diga "SIEMPRE OK".

no sirve de un carajo ver el tema del servidor, porque tiene una clave unica (tipo las keys privadas de los SSL), que en teoria es la que tambien esta en el TPM (creo que no se puede leer de ahi, pero si operar con ella)

y @Crazy.sx: Yo ya termine, pero aun no la lleve a liberar. Me parece una burla que nos den estos equipos de tan bajas prestaciones (y sobrevaluadisimos), con este sistema pedorrisimo. Si te la van a robar, aunque no quede util en si; el disco, bateria, ram, etc ,etc si. Y es como dice elemental code, es un desafio esto. No existe algo seguro 100%, y menos que menos algo tan pavo como esto. Tratar de meterle mano seria muy interesante.

saludos

Che, para interiorizar un poco en el tema. Hablando seriamente (yo tengo una; dado que ya termine, aviso asi Eternal Idol no me mira raro), el proceso de booteo (a mi entender, y parece lo mas logico) es asi:
* Init HW basico (como toda bios)
* Ejecucion CORE BIOS (POST)
* Probablemente aqui se realize el INIT del chip TPM, tambien se LEE y verifica su certificado y la cantidad de veces que se booteo (no se si realmente el TPM guarda algun dato aparte del certificado, por ende, la cantidad de veces que se booteo puede venir de otro lado).

Para empezar, tenemos la bios (la encontré en un post de MyDigitalLife, el chavon es de Argentina, y es una muy buena pregunta de donde saco la bios, porque no esta disponible en ningun lado). Pero no hay que estar tan felices, esa bios no esta completa (512k vs 1mb de otra).

Entonces busque otra que funcionara (probe flashearla, y bootea igual).
La descomprimi, y tengo sus partes. Se trata de una Phoenix Secure Core (es la nueva version de las Legacy de Phoenix).
Ofttopic: La bios parece que fue compilada "asi nomas", en muchos lados se pueden ver strings como: "Jumper settings can be described here.", "48spaces", etc. (strings que vienen de "ejemplo" pero que ni bola le dieron).

Bueno, para continuar: Evidentemente hay una configuracion del TPM, pero no esta disponible en el Setup standard. (hay strings relacionados como TPM Menu, Enable TPM, Disable TPM, Clear TPM, etc).

Volviendo al tema del Lock (TPM): La bios tiene ciertas prestaciones, que permiten inyectar codigo a lo pavote (archivos MOD_XXXX.ROM, ROMEXECXX.ROM, BB.BIN, BIOSCODXX.ROM y los mas interesantes: HOLEX.ROM).

Me gustaria aclarar que HOLE1.ROM tiene un HEADER MZ (aun no pude darle caña con el IDA, porque no se en que posicion de memoria se carga).

De todas formas, se pueden probar 2 cosas:
1º - encontrar el codigo que no permite bootear (ni siquiera entrar en la bios) y en lo posible parchearlo con un jmp (seguramente comprueba integridad de data, y si esta todo bien jumpea a una posicion XXX donde esta la secuencia original de booteo); o bien:

2º - encontrar el address en donde esta el codigo que comienza la secuencia real de booteo, y clavar un jmp ahi cuando se llegue al post (posiblemente, agregandolo al final del ROM del video, del LAN, o algun custom que se pueda añadir por ahi; aunque no descarto inyectar algo en el ROM del video, tipo un hook, que se llame cuando uno presiona una tecla).

3º - (el menos divertido), hacerle ingenieria inversa a los certificados que se instalan y hacer una especie de Keygen que te extiende el periodo


Ah, me olvide de decir: cuando te "liberan" la netbook, agarran, ponen un pendrive (dios sabra que tiene adentro) y la bios bootea (aunque haya estado "bloqueada"); pero se ingresa a una parte escondida (nose si esta en el pendrive, o en algun modulo rom de la bios), que te deja deshabilitar el tpm (o cargar un certificado main, realmente no vi), quedando "liberada".

Archivos para revisar:
net k.rar
Adentro esta el ROM que consegui (compatible con la original, y con el mismo sistema del Theft Deterrent), y lo que exporta la herramienta (modulos de la bios) que se puede encontrar aca.

Para flashear, es un poco mas complejo: hay que hacer un pen con DOS, y darle caña con el phlash16
(linea de comandos: PHLASH16 BP0014p.ROM /S /X /C /BBL /CS /MODE=3 /EXIT /MFG) donde BP0014p.ROM es el ROM de la bios.

esperemos que alguien pueda descompilar y ver cual modulo de la bios esta llevando a cabo la magia rara

saludos