2018/05/25

Torrenter 2

Me había quedado una deuda en http://seguridad-agile.blogspot.com/2016/04/torrenter.html que procedo parcialmente a saldar.

Para poder resolver correctamente lo del dhcdp, hay que normalizar una situación: la interfaz de control, que toma la dirección de la red a la que se conecta no puede estar en la misma red que el trunk, que provée direcciones de red.

Tengo entonces que particionar el switch

VLAN

Voy a dejar el trunk y algunas bocas más en una VLAN y el resto del hogar en otra.

bridge->vlan->create->2
bridge->vlan->addPort->2->1
bridge->vlan->addPort->2->2-4 no hace falta, 1-4 estan trunking

bridge->vlan->addPort->2->5
bridge->vlan->addPort->2->...

bridge->vlan->addPort->2->12


Recapitulando



             +---------------------------+
             |        S W I T C H        |
             +-------------+-------------+
             |    VLAN2    |     VLAN1   |
             +------+------+-------------+
             | trunk|      |             |
             +------+------+-------------+
             | 1234 | 5-12 | 13-24       |
             +-++++-+------+-+-----------+
               ||||          |
192.168.2.0/24 ||||          | 192.168.1.0/24
               ||||          |
               ||||.3        | .112 x dhcp
             +-++++----+-----+----+
             | trunk   | control  |
             +---------+----------+
             |  T O R R E N T E R |
             +--------------------+

Habiendo normalizado esto, no hacen falta más los scripts goTrunk.sh y goNoTrunk.sh


DHCPD

Por último, falta proveer direcciones IP a quienes se conecten.

apt-get install isc-dhcp-server



Arranque desatendido

No voy a mentir, lo anterior quedó escrito hace mucho tiempo, ha perdido momentáneamente sino permanentemente mi interés, no creo que que agregue nueva información, queda así:

Por más último, hay que lograr que se pueda prender la máquina y funcione sin tener que interactuar.

Ya está para
  • raid
  • nginx

Falta para

  • trunking
  • routing
  • bttracker
  • btdownloadheadless
  • swap en video

Pendulómetro

Debido un experimento de la escuela de una de las personas que tengo a cargo, consistente en medir con la mayor precisión posible el tiempo de oscilación de un péndulo y aprovechando que tengo el hardware, armé y programé un medidor.



Un inconveniente que había intuido pero postergado de la versión inicial es que la medición del tiempo debía ser entre flancos, no en el flanco. Para medir un movimiento circular el flanco está ok, pero al ser oscilante, si se utiliza un flanco en un caso corresponde a un lado de la pesa y en el otro al otro, produciendo tiempos distintos donde el sentido común espera iguales.


Circular: un círculo rotando con una muesca produce el patrón A-B, con medir el tiempo A-A ya tenemos el tiempo de giro.

---+    +----------+    +----------+    +----------+    +-----
   |    |          |    |          |    |          |    |
   +----+          +----+          +----+          +----+
   A    B          A    B          A    B          A    B


Oscilante: con un péndulo,

---+    +----------+    +----------+    +----------+    +-----
   |    |          |    |          |    |          |    |
   +----+          +----+          +----+          +----+
   A    B          B    A          A    B          B    A




Pude haber utilizado la lógica de iniciar en el flanco descendente (A), desprecio el ascendente (B), miro y reinicio en descendente (A), desprecio ascendente (A)... y así.

Pude haber medido ascendente, el descendente y tomar como punto de medida el medio.

Lo que hice fue medir el tiempo que esta arriba y sumarle el que está abajo, que al igual que el anterior sirve indistintamente para ambos tipos de movimiento.

De todos modos es muy difícil que los semiciclos den lo mismo, pues para ello el punto de reposo del péndulo debe estar perfectamente centrado.

MSP430



EDU-CIAA-NXP + Poncho Educativo + SAPI





No muestro video de EDU-CIAA-NXP + Poncho Educativo + FreeOSEK pues la salida es por UART, no tiene gracia.



Usé lógica para debouncing que supuse existía pues sin ella tenía un comportamiento errático, pero el número de mediciones seguidas lo puse por que sí, no medí con ningún instrumento ni tomé ninguna medida ni cálculo.

En la versión MSP430 es tan bajo el consumo que la batería no lo detecta y tras un tiempo corta la alimentación. La EDU-CIAA-NXP + Poncho Educativo tiene un LCD con backlight y se mantiene, faltaría probar la versión que usa UART.




Las distintas versiones


Hardware


La lealtad hacia el proyecto CIAA[1] me dictaba usar la EDU-CIAA-NXP[2] con un poncho EDU[3] o PLC[4] para el LCD, pero el ambiente hostil de la escuela y que tenía más fresco usar el kit MSP430[5] marcó el camino.

