PDF de programación - the original hacker 02 201312

THE ORIGINAL HACKER
SOFTWARE LIBRE, HACKING y PROGRAMA-
CIÓN, EN UN PROYECTO DE

EUGENIA BAHIT


@eugeniabahit

GLAMP HACKER Y
PROGRAMADORA EXTREMA
HACKER ESPECIALIZADA EN PROGRAMACIÓN
EXTREMA E INGENIERÍA INVERSA DE CÓDIGO
SOBRE GNU/LINUX, APACHE, MYSQL,
PYTHON Y PHP. EUGENIABAHIT.COM

DOCENTE E INSTRUCTORA DE TECNOLOGÍAS
GLAMP CURSOS.EUGENIABAHIT.COM
CURSOSDEPROGRAMACIONADISTANCIA.COM

MIEMBRO DE LA FREE SOFTWARE
FOUNDATION FSF.ORG, THE LINUX
FOUNDATION LINUXFOUNDATION.ORG E
INTEGRANTE DEL EQUIPO DE DEBIAN
HACKERS DEBIANHACKERS.NET.

CREADORA DE PYTHON-PRINTR, EUROPIO
ENGINE, JACKTHESTRIPPER. VIM CONTRI-
BUTOR. FUNDADORA DE HACKERS N'
DEVELOPERS MAGAZINE Y RESPONSABLE
EDITORIAL HASTA OCTUBRE '13.

Buenos Aires, 3 de
Diciembre de 2013

ÍNDICE DE LA
EDICIÓN NRO2

INGENIERÍA INVERSA

APLICANDO LA INGENIERÍA INVERSA: EL ARTE DE LA
CIENCIA......................................3

: DESARROLLAR SOFTWARE

PYTHON SCRIPTING

CONFIGURACIÓN MEDIANTE CONFIGPARSER..........8

: MANIPULAR ARCHIVOS DE

INGENIERÍA DE SOFTWARE
: AGREGADO DE ARCHIVOS

CRON Y EJECUCIÓN PERIÓDICA DE PROCESOS EN LOS
PAQUETES .DEB...............................18

EUROPIO ENGINE LAB
: ¿CÓMO SE HICIERON LOS ABM

DE LA WEB “THE ORIGINAL HACKER LIBRARY”?...21

SEGURIDAD INFORMÁTICA

INTELIGENTES EN PHP S–
SUPERGLOBAL $_POST.........................31

: CAPAS DE SEGURIDAD

ANEAMIENTO DEL ARRAY

The Original Hacker – www.originalhacker.org

®2013 Eugenia Bahit – www.eugeniabahit.com – Bajo Licencia Creative Commons BY-NC-SA

3

DESARROLLAR SOFTWARE
APLICANDO LA INGENIERÍA
INVERSA: EL ARTE DE LA
CIENCIA

DESARROLLAR SOFTWARE
PUEDE CONVERTIRSE EN UN
VERDADERO “ARTE
CIENTÍFICO” SI SE ES
CAPAZ DE COMBINAR
PARALELAMENTE, LÓGICA Y
PENSAMIENTO LATERAL. Y
ESO, ES LO QUE LA
INGENIERÍA INVERSA NOS
PROPONE. EN ESTA EDICIÓN
DE THE ORIGINAL HACKER,
VEREMOS EN QUÉ CONSISTE
LA INGENIERÍA INVERSA DE
SOFTWARE APLICADA
DURANTE SU DESARROLLO.

S

i alguna vez te viste envuelto en una maraña de ideas y
procedimientos al momento de desarrollar una determinada
funcionalidad y terminaste enredándote tanto que decidiste
“dibujar” lo que necesitabas alcanzar y desde allí, fuiste
sustituyendo tu “dibujo” por código hasta terminarlo, lo que hiciste,
fue aplicar un procedimiento de ingeniería inversa para resolver ese
requerimiento que tanto te enredaba.

A la ingeniería inversa muchas veces se le suele tener miedo y esto
sucede -creo yo- por la inmensa cantidad de mitos alrededor de
este maravilloso concepto pero por sobre todo -y en definitiva-, por
la gran ignorancia y desconocimiento sobre su existencia.

La ingeniería inversa plantea una
forma lateral de alcanzar
objetivos, partiendo del resultado
-el “qué”- para obtener el modo de
alcanzarlo -el “cómo”-

La ingeniería inversa es amplia. Es amplia como ciencia y como
técnica pero también como concepto, ya que si bien posee un único
significado, sus aplicaciones son tan variadas y disímiles que es allí
donde se produce la distorsión conceptual que tantos miedos
genera.

Al proponer el inicio de los procesos partiendo del objeto final, es que comúnmente se la relaciona con una de
sus aplicaciones más frecuentes:

•

Ingeniería Inversa de Hardware


: aquella que, partiendo de un componente físico (hardware) cuyo

The Original Hacker – www.originalhacker.org

®2013 Eugenia Bahit – www.eugeniabahit.com – Bajo Licencia Creative Commons BY-NC-SA

4

código es privativo (no libre, no abierto), intenta obtener un software que permita reemplazar al
controlador del fabricante.

Sin embargo, no es únicamente en esta área donde la ingeniería inversa se aplica. La ingeniería inversa tiene
muchísimas más aplicaciones, entre ellas:

•

•

Ingeniería Inversa de código
: aquella que va “siguiendo la pista” del código fuente de una aplicación

ya sea tanto para entender la forma en la que ésta funciona como para detectar fehacientemente
vulnerabilidades que no podrían ser halladas mediante herramientas para pruebas de intrusión
automatizadas (que tan de moda se han puesto en los últimos tiempos pero que sin embargo, no han
sido capaces hasta el momento, de sustituir ni reemplazar la inteligencia humana);

