antidebug | Collection Of Anti-Debugging Tricks | Code Inspection library

Here's what's happening:

• handle = dlopen ("libc.so", RTLD_LAZY) assigns NULL to handle. Dlopen fails because on your GNU/Linux distro (and most other modern distros) lib.so isn't a shared library - it's a GNU ld script.
  dlopen ("libc.so.6", RTLD_LAZY) would have succeeded.

• go = dlsym(handle, "ptrace") succeeds(!). With glibc, it's OK to pass a NULL pointer as the handle argument to dlsym because glibc happens to use ((void *) 0) as RTLD_DEFAULT.
  This generally won't work on other systems. FreeBSD's dlsym uses ((void *) -2) as RTLD_DEFAULT, and if you call dlsym with a NULL handle, it will look for the symbol within the executable or shared library that called dlsym.

• go(PTRACE_TRACEME, 0) succeeds.

• dlclose(handle) can't tolerate a NULL handle, and it causes a segfault, so the SIGSEGV signal is raised.

• since the process is being traced, receiving a signal results in it being stopped (suspended). Typing jobs to your shell will show the signal that made the process stop.

The code

you use static linked CRT - this is visible from your stack trace. static linked CRT in exe initialized after exe entry point is called. but tls callback on DLL_PROCESS_ATACH called before exe entry point. in this case your static CRT yet not initialized and any call to this CRT code can crash. solution - use dynamic linked CRT in separate DLL - in this case it already will be initialized before TLS callback