Encerrado

WinDbg Expert Needed: Reverse Engineer Simple Client-to-Server Chat Protocol + .Net App

I have a project that requires someone skilled at run-time debugging. Here are the requirements:

- Must be skilled at run-time debugging of Win32 binaries (most important!).

- Must have knowledge of TCP/IP protocol (need to use Wireshark or similar packet sniffer effectively).

- Must be able to write a simple socket program in Python, Perl or C.

The project is to reverse engineer a chat protocol used by a popular freely available application. The goal here is to produce a homebrew client that behaves like the actual chat client (you don't have to make the homebrew client, that is my project :)).

## Deliverables

Run-Time Debugging of Win32 Binary to Reverse Engineer Simple Client-to-Server TCP/IP Chat Protocol

I have a project that requires someone skilled at run-time debugging. Here are the requirements:

- Must be skilled at run-time debugging of Win32 binaries (most important!).

- Must have knowledge of TCP/IP protocol (need to use Wireshark or similar packet sniffer effectively).

- Must be able to write a simple socket program in Python, Perl or C.

The project is to reverse engineer a chat protocol used by a popular freely available application. The goal here is to produce a homebrew client that behaves like the actual chat client (you don't have to make the homebrew client, that is my project :)). Some notes on this project:

- I have peaked at the chat protocol using Wireshark. My testing has been to send a fixed string to a chat room using the actual client. When I do this I see packets sent by the client of fixed length in each case, with several initial data bytes (probably opcode bytes) being the same for each packet sent. As I send fixed strings of longer length, the packet length sent by the client increases.

- The challenging part here is that part of the packet message is encrypted in some manner. Ex. when I send the string "hello" twice to the chat room, the client sends different data bytes in each case. My guess is that there is some bit operations going on with relation to the TCP timestamp that is being used to scramble / obfuscate the actual data.

- The hard part of this project is determining how exactly the actual data is being obfuscated / scrambled by the client. Once this is figured out, I am very certain that the underlying protocol is simple.

This project will require use of a run-time debugger such as windbg to find out how the data is being scrambled. I know, this sounds like it could be really easy or really hard, depending on how the client is designed. Some notes:

1. At least two hobbiests have succeeded in reverse engineering the protocol to build their own clients within the past several months. Therefore the project is clearly not impossible, and probably not extremely difficult.

2. All the information necessary to decode packets exists on either the client or is sent by the server at some point during login. Ex. it is certainly possible to build your own client once you obtain knowledge of how packets are encoded.

I really want to stress again that the HARD part of this project is using a run-time debugger on the binary to see how outbound data is being scrambled / obfuscated. Just using Wireshark almost certainly won't get the job done.

There are TWO deliverables required:

1. Packet-level documentation on the complete login + chat protocol, including info on decoding packets, logging in, joining a specific chat room, sending text to the chat room, server replies / acknowledgements, receiving text sent from another user, determining the list of users in the chat room, and any other chat-based communication sent or received by the client.

2. A simple application + source code (prefer Python or Perl, but a C/C++ sockets program compilable in Linux is OK too) that performs the following operations: Login, join a chat room, print the users in the chat room, sends a command to the chat room. This app does not have to be complex at all, everything can be hard-coded without a need for user input. Basically I just need you to demonstrate that the documentation provided in (1) is accurate.

Question? Please ask! I will prodide a link to the software client and a login account for debugging when I accept the bid.

Habilidades: Programação C, Engenharia, Microsoft, MySQL, PHP, Gestão de projetos, Python, Arquitetura de software, Teste de Software, Área de trabalho do Windows

Ver mais: win32 programming, when you don t get the job, use of binary, text to string, strings in c programming, string find c, software testing find job, software engineer find job, software engineer find, socket programming python, socket programming in python, socket programming in php, socket programming in c, socket login, simple binary code, simple binary, requirements needed for engineering, python software testing, python socket programming, python programming software, python programming on win32, programming in python 3, programming engineer, php programming notes, perl socket programming

Acerca do Empregador:
( 11 comentários ) United States

ID do Projeto: #2975343

6 freelancers are bidding on average $188 for this job

tzo

See private message.

$212.5 USD in 21 dias
(264 Comentários)
6.4
WinProgrammer

See private message.

$212.5 USD in 21 dias
(33 Comentários)
5.1
alienwebsl

See private message.

$195.5 USD in 21 dias
(6 Comentários)
2.7
wangyu45vw

See private message.

$85 USD in 21 dias
(3 Comentários)
0.0
athanvw

See private message.

$212.5 USD in 21 dias
(0 Comentários)
0.0
biocarbon

See private message.

$212.5 USD in 21 dias
(1 Comentário)
0.0