Desencriptar trafico TCP en un aplicación cliente-servidor

wenas gente, soy nuevo aqui, aver si alguno de vosotros me podia orientar.

weno os cuento, quiero crear un cliente alternativo para una aplicacion de chat de audio, y me gustaría observar como se establece la comunicación entre ambos lados(cliente-servidor), lo que pasa que dixa comunicación esta encriptada y quería averiguar al menos que algoritmo de encriptación utiliza (supongo que sera de clave simétrica).
En las primeras tramas siempre se repite(en ASCII):
Cliente>>Servidor:

sentido simple
encodeo NUM

Servidor>>Cliente: (el 1553831 varía cada conexion)

Servidor>3000 1553831 1553831 entro
Servidor>#Bienvenido.
Servidor>1100 sentido cambiado a simple
Servidor>1080 encodeo seteado

Cliente>>Servidor: (el 1158176071 varía cada conexion)
22:encriptar 1 1158176071
Servidor>>Cliente:
0,26:1110 encripcion habilitada

y después ya todo es ilegible, aver si me podeis decir alguna manera de estudiar el trafico para averiguar el algoritmo de cifrado que usa, supongo que la clave que use para encriptar y desencriptar(suponiendo que sea la misma) será el numeriko ese que varía en cada conexion.

Por cierto el ejecutable no tiene ningun tipo de protección, y le he estao exando un ojo en el ollydbg, a ver si aislaba el algoritmo pa encriptar, pero no tengo muxa costumbre de manejar ensamblador y no soy capaz.

Cualquier consejo recomendacion olo que sea, será agradecida, un saludo ;)

enga hombre no sudeis de mi jajajaja, que no me creo que nadie haya hecho nunca algo similar ;)

Siento no poder ayudarte. Pero no tengo experiencia alguna en esto. Es sólo que dudo que ese número aleatorio que muestra sea la clave para el cifrado, sería demasiado fácil y evidente, y no veo la necesidad de mostrarlo.

Salu2

hombre gracias por contestar :p , lo cierto es que el numerillo no es aleatorio va incrementandose en uno en cada conexión, entonces si no le manda la clave en cada conexión es que el cliente en si ya la tiene, aunque cada conexión encripta de una forma distinta , por lo que veo voy a tener que aprender a usar bien el debugger y dar gracias que el ejecutable no esta empakado con ninguna protección chunga de esas :)

Cita:

---

Iniciado por wikipedia

La mayoría de los métodos de encriptación utilizan una clave como parámetro variable en las mencionadas fórmulas matemáticas de forma que a pesar de que un intruso las conozca, no le sea posible descifrar el criptograma si no conoce la clave, la cual solo se encuentra en posesión de las personas que pueden tener acceso a la información en cuestión. Algunos métodos utilizan incluso dos claves, una privada que se utiliza para la encriptación y otra pública para la desencriptación. En algunos métodos la clave pública no puede efectuar la desencriptación o descifrado, sino solamente comprobar que el criptograma fue encriptado o cifrado usando la clave privada correspondiente y no ha sido alterado o modificado desde entonces.

---

Esto significa que puede que la tenga o puede que la negocie, por lo que creo que además del dbg vas a tener que estudiar sobre asuntos de encriptación ;)

Salu2

no si ya le estaba echando un ojo a un libro de criptografia de un tal pino caballero gil , xD, de todas maneras el concepto cifrado simetrico(clave privada)/asimetrico(clave publica) creo que lo tengo claro,
lo que yo me refiero es que si cada conexión los datos que se intercambian son los mismos, excepto esos numerikos, éstos tienen que ser si no la clave , relacionada con ella de alguna forma no crees? un saludo

Quizá los datos tampoco sean los mismos. Por ejemplo, con que en cada intercambio de datos se incluya la hora, ya nunca será exactamente igual el contenido de los mismo.

Salu2

Entonces deduzco de tus respuestas que sugieres que quiza el servidor no le mande ninguna clave de cifrado, entonces todo lo que habría que analizar sería local(en el cliente) y volvemos al debugger xD

editado: y digo yo, y porque si no necesitan intercambiar ninguna clave, la comunicación no empieza encriptada desde el primer datagrama?

No, al contrario, yo pienso que puede ser más robusto. Si la clave es variable y la introduce el usuario entonces la cosa se complica. Sólo en un sistema cuya seguridad está muy cuidada se crean los usuarios específicos para servicios concretos. Normalmente la práctica es crear un usuario en el sistema que tendrá acceso a varios servicios en el mismo. Por lo que yo creo que quizá puedas, antes que realizar ingeniería inversa sobre el programa, capturar la clave del usuario que te interese cuando éste la use en otro servicio potencialmente inseguro, de existir dicho servicio.

Salu2

