2021/10/13

Teensy al rescate

Me había contado una persona, obviamente no puedo decir cuál, que cuando entró hace ya muchos años en una importante empresa informática de alcance mundial, precursora por ese entonces en tener la modalidad de algunos días remotos, que en la laptop que le habían dado había un agente que reportaba a un sistema de monitoreo y si no interactuabas con la máquina te escrachaba. No recuerdo que recurso utilizó para engañarlo, si fué físico o por software.

Como te había contado trabajo con dos máquinas físicas, la power del trabajo llena de virtuales y la de medio pelo mía, llena de pantallas y con un buen teclado. Normalmente no uso de modo directo la del trabajo, pero a veces me viene bien poner algo en las pantallas, por ejemplo durante un reciente ejercicio de ciberseguridad mostrar un mapa de la red.

El problema es que se bloquea por falta de interacción y tiene una política que me impide cambiar el tiempo de activación del bloqueo, que debe andar por unos diez minutos. Encima está lejos y me tengo que desplazar...

Aunque a mi me moleste, es una política correcta, pues la idea es que el equipo no debe quedar expuesto si uno se distancia.

Me encuentro en una situación parecida, pero no para evitar ser controlado. En el caso de la otra persona, había un escenario adversarial entre la empresa y la persona. En mi caso, estoy pagando el efecto colateral del escenario de un tercero, adversario, afecta la usabilidad.

Necesito entonces algún método para evitar el bloqueo. Entonces recuerdo que tengo algún teensy libre, esto es un microcontrolador que se puede comportar como un dispositivo usb, en este caso en particular me interesa como teclado o mouse. 

El teensy viene a ser como un arduino, de hecho arduino ide con la extensión apropiada se usa para programarlo. No voy a repetir los detalles de la instalación de arduino ide más teensy, están en Rescatando un touchpad y Usando un touchpad con usb, donde tambien hay más detalles respecto a los botones y a comportarse como un teclado.

Lo primero que pensé es que envíe un evento de teclado, pero ¿cuál? No tiene que escribir. Usar algún modificador tambien es un problema si justo estoy escribiendo que me cambie minúscula por mayúscula y no me de cuenta.

Lo mejorcito será entonces mover apenas el mouse para un lado, luego revertir.

Necesito tambien algún feedback de que está activo, de que está actuando y poder desactivarlo sin desconectarlo, pero esto último me obligaría a armarle un gabinete, pues no tiene botón, sólo un led.

El programa es increiblemente sencillo, sólo hay que configurar apropiadamente el entorno.

 

const int ledPin = 6;

void setup() {
   pinMode(ledPin, OUTPUT);
}
void loop()
{
   Mouse.move(1, 1);
   digitalWrite(ledPin, HIGH);
   delay(1000);
   Mouse.move(-1, -1);
   digitalWrite(ledPin, LOW);
   delay(10000);   
}

 

Me lleva más tiempo mirar fijo la máquina a ver si esta funcionando que

sudo modprobe usbmon

sudo wireshark

 

Selección de usb en wireshark
Selección de usb en wireshark

 

Elegir el monitor correcto al inicio, atinarle al filtro, esperar dos mensajes y mirarlos fijos y ver que uno corresponde a Mouse.move(1, 1) y otro a Mouse.move(-1, -1).



Mouse.move(-1,-1)
Mouse.move(-1,-1)



Mouse.move(1,1)
Mouse.move(1,1)


De todos modos, mientras escribo esto, lo dejé conectado y ya pasaron 29 minutos sin bloquearse, debe andar bien.

2021/10/11

H4CK3D 2021: mejor resolución de dependencias en Makefile

Te recuerdo que todo esto tiene el objetivo de armar un ataque al comportamiento de un programa desde el hardware para mostrar en H4CK3D 2021. Como productos colaterales, una mejor adaptación de grahamedgecombe/icicle a ciaa/icicle, en parte aceptada como PR, en parte quedará en cpantel/evilCodeSequence y un montón de aprendizaje de mi parte, que te comparto como siempre, más si venís de leer todo esto:

El problema que vengo arrastrando es el tiempo:

  • yosys: 1:10
  • nextpnr-ice40: 1:45
  • iceprog: 2:00

 

No puedo evitarlos, pero como habías visto en la entrada anterior, hay dos ramas, una para el hardware y otra para el software. Convergen en la que llamo "system", que es al resultado del proceso de hardware pegotearle la imagen obtenida por el proceso de software.

Makefile detallado original
Makefile detallado original


Tal como está el Makefile, como que no está fácil, así que lo desarmé para terminar de entenderlo y lo volví a armar. De paso, veamos el proceso pero un poco menos detallado:


Makefile con reglas sencillas
Makefile con reglas sencillas, diagrama simplificado

Eliminé algunas partes del diagrama para recalcar las cuatro reglas y lo de la memoria. 

Arriba a la derecha, se arma la imagen, lo cual incluye tanto nuestro programa como otro código, de esto aún no sé mucho, parece haber algo de inicialización y el de arranque, ya seá desde la RAM o desde flash, este es un punto interesante a explorar, cargar el programa desde memoria SD, agilizaría aún más el proceso.

Arriba a la izquierda, como que estaba confundida la construcción de la imagen con la inclusión de RAM. De hecho, en el Makefile original si modificás el programa regenera sin necesidad el hardware. El primer icebram lo que hace es sólo reservar el espacio de memoria, luego, en system, nuevamente icebram, pone el programa en esa área reservada.

Las nuevas reglas las construí apuntando al final de reglas existentes, los cambios son en el Makefile:


software: BUILD/progmem.hex

Sencillo, pedís "software", hace lo necesario para construir progmem.hex.


hardware: $(ASC_SYN)

según ASC_SYN  = BUILD/$(TOP)_syn.asc viene a ser top_syn.asc en el diagrama.

 

system: $(BIN)

según BIN      = BUILD/$(TOP).bin es top.bin en el diagrama

 

Para romper el encadenamiento erróneo que había, convertí:

$(BLIF) $(JSON): $(YS) $(SRC) BUILD/progmem_syn.hex BUILD/progmem.hex BUILD/defines.sv

en

$(BLIF) $(JSON): $(YS) $(SRC) BUILD/progmem_syn.hex BUILD/defines.sv

Ahora, tal como es de esperar, puedo reemplazar el programa en sólo dos minutos en lugar de los cinco originales.


Respecto a utilizar la flash como arranque, mmh, estuve mirando con más detalle y dice ser SPI, lo cual implica cuatro señales: SCLK (el clock), SS (Slave Select para elegir el chip), MOSI (datos del master al slave) y MISO (datos del slave al master).

Para comenzar, en top.sv parecen estar los dos primeros, pero los últimos están como inout

Me da olor a Dual SPI. Más que luego se instancian uno tales "flash_io" del tipo SB_IO y TRELLIS_IO que según veo por encima rapidito tienen que ver con tristate.

 Luego, en flash.sv, dice

     assign clk_out = clk;

y no me suena que SPI soporte 36Mhz.

¡Qué lástima! Me había hecho ilusiones, incluso le había soldado los pines al sdcard reader que tengo. Esto está muy encima de mis habilidades y no es bloqueante ni aporta mucho al malware que tengo que hacer funcionar...