[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with gdb not catching breakpoints in shared .dynlib

Subject: Problems with gdb not catching breakpoints in shared .dynlib
From: Greg Earle <email@hidden>
Date: Wed, 03 Nov 2004 22:04:20 -0800
Delivered-to: email@hidden
Delivered-to: email@hidden
Organization: Isolar Technical Consulting
User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)

Hi everyone,

(Not sure if this is the best/right place to ask ... but I'm trying
to port an app written for Linux, so ... )

The security team at my work asked for my help in investigating the tool
used by Script Kiddies to do brute-force SSH attacks, called
"sshblaster2":

#!/bin/sh
mkdir sshblaster2
cd sshblaster2
curl -O http://www.angelfire.com/linux/0wn3r/sshblaster2.c
curl -O http://www.angelfire.com/linux/0wn3r/libssh-0.1.tgz
gzcat libssh-0.1.tgz | tar -xpf -
ln -s libssh-0.1/include/libssh libssh
cd libssh-0.1
./configure
# Edit Makefile and libssh/Makefile to remove '-O2" from CFLAGS
# before running "make"
make
sudo cp -p libssh.dynlib /usr/local/lib/libssh.dynlib
cd ..
cc -I. -o sshblaster2 sshblaster2.c -lssh

(I had to remove the "-O2" from CFLAGS to prevent a crash.)

I made sure that the .dynlib gets created using "-g" in all
the compilations, and in the link statement.

When I run the program, it dies in a module in the library:

Host Name:      myworkmac.my.do.main
Date/Time:      2004-11-03 21:17:36 -0800
OS Version:     10.3.5 (Build 7M34)
Report Version: 2

Command: sshblaster2
Path:    ./sshblaster2
Version: ??? (???)
PID:     4430
Thread:  0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   libssh.dylib     0x3a00225c ssh_cleanup + 0x14c (client.c:211)
1   libssh.dylib     0x3a002028 ssh_connect + 0x148 (client.c:166)
2   sshblaster2      0x000023a8 checkauth + 0x138 (sshblaster2.c:106)
3   sshblaster2      0x00002660 main + 0x1a8 (sshblaster2.c:159)
4   sshblaster2      0x00001c08 _start + 0x188 (crt.c:267)
5   dyld             0x8fe1a558 _dyld_start + 0x64

Now, here's the fun part:

[21:17] myworkmac:/tmp/sshblaster2 % gdb --directory=. \ --directory=libssh-0.1/libssh --directory=libssh-0.1/include ./sshblaster2 GNU gdb 5.3-20030128 (Apple version gdb-330.1) (Fri Jul 16 21:42:28 GMT 2004) This GDB was configured as "powerpc-apple-darwin". Reading symbols for shared libraries ... done (gdb) break client.c:211 Breakpoint 1 at 0x3a002248: file client.c, line 211. (gdb) run sship.txt Starting program: /private/tmp/sshblaster2/sshblaster2 sship.txt Temporarily disabling shared library breakpoints: 1 Reading symbols for shared libraries .... done Re-enabling shared library breakpoints: 1

Program exited normally.
(gdb)

The program didn't exit normally, and gdb didn't stop at the breakpoint!
It crashed!  And in the crash log, I see:

Exception:  EXC_BREAKPOINT (0x0006)
Code[0]:    0x00000001
Code[1]:    0x3a002248

Thread 0 Crashed:
0   libssh.dylib     0x3a002248 ssh_cleanup + 0x138 (client.c:211)
1   libssh.dylib     0x3a002430 ssh_disconnect + 0xbc (client.c:243)
2   sshblaster2      0x000023e4 checkauth + 0x174 (sshblaster2.c:112)
3   sshblaster2      0x0000260c main + 0x154 (sshblaster2.c:156)
4   sshblaster2      0x00001c08 _start + 0x188 (crt.c:267)
5   dyld             0x8fe1a558 _dyld_start + 0x64

Anywhere I put the breakpoint, same thing happens - gdb isn't catching
the SIGTRAP (I assume it's a SIGTRAP) from hitting the breakpoint, so
the program dies with a BPT.  I have no clue why this is.  There's a
post (about Xcode debugging problems) at

   http://haoli.dnsalias.com/forums/viewtopic.php?t=57249

which mentions

"gdb only inserts one instruction, which generates a EXC_BREAKPOINT
exception. If you are running under the debugger you will see this or
a SIGTRAP. If you are seeing this exception where you haven't set a
breakpoint, please report it as a bug. I found (and fixed) one case
where we were leaving a breakpoint in place when we shouldn't (when you
set two "future-breakpoints" at the same location that don't end up
resolving when the app first loads). If there are other cases, I can
probably fix them pretty easily, but only if I can reproduce the
case..."

Can anyone tell me why gdb isn't catching this exception?  If I
write simple "Hello, world!" test programs that don't link to a
shared custom .dynlib (like the one in this case), breakpoints
in gdb work just fine ...

Thanks in advance,

   - Greg Earle

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden

Follow-Ups:
- Re: Problems with gdb not catching breakpoints in shared .dynlib
  - From: Eric Albert <email@hidden>

Prev by Date: system V message queue API
Next by Date: Re: Problems with gdb not catching breakpoints in shared .dynlib
Previous by thread: system V message queue API
Next by thread: Re: Problems with gdb not catching breakpoints in shared .dynlib
Index(es):
- Date
- Thread

Home