Le armé una estructura protectora a los sensores, contemplando donde tener la batería y que los cables quedaran lo menos expuestos posible, aprovechando que el kit trae los conectores de expansión macho para arriba y hembra para abajo.




Habiendo funcionado el MSP430, lo reimplementé en EDU-CIAA-NXP, tanto SAPI[6] como freeOSEK[7].

Usé el poncho educativo, rastreando a ojo los pines pues no están rotulados.

Software


En todas la versiones uso un FiniteStateMachine y un poco de "pegamento" alrededor.

En el MSP430 usé CodeComposerStudio v7[8] basándome en unos ejemplos de un curso de Udemy[9] que aunque poco profundo muy bueno, para el cual compré el MSP430.

En EDU-CIAA-NXP el stack común y el Firmware_v2[10]

Para la versión con freeOSEK, tomé dos caminos distinos, el usar lo provisto por la SAPI e intentar tomar el control de las interrupciones, esto es, que en lugar de pedir al ADC que samplee, esperarlo y leer, configurarlo para que genere una interrupción.


No pude incorporar el LCD debido a que este necesita unos delays de la SAPI que utilizan los mismos recursos que freeOSEK y me he quedado sin tiempo[11], para reportar usé UART.

Tampoco pude usar las interrupciones pues no logré que me genere una y sólo una interrupción[12].

Si en algún momento termino esos puntos, actualizaré acá o será un nuevo post.

El código está en mi github[13].

Las fotos:



MSP430 funcionando



Detalle del sensor


Detalle del sensor


La batería del otro lado

[1] http://www.proyecto-ciaa.com.ar/
[2] http://www.proyecto-ciaa.com.ar/index_comprar_educiaanxp.html
[3] https://github.com/ciaa/Ponchos/tree/master/Educativo1
[4] https://github.com/ciaa/Ponchos/tree/master/Poncho%20PLC
[5] http://www.ti.com/tool/MSP-EXP430FR6989
[6] http://www.proyecto-ciaa.com.ar/index_programar_empezar.html
[7] http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:firmware:rtos
[8] http://www.ti.com/tool/CCSTUDIO
[9] https://www.udemy.com/mcu_msp430/learn/v4/overview
[10] https://github.com/ciaa/firmware_v2
[11] https://groups.google.com/forum/?hl=en#!topic/ciaa-firmware/u74iBRmj2vQ
[12] https://groups.google.com/forum/?hl=en#!topic/ciaa-firmware/ho2i3B8ektk
[13] https://github.com/cpantel/Pendulometro

2018/05/20

Forzando Brutalmente MD5 - parte 1 - cpu


¿Venís de leer la intro

En esta parte, vemos como se implementa en C, utilizando 32 bits aunque la arquitectura sea de 64. No tiene nada de especial en sí, es la implementación de la wikipedia adaptada a C.


Optimizaciones en la implementación

 

Detallo algunas optimizaciones realizadas

 

Encadenamiento

Las claves que estamos explorando miden menos de 56 bytes, entonces no hace falta hacer el proceso de encadenamiento, en el cual se va tomando lo hecho previamente y se aplica sobre cada nuevo bloque.

 

Padding

Normalmente, como los mensajes que se están hasheando tienen distintas longitudes y no suelen ser congruentes con la longitud del bloque, al último bloque se le hace un padding, esto es un relleno.

En este caso, todos los mensajes son el último y necesitan el padding por entrar sobradamente en el bloque. Pero las claves miden siempre los mismo, tienen el mismo padding, no hace falta recalcular. En realidad casi que ni hace falta calcular, se puede hardcodear, pero no hace diferencia en la performance.

 

Loop unroll

Un loop unroll consiste en tomar el cuerpo de un for y repetirlo tantas veces como se vaya a ejectuar, ajustando los valores para que el resultado sea el mismo, por ejemplo:


int accum = 0;
for (int i=0; i < 4; ++i) {
   accum += i;
}

Se convierte en

int accum = 0;
accum += 0;
accum += 1;
accum += 2;
accum += 3;


Si tenés una mínima noción de matemáticas me podrías decir que para ese cálculo se puede usar una fórmula de un solo paso, pero estoy haciendo el ejemplo más sencillo posible.

Al eliminar las decisiones, funciona mejor el pipeline de la CPU y mejora la performance, además el cáluco de i se hace en tiempo de pensarlo:



cpucpu unroll
velocidad5.79.6
rendimiento watt0.861.44
rendimiento dolar2.384


Los rendimientos por watt y por dolar son medio medio a ojo, no le prestés mucha antención.

Pero mi objetivo no es la performance en esta etapa, sino apuntar a la implementación final en FPGA donde será implementado así.



Hack rumbo a SIMD