la verdad no entiendo lo que me quieres decir.
la clave yo creo que sí es variable porque sinó en distintas conexiones coincidiria al menos cierta parte del tráfico cifrado, entonces si el servidor envía la clave el cliente, y suponemos que en cada conexión le manda una clave distinta, entonces el único dato que varía antes de establecer una comunicación cifrada es el numeriko que te dije entonces nose. weno si puedes aclararme lo que pusiste en el post anterior t lo agradeceria :D

Da igual, lo que te digo se sale de tu duda, sólo te decía que si el usuario introduce una clave (razón por la que no comienza encriptada la comunicación) es posible que sea la clave de usuario en el sistema y pueda ser obtenida mediante sniffing.

Salu2

ok, de acuerdo de todas maneras mi primer post es el resultado del sniffing de los primeros paquetes que se intercambian, si bien el numeriko famoso podia ser la clave que dices aunque mas bien parece algun identificador de sesion o algo parecido . gracias d nuevo :)

Suponiendo que use una función externa para encriptar/desencriptar ¿es lo que se suele hacer no? las llamadas a funciones que hace son:

[ADVAPI32.DLL]RegCreateKeyEx,RegOpenKey,RegQueryValueEx,RegSetVa lueEx

[crtdll.dll]__GetMainArgs,_cexit,_environ_dll,_fileno,_fmode_d ll,_fpreset,_iob,_setmode,_stricmp,_strnicmp,_wcsi cmp atexit,atoi,exit,fclose,fgets,fopen,fprintf,free,f write,malloc,memcpy,memmove,remove,signal,sprintf, strcat,strcmp,strcpy,strncmp,strstr,time

[GDI32.dll]BitBlt,CombineRgn,CreateCompatibleDC,CreateEllipti cRgn,CreateFont,CreatePen,CreateRectRgn,CreateSoli dBrush,DeleteDC,DeleteObject,GetObject,LineTo,
MoveToEx,SelectObject,SetBkColor,SetStretchBltMode ,SetTextColor,StretchBlt

[KERNEL32.dll]CreateThread,GetCommandLine,GetWindowsDirectory,Lo calAlloc,LocalFree,SetUnhandledExceptionFilter,Sle ep,lstrcpyn

[SHELL32.DLL]ShellExecute,Shell_NotifyIcon

[USER32.dll]AppendMenu,BeginPaint,CreateWindowEx,DefWindowProc ,DeleteMenu,DestroyIcon,DestroyMenu,DestroyWindow, DialogBoxParam,DispatchMessage,EnableWindow,EndDia log,EndPaint,EnumWindows,FindWindow,GetCapture,Get CursorPos,GetDC,GetDesktopWindow,GetDlgItemText,Ge tFocus,GetMenuItemCount,GetMessage,GetParent,GetWi ndowRect,GetWindowRgn,GetWindowText,GetWindowTextL ength,InvalidateRgn,IsIconic,IsWindow,IsWindowVisi ble,IsZoomed,LoadAccelerators,LoadBitmap,LoadCurso r,LoadIcon,LoadImage,MessageBox,MoveWindow,PostQui tMessage,RegisterClassEx,ReleaseCapture,ReleaseDC, SendDlgItemMessage,SendMessage,SetActiveWindow,Set Capture,SetDlgItemText,SetFocus,SetForegroundWindo w,SetWindowRgn,SetWindowText,ShowCursor,ShowWindow ,TrackPopupMenu,TranslateAccelerator,TranslateMess age,UnregisterClass,UpdateWindow

[WINMM.DLL]mixerClose,mixerGetControlDetails,mixerGetDevCaps, mixerGetLineControls,mixerGetLineInfo,mixerGetNumD evs,mixerOpen,mixerSetControlDetailswaveInAddBuffe r,waveInClose,waveInOpen,waveInPrepareHeader,waveI nReset,waveInStart,waveInStop,waveInUnprepareHeade r,waveOutClose,waveOutOpen,waveOutPrepareHeader,wa veOutReset,waveOutUnprepareHeader,waveOutWrite

[WSOCK32.DLL]WSAStartup,closesocket,connect,gethostbyname,htons ,inet_addr,recv,select,send,socket

Os suena a vosotros alguna función de éstas que pueda servir para encriptar/desencriptar? hombre tambien cabe la posibilidad de que se haya creado él mismo el algoritmo para encriptar, pero eso no se lo suele hacer cada uno no?
que opinais?, un saludo :)

weno parece que al fin lo conseguí parcheando el cliente, al parecer tambien se acepta la comunicación sin encriptar, es una pena me hubiese gustado interpretar el cifrado,
por cierto j8k6f4v9j lo que estoy seguro es que la encriptación venía relacionada de alguna forma con la funcion time de crtdll.dll. weno dejo una imagen aunque supongo que os la pelará basto todo esto xD.
venga un saludo :)
http://img206.imageshack.us/img206/2519/antesdespuesxq8.th.jpg

Eso del time es muy probable. Se suele usar la salida de esa función (también otras, o combinaciones de las salidas de varias) como "semilla" para la generación de datos aleatorios.

Salu2