Luigi Auriemma

Hello, I got an application that uses WSARecv() to receive packets and I have read a tip given by aluigi (post5711.html) about finding out decryption routines.
Problem is, when I break on this api and the application receives some data, after I run til return using CTRL+F9 I don't see any data inside the receive buffer. What I suspect is that the application is using the message loop to get the content of the buffer another time or something like that.
I made a pseudo-code which looks like the application I' debugging. Oh and this application uses only one call to WSARecv(), there is no other references to it.

Any ideas on how I could get the data?

WSARecv has 2 bad things for reversers:
- it uses multiple buffers and so it's boring to select the first buffer in the array pointed in the call
- exists the overlap feature of the WSA* function which is a chaos because the received data is not returned immediately, luckily doesn't seem to be used often

anyway I guess that placing the memory breakpoint on the first bytes of the first pointed buffer could work in any case, have you tried it?

in my opinion an help could be first sniffing the receiving data and so having an idea of the data it contains and its format (it should be the classical size_value:data) and then passing "signsrch -e" on the executable or on its memory to know if its used a known algorithm like aes, blowfish and so on:
http://aluigi.org/mytoolz.htm#signsrch

if you see some known algorithms in the result it's enough that you insert the offsets in the dump windows (left-down) of olly and goto that address, then use the Find Recerence of olly to know when and where these constants (sbox is the correct name for the encryption algorithms) are used and set the breakpoints there.
if you are lucky when you will receive the network data olly will break at the decryption function, the rest is only finding the key used for the decryption.

Hey all,
The original post is old now but on my google for debugging WSARecv it was the first result. I'm sharing what I've learned for the future reference of others who might stumble across it while sifting google :]

- bp WSARecv and send some data. Once the data is received u'll see something like:

0529F610 05162074 /CALL to WSARecv from 05162072
0529F614 00000230 |Socket = 230
0529F618 0529F6A4 |pBuffers = 0529F6A4
0529F61C 00000001 |nBuffers = 1
0529F620 045823F8 |pReceivedCount = 045823F8
0529F624 045823FC |pFlags = 045823FC
0529F628 01129CC0 |pOverlapped = 01129CC0
0529F62C 00000000 \Callback = NULL


- pBuffers points to an array of buffers. Dump pBuffers:

0529F6A4 00 20 00 00 F8 F8 1A 01

As Luigi suggested it is structured [size][location], location being [pBuffers+4]. In this example location is 011AF8F8.


- Dump location. An easy way to do this immdbg is highlight location and right-click + follow DWORD in dump. Once you've done this hit f9 to see your input appear.

ctrl-f9 :)
the problem is when the overlap structure is used because the received data will not return immediately