I'm trying to crack linux program
when i open the program in GDB and run it works fine
but when ever i set a break point it exit with SIGKILL
can some one help me ?

hi!

cool it seems there could be antidebugging involved. did you try the basic checks in
ptth://home.pages.at/f001/linux_anti_anti_debugging4CBJ.txt

you can just quickly check if it calls ie ptrace.

cheers, 0xf001

strace -i might be useful for a quick attack upon the process. (examine the output, see if its doing ptrace, or kill(SIGKILL, getpid()) or so).

The -i prints out the eip of where the syscall happens. If its in the text segment (>0x08048000) it means the binary is either statically compiled, or alternatively, they are embedding the assembly commands in, and not depending on libc).

At any rate, you'll probably want to put a break point on that eip, and see if you can reach it. If you can reach it, do a back trace, and find out where in the code it is... from there I'd imagine it'd be pretty easy to identify where it is.

If you need more advice, you might want to tell us a bit more about the binary. For example,
- Whether or not its statically compiled.
- What symbols does it import (objdump -R will tell you)
- maybe some strace information of areas you think are suspect.

Hope this helps.

if i run the software with strace, it exits
Please check the attachment for strace

Hmmm.. that strace output didn't overly mean too much. It might be worthwhile checking your system log files though, as it logs to syslog (grep test.x /var/log/* or so.. you may need to find where your syslog logs to though if its not there.)

You may find some interesting information in there; for example, why it exited. You could also re-run strace with a larger string size outputed (-S 2048 or so should work, if not, check the strace man page)

An interesting note is that its threaded, so that makes some things slightly more complicated.. for starters you might want to tack -f to the strace arguments as well, and that might shed some light onto the matter.

Additionally, you might want to put a breakpoint on the code you're interested in, and also put a hardware breakpoint on that memory as well, in order to check if the code breaks inside a crc-type loop. You should be able to do the hardware assisted breakpoint via the gdb awatch command.

I noticed it appears to be statically compiled, did you try to restore symbols on the binary, or does it have symbols on it? that could provide useful for cross-referencing purposes. (Locating ptrace() calls, etc.)

Hope this helps,
- andrewg

hi,

when looking at your strace output i can see the binary uses the clone() syscall. the name is quite self explaining, it creates a clone process of it self. this is how it implements the thread(s) ([0855ad55] clone). I also wanted to suggest to use the -f option of strace (to trace the threads as well), but I never tried it on the clone syscall. can just hope it works.

also it creates several pipes to communicate either with it's clone or sthg else. I saw the syslo g facility am I right? interesting is also that it redirects via rt_sigaction the signal handlers. by this it might as well check for a debugger presence.
also the gettimeofday, time calls seem suspicous to me, it might measure the execution speed for being singlestepped broken and continued etc.

somehow I maybe you can see the whole thing under a different light - can you run linice on your system? i am pretty sure you will be able to find it quicker what is going on and maybe then this binary does not recognize a debugger at all.

for a little bit more information can you run the strace like
strace -tt -v -x -f -s 2048 yourexecutable

what the options are for you will find in the manpage

regards, 0xf001

PS: andrewg my debian says -Ssortby -sstrsize is this a typo, or?

0xf001, that was a typo. Wasn't on a box with strace installed to confirm at time of writing.

At any rate, syslog() uses various time syscalls to format the time part of the logs that are generated.

hi barshad,

I had a look at this again, after downloading the software. Actually as I see this is a VOIP daemon. Due to its nature this daemon runs in multiple instances that is where the clones come from.

Just another idea - sometimes debugging is not necessary. I loaded the file into ie lida and
found that you can try to analyze backwards from string usage like

# strings mp_kerneld.x | grep -i "trial"
TRIAL VERSION - NO MORE CALLS WILL BE ACCEPTED
MVTS: TRIAL VERSION - NO MORE CALLS WILL BE ACCEPTED

hope that helps ....

cheers, 0xf001