How to debug win 32 process to find memory access violation?

Question

I have Agent installed on remote machine, this agent behave like process works in background, the process open socket connection with port number.
The problem:
this agent was exploited by security company, I am as QA want to find the problem for fix it.
I have Perl script that able to connect to the agent by socket connection and send some data to let the agent be : (db8.dc4): Access violation - code c0000005 (first chance) .

How can I debug the process while sending the data using the script to find this message of the access violation.

Maybe to use : windbg or Immunity Debugger ?

---

exception details:
(db8.dc4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=01554b40 ebx=00000000 ecx=01558c66 edx=014a0041 esi=0000139a
edi=015537a6
eip=0036cf14 esp=0145e44c ebp=ffffffff iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010206
mosifs32!os_last_trim_trailing_space+0xb717:
0036cf14 88140e mov byte ptr [esi+ecx],dl
ds:0023:0155a000=??
0:002> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0145e450 005938b8 mosifs32!os_last_trim_trailing_space+0xb717
0145e468 00594106 mchan!mchan_post_message+0x2144a
00000000 00000000 mchan!mchan_post_message+0x21c98

---

it will be so kind to get professional answer. Thanks.

Answer 1

If you have the ability to install Visual Studio's remote debugging components on the target machine you can do this as shown here.

Otherwise use Windbg as described here or here, depending on how much cooperation you can expect at the remote site.

Answer 2

Do you have a traffic dump of the attack?

It looks like you have overwritten the EBP to ffffffff, this could cause a crash. In most cases the EBP isn't as important to control as the EIP, when a function returns it pulls both the EBP and EIP from the stack and they are right next to each other. Its likley that this is a stack based overflow because of this EBP value. Although it could be another bug all together like a Dangling Pointer, but to be honest there isn't much information to go on, I'd have to look at it in a debugger.

If you have the source code then use a debugger built into your IDE like Eclipse or Visual Studio. If you don't have the source code then you can use either OllyDBG or WinDBG, its whatever you feel most comfortable with. You should attach to the process and trigger the crash again. This will show you the raw assembler that is causing this access violation. You can also set a break point before the crash to get a valid stack trace. Often times in can be tricky to find where a stack overflow occurred because the stack trace has been overwritten.

Using WinDBG/OllyDBG you can also inspect memory at the time of crash and see how you can influence the program. It is possible that you did corrupt the stack and the EIP isn't controlled because the function is crashing before it returns. Sometimes when you smash a stack you have to know some valid pointers to satisfy read/write operations before the program returns.

Answer 3

Not actually an answer about how to debug the process - others have answered that. But as supplementary information, in case it helps you:

It appears that in the function os_last_trim_trailing_space(), you are writing user-controlled data into a char buffer stored on the stack. The address of that char buffer is about 270kb above the bottom of the stack, so it's almost certainly not allocated within that function - it's probably passed in from the calling function.

The crashing instruction is effectively doing buf[5018] = 'A', where buf is considerably smaller than that. 'A' is the user-controlled data - long streams of As (0x41 in hex - the value of %dl in your dump) are typically used in demonstration exploit code.