Ingeniería Inversa de Software
: ya sea para descomposición de aplicaciones (generalmente, aplicada

para desentrañar un Software cerrado y privativo) o para el caso contrario, la composición de
Software, a la cual nos dedicaremos en este artículo.

TDD: EL EJEMPLO PERFECTO DE INGENIERÍA INVERSA DE
SOFTWARE APLICADA AL DESARROLLO
La técnica extrema TDD (Test-Driven Development),
que en español se traduce como Desarrollo guiado
por pruebas, es un claro ejemplo de cómo la
Ingeniería Inversa aplicada al desarrollo de Software
logra lógicas realmente simples de comprender y
prácticamente unívocas e inequívocas.

Unit Testing
Las pruebas unitarias simplemente son funciones
destinadas a evaluar una única acción del código
fuente. Es así que si en nuestra aplicación tenemos
una función destinada a eliminar etiquetas HTML de
una cadena de texto, podremos tener, en paralelo 5
métodos por ejemplo, que pasen 5 cadenas de texto
diferentes a nuestra función y comprueben que el
valor de retorno sea efectivamente el esperado.

Muy frecuentemente, confundimos Unit Testing
(pruebas unitarias) con Test-Driven Development y
Test-First Programming. Estos errores de concepto
pueden generar que jamás se logre entender con
exactitud, qué es la Ingeniería Inversa, cómo se
aplica y para qué es necesario implementarla. Por
ello, me gustaría tratar de explicar los tres conceptos
con la esperanza de que por fin, queden claramente
diferenciados entre sí.

En principio, podemos decir que Unit Testing, Test-
First Programming y TDD, son tres técnicas donde
“de menor a mayor” una es requerida por la otra. Es
decir que TDD necesita de Test-First Programming y
éste, de Unit Testing. Es por ello, que comenzaremos
definiéndolos de “menor a mayor”.

Las pruebas unitarias como tales, no requieren de
Ingeniería Inversa y de hecho, hasta pueden ser
generadas de forma automatizada, por lo que de
forma aislada, no pueden considerarse como una
técnica extrema. Sin ir más lejos, las pruebas
unitarias podrían escribirse una vez que la aplicación
se encontrase ya desarrollada.

Test-First Programming
Esta es una técnica que consiste en escribir primero
las pruebas unitarias y luego el código de la
aplicación.

The Original Hacker – www.originalhacker.org

®2013 Eugenia Bahit – www.eugeniabahit.com – Bajo Licencia Creative Commons BY-NC-SA

5

Esta técnica ya es un poco más compleja que el
mero hecho de escribir pruebas unitarias pero sin
embargo, no alcanza a ser una técnica de Ingeniería
Inversa, puesto que podría facilitarse tranquilamente,
el diseño de lo que se quiere lograr (es decir, “el
cómo”) antes de contar exactamente con el objeto
(es decir, “el qué”).

pseudo-prototipos (que a veces no son más que el
resultado hardcodeado de un ejemplo de lo que se
desea lograr) ir implementando el mínimo código
necesario para que dicho pseudo-prototipo deje de
serlo. Y para escribir el mínimo código necesario,
propone utilizar Test-First Programming cómo técnica
para la implementación de las pruebas unitarias.

TDD – Test-Driven Development
El desarrollo guiado por pruebas, es pura y
exclusivamente una técnica extrema de Ingeniería
Inversa que plantea pensar primero en lo que se
quiere lograr (es decir “el qué”) y partiendo de

¿Por qué decimos que la técnica de TDD es
Ingeniería Inversa pura?
Porque para que ésta esté bien implementada, se
debe partir el desarrollo desde lo que se quiere lograr
para alcanzar de a poco el cómo lograrlo.

COMPRENDIENDO”EL QUÉ”: COMENZAR POR EL RESULTADO
A lo largo de los años he notado que lo que más le cuesta entender a todas las personas es qué es
exactamente a lo que nos referimos cuando hablamos de “resultado”, es decir, “qué es exactamente el qué”.
Y de verdad, que de tan simple que me resulta, a veces creo que esa obviedad es la que lo hace tan difícil de
entender como quizás también de explicar. El resultado es exactamente lo que esperas ver cuando
hayas terminado tu aplicación y la utilices por primera vez.

Paso a paso, un ejemplo muy sencillo y de fácil comprensión sobre cómo se implementaría la Ingeniería
Inversa en el desarrollo de Software, podría ser el siguiente:

1. Se identifica lo que se quiere alcanzar:

por ejemplo, un generador de formularios de contacto;

2. Se identifica aquello que producirá nuestro Software terminado:

por ejemplo, un formulario HTML;

3. Se crea un prototipo del producto de nuestra aplicación:

es decir, se crea un archivo HTML con un formulario de contacto a modo de ejemplo;

4. Se implementa el mínimo código necesario para que ese formulario sea retornado:

por ejemplo, desde el lenguaje de programación en el que se vaya a desarrollar la aplicación, se
procedería a crear una función que lea el contenido del archivo HTML y lo retorne. A continuación, una
instrucción, llamaría a dicha función imprimiendo en pantalla el valor de retorno;

5. Se procedería a repetir el paso 4, de a un ítem por vez:

esto se hará, hasta lograr que el formulario HTML sea generado de forma 100% dinámica;

The Original Hacker – www.originalhacker.org

®2013 Eugenia Bahit – www.eugeniabahit.com – Bajo Licencia Creative Commons BY-NC-SA

6

Cuando además, se implementa TDD como técnica para lograr el paso 4, la diferencia con la guía
anterior, es que tras el paso 3, se aplica Test-First Programming para lograr el paso 4.

TROUBLESHOOTING: INGENIERÍA INVERSA
Este subtítulo fue puesto ex profeso a fin