Considerá que MD5 es un algoritmo de 32 bits y la arquitectura predominante en server/desktop/laptop es 64 bits. Esto nos deja en la situación de que se pueden calcular dos hashes simultáneos. Aun que es rehacker el rendimiento no es el esperado asi que no perdamos tiempo con esto.

 

Hack 64 bits
Hack 64 bits


Sin embargo el concepto es importante, pues nos prepara para la siguiente parte, donde tener más bits pasa de ser hack a una feature.

 

Video

  • https://www.youtube.com/channel/UCKsHdgvwvmCNnGD1Az8SSUQ

Código


  • https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v1_cpu
  • https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v1_cpu_unroll
  • https://github.com/cpantel/Forzando-Brutalmente-MD5/tree/master/v2_hack
Seguí con la parte 2

2018/05/13

Forzando Brutalmente MD5 - presentación

Forzando Brutalmente MD5 es un ciclo de charlas, probablemente cinco, en las cuales comparto la experiencia de atacar por fuerza bruta el algoritmo obsoleto de hashing MD5.

Las partes, que no necesariamente corresponden a las charlas son:

Si tiene link ya ha sido presentada públicamente, en negrita significa que ya está hecha, en itálica que la estoy elaborando. Ahora estoy sufriendo en extremo con FPGA, es muy difícil para mi. Bueh, para cualquiera.

A lo largo de las siguiente semanas y meses, iré publicando acá y en github[1] los contenidos. Acá menos técnico, en github el código.

Estos contenidos han sido presentados en vivo en

Primera parte, CPU y hack 64 bits
  • H4CK3D:  partes 1, 2 y una repasada del conjunto [2]
  • Viernes Ñoños en CADIEEL [3]
  • Charlas Ninjas, sin acceso público

Segunda parte, SIMD
  • Viernes Ñoños en CADIEEL
  • Charlas Ninjas, sin acceso público
Tercera parte, threads, forks y GPU

  • Charlas Ninjas
Cuarta parte
  • Charlas Ninjas, sin acceso público, uno de estos días. 
  • OWASP LATAM TOUR 2019[4], todo menos FPGA, vendría a ser "con computadoras"

De qué se trata


De cómo atacar por fuerza bruta un hash para obtener su preimagen utilizando distintos hardware y técnicas de programación.

En construcción desde 2017-12, pensada desde al menos un año antes.

Excusa para aprender y practicar los temas que me interesan.

Mis recursos


Libros

  • Programming with POSIX Threads – David R. Butenhof – 2009
  • Pthreads Programming – Bradford Nichols, Dick Buttlar & Jacqueline Proulx Farrell – 2009
  • Structured Computer Organization - Andrew S. Tanenbaum – ~2010
  • Distributed Systems – Andrew S. Tanenbaum – ~2010
  • Computer Architecture: A Quantitative Approach – Hennessy/Patterson – 2017
  • Computer Organization and Design: The Hardware/Software Interface ARM Edition – Patterson/Hennessy – 2017

Cursos

  • Organización del computador –  Saubidet – FIUBA 2007
  • Taller de Programación I – Veiga – FIUBA 2009
  • Programación distribuida y paralela usando MPI – Arzhan Kinzhalin – ECI 2011
  • Software Performance: Methodology and Techniques – Arzhan Kinzhalin – ECI 2007
  • Circuitos Lógicos Programables – Nicolás Álvarez – CESE 2017

Aplicabilidad


Si siguieras un camino como este estarías en mejor estado para hacer:

  • Ataques de fuerza bruta
  • Defensa ante ataques de fuerza bruta
  • Decisiones de arquitectura
  • Optimizaciones generales
  • Blockchain

Por qué MD5


  • Por que es fácil.
  • Para separar la enseñanza de la “producción”, evitando el enviciamiento que su unión produce.
  • Es obsoleto, no hay presión.
  • Es de 32 bits y me habilita el ejemplo de “hacking”

Descripción MD5


Ver wikipedia y quedarse con esto:
  • Son 64 rondas en grupos de 16 aplicadas repetidamente a buffers de 512 bits (64 bytes), aplicando un pad para completar.
  • Se aplica un valor que se calcula con una función que se puede precalcular.



[1] Github
  • https://github.com/cpantel/Forzando-Brutalmente-MD5
[2] H4CK3D
  • Sitio: https://h4ck3d.org/
[3] Viernes Ñoños en CADIEEL
  • Buscar los mensajes con el asunto [Viernes Ñoños en CADIEEL] en https://groups.google.com/forum/?hl=en#!forum/embebidos32
  • Canal en youtube: https://www.youtube.com/channel/UCKsHdgvwvmCNnGD1Az8SSUQ
  •  
[4] OWASP LATAM TOUR 2019 BsAs
  • https://www.owasp.org/index.php/LatamTour2019#tab=ARGENTINA_-_Buenos_Aires