martes, 29 de diciembre de 2015

Gravity Falls

Por motivos que no aclararé, me hallo descifrando los mensajes secretos de Gravity Falls.

If you do not understand spanish, you can ask me to translate this text to english and I will put the job in the backlog

Me basé en unos programitas en python que había desarrollado para Crypto I de Coursera, que comenzé y abandoné dos veces pues al final se pone demasiado matemático para mis capacidades. Aún así, aprendí muchísimo y no dudo en recomendarlo.

La idea es que, según me han contado, hay varios cifrados. Un Caesar(3), una substitución y según pude ver de casualidad en un mensaje, un Atbash, que viene a ser 'a' -> 'z', 'b'->'y'...


$ python GravityFalls.py
?: m
    PU. FDHVDULDQ ZLOO EH RXW QHAW ZHHN. PU. DWEDVK ZLOO VXEVWLWXWH.
    ??. ????????? ???? ?? ??? ???? ????. ??. ?????? ???? ??????????.
?: try Caesar
  1 OT. ECGUCTKCP YKNN DG QWV PGZV YGGM. OT. CVDCUJ YKNN UWDUVKVWVG.
  2 NS. DBFTBSJBO XJMM CF PVU OFYU XFFL. NS. BUCBTI XJMM TVCTUJUVUF.
  3 MR. CAESARIAN WILL BE OUT NEXT WEEK. MR. ATBASH WILL SUBSTITUTE.
  4 LQ. BZDRZQHZM VHKK AD NTS MDWS VDDJ. LQ. ZSAZRG VHKK RTARSHSTSD.

   ...

Tengo entendido que buscando en Internet se halla la tabla de la substitución pero, ¿cuál es la gracia?

Como los mensajes están en inglés, el código y la interfaz tambien.

El programa soporta sólo maýusculas e ignora la puntuación, tal como son todos los mensajes obtenidos.

Emite estadísticas de frecuencia de caracteres, bigramas y trigramas, junto con tablas de frecuencias de las mismas en inglés. Esto sirve para descubrir las tablas de substitución.


¿Unit Testing? Eeeh, si, ad hoc, al comienzo orientado a refactorización y luego derivando a TDD.

¿Performance? Bueno, hay operaciones cuestionables desde ese punto de vista, como recalcular las frecuencias al pedir su visualización sin que nada haya cambiado.

¿Arquitectura? Es como la arquitectura de un banco de plaza, es poco. Es lo más sencilla posible para que sea comprensible y expandible. Lo mencionable es el Chain of Responsability para la ejecución de los comandos y el tímido MVC. Los componentes son Model y teñido por Controller en accept() y View está completamente separado.

Sintetizando, este proyecto te puede servir para aprender o practicar:
  • criptoanálisis básico
  • inglés (mensajes, interfaz, código)
  • programación (python, patrones)
En https://github.com/cpantel/gravityFalls está el código. Sólo he comiteado lo mínimo indispensable pues en el proceso de desarrollo y refactorización he cometido pecados inconfesables y no hace falta se hagan públicos.


Detalles


El protocolo de Chain of Responsability es accept(command, [message], [...]) y la respuesta es (Bool:handled, Bool:error, String:result). Al final, Printer formatea y muestra según la respuesta.

Si se quisiera agregar un módulo, por ejemplo un algoritmo para SubtitutionCipher, habría que agregarlo colgando de él, quizás pasarle el Statistical y que devuelva un dictionary

Usé Chain of Responsability en lugar de Mediator pues tenía ganas de usar Chain of Responsability. Si hiciera falta pasar a Mediator, lo haría. Ganas pero no capricho.

Estas son las tablas de frecuencias en inglés sacadas de [practicalcryptography]

Frecuencia letras (asociada a f1)



E 12.1
T 8.94
A 8.55
O 7.47
I 7.33
N 7.17
S 6.73
R 6.33
H 4.96
L 4.21
D 3.87
C 3.16
U 2.68
M 2.53
F 2.18
G 2.09
P 2.07
W 1.83
Y 1.72
B 1.6
V 1.06
K 0.81
J 0.22
X 0.19
Z 0.11
Q 0.1

Frecuencia palabras (asociada a futura fw)


THE 6.42
OF 2.76
AND 2.75
TO 2.67
A 2.43
IN 2.31
IS 1.12
FOR 1.01
THAT 0.92
WAS 0.88
ON 0.78
WITH 0.75
HE 0.75
IT 0.74
AS 0.71
AT 0.58
HIS 0.55
BY 0.51
BE 0.48
ARE 0.47
FROM 0.47
THIS 0.42
I 0.41
BUT 0.4
HAVE 0.39
AN 0.37
HAS 0.35
NOT 0.34
THEY 0.33
OR 0.3

Frecuencia bigramas (asociada a f2)


TH 2.71
HE 2.33
IN 2.03
ER 1.78
AN 1.61
RE 1.41
ES 1.32
ON 1.32
ST 1.25
NT 1.17
EN 1.13
AT 1.12
ED 1.08
ND 1.07
TO 1.07
OR 1.06
EA 1
TI 0.99
AR 0.98
TE 0.98
NG 0.89
AL 0.88
IT 0.88
AS 0.87
IS 0.86
HA 0.83
ET 0.76
SE 0.73
OU 0.72
OF 0.71

Frecuencia trigamas (asociado a f3)


THE 1.81
AND 0.73
ING 0.72
ENT 0.42
ION 0.42
HER 0.36
FOR 0.34
THA 0.33
NTH 0.33
INT 0.32
ERE 0.31
TIO 0.31
TER 0.3
EST 0.28
ERS 0.28
ATI 0.26
HAT 0.26
ATE 0.25
ALL 0.25
HES 0.24
VER 0.24
HIS 0.24
ETH 0.24
OFT 0.22
ITH 0.21
FTH 0.21
STH 0.21
OTH 0.21
RES 0.21
ONT 0.2

Frecuencia primera letra de palabra (asociado a ffw)

t 16.671
a 11.602
s 7.755
h 7.232
w 6.753
i 6.286
o 6.264
b 4.702
m 4.383
f 3.779
c 3.511
l 2.705
d 2.67
p 2.545
n 2.365
e 2.007
g 1.95
r 1.653
y 1.62
u 1.487
v 0.649
j 0.597
k 0.59
q 0.173
z 0.034
x 0.017

Frecuencia de letras repetidas (asociada a futura fd)


LL
SS
EE
OO
TT
FF
RR
NN
PP
CC
MM
GG
DD
AA
BB

Próximos pasos

Que calcule las frecuencias de letras duplicadas.
Que calcule las frecuencias de palabras
Que calcule las frecuencias de la primera letra de cada palabra
Que calcule el patrón (véase próxima entrada en uno de estos días)

Referencias


[practicalcryptography] http://practicalcryptography.com/cryptanalysis/letter-frequencies-various-languages/english-letter-frequencies/

https://en.wikipedia.org/wiki/Letter_frequency

Frecuencia de letras repetidas y buena parte de mi instrucción tomadas de Secret History:  The Story of Cryptology - Craig P. Bauer

sábado, 21 de noviembre de 2015

Choco PI

Motivos: Seguridad, Educación y Bajo consumo


if you want an english version, feel free to ask me for it

Teniendo chicos hay tres caminos:

  • Permitir todo
  • Negar todo
  • Arremangarse


Lo normal es lo primero.

Mi impulso natural es el segundo.

Esta nota y alguna futura forman parte de lo que he hecho en el marco de lo tercero.

Aclaro que no soy pedagogo, esto es resultado de mi experiencia y sentido común.

Permitir todo


Es lo más sencillo. Mirá a tu alrededor y lo verás llevado a la práctica. Niños que no saben aún leer ni escribir manejando una tablet. Está ok, salvo que lo están haciendo en lugar de estar potrereando/andando en bici/patines/skate/pelota/trepar árboles/leer libros. Es la nueva tele.

Yo no estoy libre de pecado, de pequeño y no tanto pasé bastante tiempo jugando a los fichines o la Atari 130 XE, es que era un marginal.

Lo bueno es que aprenden a usar todo. Lo malo, es que a diferencia de los juegos de antes, ahora están conectados a Internet. Antes, cuando yo potrereaba, mis padres, tutores o encargados sabían lo que estaba haciendo pues lo habían hecho en su momento. Ahora, los niños estan "potrereando" en Internet, con adultos desconocidos ("no hables con extraños, no te subas al auto de un desconocido" -> "no chatees con extraños") y sus padres, tutores o encargados no tienen ni la menor idea, incluso hay algunos que ni siquiera potrerearon en el mundo real porque estaban mirando tele.

Negar todo


Lo segundo más fácil, mi impulso natural coherente con que el uso de mobile por menores en mi hogar despierta mi lado más paranóico, a tal punto que los aspectos educativos resultan perjudicados.

Ese es el problema, tampoco queremos analfabetos informáticos.

Un escenario común es "¿Podemos poner música?". Claro, siempre pueden y terminan mirando videos y de ahí está a un click jugar y es más fácil negar de una.

Arremangarse


Para no abandonarles en el ciberespacio ni negárselo, implantaré dos medidas: una, la del presente artículo, para reducir la interacción innecesaria con Internet y la otra, a futuro y en otra nota, la segmentación de la red y su monitoreo.

Puede parecer extremo, pero no tengo ganas de ser parte de una botnet. Tampoco quiero invadir su privacidad y estar mirando lo que hacen.


Teniendo un amplio y disponible almacén musical, ni hace falta pedir permiso y es sencillo restringir por contrato el acceso.


Aprovechando una Raspberry PI Model B, una caja plástica de bombones de chocolate, una adaptador usb/pata, un disco ide, un torno de mano, bastantes cds de música con sus correspondientes backups ripeados, es sólo pensar y trabajar un ratito para tener algo que permita escuchar música de algún modo.


No voy a entrar en detalles tipo instructables, pues las probabilidades de que tengas el mismo hardware que yo son bajísimas. Sólo mencionaré tips, recomendaciones y errores cometidos. Además asumo un conocimiento intermedio de administración linux, el objetivo de todo esto es estimular ideas para que te armes lo tuyo con lo que tengas.


Caminos no tomados


Quería aprovechar una SD Card de 2 GB, donde ya antes había instalado una distro para las pruebas con w3af [], pero el esfuerzo de achicar alguna distro para que entre, aunque traería aparejado un brutal incremento de conocimiento, excede el alcance y tiempo de este proyecto, al punto que es más barato comprar SD del tamaño necesario, 8 GB.

Instalar una distro específica de media center que hubiese permitido instarlar en tan sólo 1 GB estuvo considerado, pero tenía que aprender cosas específicas, mejor invertirlo en conocimiento genérico.


Detalles


La idea más completa es esta, pero no implementé todo:

+--------------+         +-------+       +--------+
| Amplificador <--audio--< RBpi  <-------> mpc    |
+------^-------+         | Music |       | ncmpc  |
       |                 | Player|       | android|
       +----------IR-----< Daemon|       +--------+
                         +-^---v-+       

                           |   |           +--------+  
  +------------------------v-+ \-streaming-> http   |
  |smb/sftp/rsync/nfs/webdav |             | client |
  +--------------------------+             +--------+
                                          


Gabinete


Esto es probablemente lo más interesante de esta entrada.

Al cortar el plástico hay que usar una velocidad mas bien baja y no cortar por mucho tiempo, ya que el plástico se calienta, derrite y pega a la herramienta. La década perdida, o más bien, las tres décadas perdidas es no haber tenido antes un dremel, ¡qué lo parió!










Es recomendable pensar bien como van los componentes. Yo me equivoqué con el conector de audio, pues cuando armé el gabinete no había terminado de pensar como lo iba a usar y así fue como tuve que usar un conector de audio a 90° y además tener que sacar la RBpi para poder conectarlo y desconectarlo.

Mas o menos lo pensé en función de los cables y la circulación de aire.



Administración general


Lo más cómodo me ha resultdo ssh -X, que me permite abrir synaptic para instalar lo que necesite. Sólo hace falta conectar a kvm en el primer arranque para configurar la red.



Temperatura

En invierno no hay problemas, pero en verano se puede complicar. El único termómetro disponible es el del disco rígido, pero sensors-detect no lo vé. Mala suerte.



Real Time Clock

Raspberry PI no tiene batería ni RTC, así que hay que configurar correctamente NTP, lo cual parece ok, sólo porque la configuración de la red permite que ChocoPI acceda a Internet. Mmmm, veremos.

Hay que configurar correctamente la TimeZone, ntp viene activo por default.


Green Energy

La mayor parte del tiempo esta máquina está en vano, pero no quiero que se esté prendiendo y apagando. De hecho tiene una RBPI para que tenga bajo consumo. El disco sí me interesaría que se apague cuando sé que va a estar varias horas si uso. Eso se hace con hdparm, pero me complica la vida tanto como prender y apagar todo, así que, otro skip.



Power off


En teoría apagar una máquina debería ser de las cosas mas sencillas, ¿no? Para los que no recuerdan o no estuvieron, hubo un tiempo en el cual había que "aparcar" los cabezales de los discos rígidos antes de apagarlos para evitar que pegaran contra las superficies. Tambien eran los tiempos en que para apagar lo único que había que hacer era... apagar. Ahora hay que avisarle al sistema operativo. Más que avisarle hay que pedirle.

Con este modelo nos quedamos con lo peor de las dos épocas: hay que pedirle al sistema operativo para que apague la RBPI y hay que apagar la fuente a mano, pues el disco rígido está conectado directamente a la fuente.

Aprovechando la capacidad de I/O de la RBPI habría que poner un relé o similar y algún circuitito, pero como la idea es que esté siempre prendida, tiene muy baja prioridad.


Control del amplificador


Uno de estos días, aprovechando los pines de la RBpi, no sé cómo, voy a controlar el amplificador via el remoto infrarojo.

Storage

Primero hay que descubrir dónde aparece el disco

[dmesg]
[    7.223291] scsi 0:0:0:0: Direct-Access     XXX XXXXX          PQ: 0 ANSI: 0
[    7.248541] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[    7.278569] sd 0:0:0:0: [sda] Write Protect is off
[    7.302157] sd 0:0:0:0: [sda] Mode Sense: 33 00 00 00
[    7.365556] sd 0:0:0:0: [sda] Attached SCSI disk


Luego particionarlo con fdisk, formatearlo con mkfs

sudo mkfs.ext4 /dev/sda1

actualizar fstab para que se automonte:


[/etc/fstab]
/dev/sda1       /mnt            ext4    rw,relatime,data=ordered 0 0

y por último copiarle la data, como mas te guste.

MPD

Es el programa que ejecuta los temas con una interfaz remota.

Puse todos sus archivos en el disco usb, /var/lib/mpd a la par de la música y ajusté acorde a la configuración. Ahí también va el streaming.



[/etc/mpd.conf]
music_directory     "/mnt/musica/"
playlist_directory  "/mnt/mpd/playlists"
db_file             "/mnt/mpd/tag_cache"
log_file            "/mnt/mpd/mpd.log"
pid_file            "/run/mpd/pid"
state_file          "/mnt/mpd/state"
sticker_file        "/mnt/mpd/sticker.sql"
user                "mpd"
audio_output {
    type            "alsa"
    name            "My ALSA Device"
}
audio_output {   
    type            "httpd"   
    name            "My HTTP Stream"
    encoder         "lame"    port        "8000"
    bitrate         "128"

    format          "44100:16:1"
}
filesystem_charset  "UTF-8"




File Sharing

Teniendo sshd, ya tenemos SFTP. Cuando tenga tiempo, ganas y necesidad, configuraré smb y nfs de algún modo relativamente seguro.


Sincronización


En mi master de audio, cada tanto ejecuto rsync. El sentido de la confianza indica que no pueda hacer pull desde ChocoPI, en quien confío menos que mi master. No olvidés ejecutar mpd update tras cualquier cambio.

Extensión para FF


Minion, en mi caso no toma el servidor asi que hay que

about:config -> extensions.mpm.server -> ip:port

pero no hay manera de decirle la contraseña.

Metadata


Al igual que cualquier otro player, toma la metadata del archivo, no le interesan los nombres de los archivos o las carpetas contenedoras, lo cual a mi me rompe mucho los pies, pues tengo un esquema muy sencillo:

letra
   nombre.grupo
      año - nombre album
         número - nombre tema

Lo cual no se lleva muy bien con compilados, disc1 y disc2,  ni música clásica.

Si la vida fuera fácil:

ls -1 "$1" | while read interprete; do
  ls -1 "$1/$interprete" | while read disco ; do
    anio=$(echo $disco | cut -d"-" -f 1)
    eldisco=$(echo $disco | cut -d"-" -f 2-)
    ls -1 "$1/$interprete/$disco" | while read tema; do
      pos=$(echo $tema | cut -d"-" -f 1)
      eltema=$(echo $tema | cut -d"-" -f 2)
        id3tool \

          --set-title="$eltema" \
          --set-album="$eldisco" \
          --set-artist="$interprete" \
          --set-year="$anio" \ 
          --set-track="$pos" \
          "$1/$interprete/$disco/$tema"
    done
  done
done


Pero como la vida no es fácil, es otro skip...

Seguridad


Apesta, es por ello que ni me he molestado aún en configurar smb, nfs, http o webdav. MPD tiene passwords, pero, wireshark dice que


OK MPD 0.19.0
status
ACK [4@0] {status} you don't have permission for "status"
password "password"
OK
status
volume: 85
repeat: 0
random: 0
single: 0
consume: 0
playlist: 2
playlistlength: 9
mixrampdb: 0.000000
state: stop
song: 0
songid: 1
nextsong: 1
nextsongid: 2
OK



No hay manera sencilla de corregir esto

 

Links útiles


http://www.musicpd.org/clients/ncmpc/

https://wiki.archlinux.org/index.php/Music_Player_Daemon/Tips_and_tricks

http://www.suntimebox.com/raspberry-pi-tutorial-course/week-3/day-5/

http://daker.me/2014/10/how-to-fix-perl-warning-setting-locale-failed-in-raspbian.html

http://www.musicpd.org/doc/user/

http://mpd.wikia.com/wiki/Music_Player_Daemon_Security

sábado, 7 de noviembre de 2015

Solución definitiva a la comunicación segura

El otro día en la eko11 me hice nuevos amigos, como Iván @HacKanCuBa, aunque quizás ya lo conocía de antes, pero bueno, es el problema de tener sólo 64 Kb (https://twitter.com/dev4sec/status/660485176691138560). Hablábamos de temas que no vienen al caso cuando surgió un interesante spin off, relacionado a mensajería segura.

Por supuesto no recuerdo todos los detalles ni el orden ni quién dijo qué, asi que me tomaré algunas libertades con el relato, eliminaré las personas, agregaré docenas de detalles asumidos durante la conversación y pasaré a modo "ensayo" o "charla magistral". Prometí escribir esto en diez minutos, así que quizás hayan algunas inexactitudes, reclama y señala, por favor. Faltando a mi costumbre no he puesto citas que respalden lo que digo, muchas ideas son suposiciones.

En la actualidad la manera menos insegura de comunicación remota es mediante cartas en papel


Todo mensaje es eventualmente interceptable, sobre todo en el caso de las computadoras, dado el control existente sobre los nodos y canales. Esto incluye mail, foros, sms, chat, p2p, conversaciones telefónicas, lo que quieras.

Existen técnicas para ocultar el árbol en el bosque que cuentan con que el adversario no reconozca a un mensaje como tal. El problema es que si tiene todos los mensajes, en algún momento podría reparar en que algo se le ha pasado y revisar los mensajes viejos.

Como el almacenamiento no es gratis y tus mensajes ocupan lugar junto al de muchos otros objetivos, es importante lograr que los mensajes no sean reconocidos y sean descartados.

En apoyo a este punto se había dicho, creo que Snowden, que la inteligencia británica conserva durante unos pocos días todo el tráfico que logra ver de todo el mundo, implicando que luego buena parte se descarta. El criterio de descartar seguramente tiene que ver con que los mensajes califiquen y podemos imaginar que puede darle valor a un mensaje:
  • origen y destino, ya sea persona, cuenta, dominio o ip.
  • palabras claves
  • que no haya podido ser descifrado
  • correlación con otros eventos (supongo que por las dudas se conservan todos los mensajes N tiempo antes y despues de algún hecho importante de la realidad)


Para optimizar, probablemente se usen agentes recolectores en los blancos como finfisher, que tienen la ventaja de preseleccionar lo de interés.

Luego está el cibercrimen. Si tu máquina que ha pasado desapercibida para un organismo de inteligencia es víctima de malware común, quizás una mafia de Europa oriental esté recibiendo información a la que no dará valor, pero si sus servidores son capturados por las fuerzas del orden, ellos sabrán reconocerlo.

Y siempre queda el análisis forense, la capacidad de recuperar información pasada y supuestamente descartada analizando la memoria y disco de tu máquina.


De todo esto, para mí, lo fundamental es separar tu identidad real de la virtual, lo cual es muy difícil:


  • no debe haber relación por ips, mac address de wifi o bluetooth, cuentas de mail o social media
  • no debe tener un patrón de tráfico (horas, ubicaciones) similar
  • no debe tener una red de contactos similar 

En varias entradas ya he opinado al respecto, quizás debería reescribirlas de modo más coherente y actualizado. Va PostIt al backlog. 


Como dijo Gera en ekoXX, no recuerdo cuál, "Facebook me conoce aunque no tenga cuenta en Facebook, por todos los que me han invitado a unirme"


El correo común es mucho más difícil de interceptar por que no es automatizable. Hay que elegir cuales cartas evaluar, para lo cual rige bastante todo lo del análisis de tráfico ya mencionado. 

Luego hay que ver dentro de cada carta. De esto no sé nada, aparte de que se pueden abrir y volver a cerrar las cartas con vapor y me han dicho que se puede examinarlas sin abrirlas con un tomógrafo, lo cual debe ser bastante carito.

Se puede utilizar papel fotográfico sin revelar, de modo tal que si alguien expone la carta esta se arruina. El problema es que hace falta equipo especial y es más pesado el papel, comienza a destacar por encima del resto, no lo que queríamos.

Se puede usar tinta invisible, pero supongo que con un tomógrafo o similar es legible.

Y no estoy considerando en detalle el objetivo por parte del adversario de ver nuestra carta y que nos llegue sin que sepamos que ha sido interceptada.

El problema restante es que una vez que el adversario se ha hecho de nuestro mensaje, lo puede leer. Hace falta cifrarlo y aquí perdimos, pues cualquier cifrado que no esté hecho por una computadora es rompible por una computadora, por mera fuerza. Aunque estés un año haciendo cuentas para cada mensaje, igual la computadora te lo va a romper en segundos.

Volviendo a la conversación con Iván, pensamos en cifrar, imprimir, enviar por carta, scanear, OCR, descifrar. Con esto combinamos la capacidad de cifrar de las computadoras sin darles la ventaja del control sobre los canales de comunicaciones.

Y hemos vuelto a que estamos usando computadoras, blanco de análisis forense, emisiones electromágneticas y demases.

Si no fuera por la solución a la que arribamos posteriormente, es con lo que me quedaría. Obviamente con computadoras a las que le quitamos la capacidad de comunicación y almacenamiento y las usamos sólo para eso, probablemente arrancando de dvd, sin persistir nada, con impresoras básicas sin pooles. Quizás se podría reformular una impresora multifunción, va PostIt a backlog pero no el mío, jaja.



La solución definitiva


Finalmente, deseperados, arribamos a la solución definitiva, que usa papel, los mensajes son ilegibles y no usa computadoras: utilizar médicos que escriban nuestros mensajes y farmaceúticos que los lean.

Si queremos duplex necesitamos un médico y un farmaceútico en cada nodo, claro.


Los mensajes deben ser breves, tantas recetas podrían llamar la atención.

Cualquiera podría cuestionar que el adversario puede tener farmaceúticos. Si, seguro, pero nosotros ya tendriamos a los mejores, los que no necesitan preguntarle al paciente nada para terminar de interpretar la receta. No deben haber tantos.





viernes, 23 de octubre de 2015

Eko 11 dia 3


Puff, pensé que no llegaba...

OSQuery de Facebook

Suena interesante, poder hacer select * from process where TTY="tty4"; en lugar de ps ax | egrep -e '^..... tty4'

Pero que te digan vengan y ayuden, no sé, me agarra cosita. Una cosa es que me lo pida un par o parecido, pero una empresa grande... Tanto a Infobyte y a Securetia que gentilmente me han dado acceso a Faraday y a Karma repectivamente, no he tenido problema en darle mi modesto y superficial aporte sin que me lo pidieran, pero Facebook es FACEBOOK, miles de millones de verdes y me pedís que te regale trabajo, ufff, soy open source pero no tanto.

No sé como resolver esto.

Aparte.

Si no hubiese asistido al training, no hubiese entendido nada de Windows SMEP bypass. No sé por qué no le dieron el premio de trayectoria a Nicolás @NicoEconomou. Espero se lo den en #eko12.

Muy buena Crozono de Sheila @UnaPibaGeek y Pablo @pabloromanos, mucho más sofisticado y limpio que mi plan: tirar un corcho atado con una tanza por el inodoro, ir a la cloaca a buscarlo y meter un cable ethernet con POE.

A raiz de que varios de mis compañeritos más observadores y babosos me han dicho que este año ha habido mayor presencia femenina, yo me pregunto, ¿no sería correcto brindar algún tipo de ayuda? A todos nos cuesta venir, no sé si a las mujeres no madres más, pero seguro que a las madres sí. De todos modos, una mujer que aún no ha tenido familia debería ser ayudada a asistir, para que esté mejor insertada para cuando tenga familia.

Adémas muchas mujeres pierden un día por mes por los dolores menstruales. Puede parecer una boludez, pero es una desventaja.

Tambien el viajar en horarios extremos. Yo me vuelvo en colectivo a la hora y del lugar que sea por 4 pé o menos, si lo hiciera en taxi, son más de 70 pé fácil.

Y ni hablar de que si hay una sola por cada cien hombres... debe ser estresante sentir doscientos ojos en el trasero...


Temo sin embargo que se confunda con lo que hacen (o hacian, ha pasado tanto tiempo...) en los boliches, estoy completamente en desacuerdo con el concepto de "Damas Gratis".

No me gustó que mercado libre tuviera promotoras, no me gusta que hayan promotoras y eso que este año los animalitos estuvieron bastante educados cuando ellas subieron al escenario, todo un mérito pues estaban muy bonitas, casi que a mi tambien me dieron ganas de gritarles algo, jaja.



Perdón que esté tan sensible. Si eres mujer y te molesta lo que escribo, considerá que puedo estar mal expresándome y tambien echale una ojeada a http://kyliechan.com/the-accidental-sexist/

Aparte.

Una pena que se haya cancelado lo de "Why app stores cannot be trusted: ROP as a Service", espero que alguien cuente algo, en archive.org no quedó.

En reemplazo de esta charla hubo un espacio de fast/lightning talks que con Javier @jjvmARaprovechamos para difundir el próximo Agile Open Seguridad.

PATCH: para todos los que no son de CABA Argentina, nos faltó decir que cuenten con nosotros si necesitan asesoramiento para organizar un evento de este tipo por vuestros pagos.

PATCH: para la organización de la Eko, cuenten con nosotros para asesorar y/o facilitar un día de Open Space en la Eko12. Esto es tanto un ofrecimiento como un pedido o sugerencia.


Antes, cuando estaba juntando valor y ánimo, había hablado con Andres @w3af, que ha venido a algún AOS. Lo que me dijo con una crudeza que me gustaría que mucha más gente empleara fue: "El formato me gustó, pero la asistencia tenía un nivel bajo, yo no volvería y los que fueran de acá no volverían tampoco" (más o menos, no lo grabé).

Y tiene razón, si no logramos en alguna oportunidad llegar a la masa crítica tanto de cantidad de asistentes, que supongo que debería ser el doble de lo normal, como en una mayor proporción de gente con conocimiento, seguiremos reptando.

Aparte

Fuí testigo de la solidaridad de @sysarmy para con Joaquín @_joac, junto a quien estuve por casualidad sentado un buen rato y siendo quien soy ni me dí cuenta quien era, prometo cambiar. Fijate que estoy poniendo los twiters y me estoy armando un txt con nombres y otros datos y de muchos de ustedes ya tengo la foto y voy a estudiar antes de cualquier evento para poder saludar correctamente a cada uno. De paso practico socint.

De conjunto ha sido una muy buena experiencia, claro que nunca superará a la primera a la que fuí (eko8), más que estaba Nitroman. Saludos y gracias a los organizadores que no hallé en persona y hasta #eko12.



jueves, 22 de octubre de 2015

Eko 11 dia 2

Esto viene mejorando. Salvo la primera vez, que por ser la primera vez todo te parece novedad, nunca había asistido a tantas charlas. Las que no menciono es por que nada puedo agregar o no me llamaron la atención con algo para compartir.

Contra vot.ar Iván y Javier le dieron palos al voto electrónico en general y al sistema utilizado en particular.

Aunque no lo dijeron así, la cosa es como discutir teología con un ateo. El punto esencial es que no hay transparencia, aunque el sistema sea perfecto. Desde el momento en que hay que explicarle a alguien algo más que "tomás tu boleta y la ponés en la urna" el sistema no es transparente.

No puede ser que haya que llamar a un técnico para certificar. Es algo tipo los problemas de Zero-knowledge proof[1]. Una persona puede comprobar que algo es cierto pero esa comprobación no sirve para otra persona. Cada persona debe comprobarlo por si misma. Con boleta y urna es factible, sólo alguien con serias limitaciones mentales no lo entendería. Con una computadora de por medio, sólo alguien con serias limitaciones mentales puede pretender que un sector significativo de la población lo entienda.

Algo que no se mencionó es que la lectoras probablemente sean grabadoras, lo cual es un canal de salida de información. Algo frente a lo que se detuvieron es el microcontrolador que hay para la rfid e impresora (y quizás pantalla). Ellos consideraron que bien puede estar protegido para que no se pueda leer (o sea auditar). Pero si le sacaras esa protección, si obtuvieras una urna podrías reprogramarlo y posibilitar persistencia o alguna emisión radioeléctrica tal que se pueda vulnerar el secreto de voto.


Luego Manuel y Francisco mostraron como emular parcialmente una celda telefónica con equipamiento accesible en precio. Quizás un poco caro para jugar pero interesante para pruebas de ingeniería social.

En varias de las de más bajo nivel y es algo que ocurre no sólo acá, los expositores no son generosos, asumen que están hablando con pares con conocimiento similares.

No sé si está mal, hace a exposiciones más cortas, pero supongo que deben haber muy pocos asistentes que realmente entiendan todo. Igual, sirven, al menos yo siempre saco algún pensamiento nuevo, una idea, algo.


Jaime de hacking carros me ha abierto el entretenido e interesante panorama potencial de inyectar conversaciones en algunos vehículos.

Lamentablemente me perdí el comienzo de el de fraude de empresas de comunicaciones entre ellas mismas, a los clientes y a los estados, que ni siquiera sabía que existía.

Finalmente Juliano mostró un tipo de vulnerabilidad que no sé porqué no conocía con ese nombre SSRF (Server Side Request Forgery). Estuvo bueno que durante un rato fallara, al repetir se hizo mas claro el ataque.

Impresionante el esfuerzo organizativo de Jerónimo que según entendí le consiguió el equipamiento vulnerable en muy poco tiempo. Al punto que Juliano hoy confirmó la vulnerabilidad y la reportó.

Con respecto al desafío de lockpicking, ni me acerqué, Juani me contó ayer que era de un nivel de dificultad comparable al CTF y la verdad es que me pagaron la entrada y training y en horario de trabajo, más me vale que le saque lo máximo.


En un plano muy íntimo, me siento muy disminuido, como que hay ciertas actividades mostradas en las charlas que son cosas que si a uno (al menos a mí) se me hubiesen ocurrido, las hubiera podido hacer, por ejemplo lo de vot.ar. El problema es que en el día a día hay que ir priorizando en incluso el descansar y no hacer nada por momentos puede tomar un valor muy alto.

No es que no haya hecho nada nunca, estoy muy contento con las charlas y demos que he dado, incluso con la de OWASP en la que se me borró de la mente una parte, con el poco código que he compartido, pero eso ya ocurrió, como que hay que generar permanentemente nuevas cosas.

Envidio (en el buen sentido) mucho a quienes exponen.

Y es cada vez más difícil, la comunidad agile la veo decaida en sus actividades, mas bien faraónicas una o dos veces por año y más bien alejándose de los aspectos técnicos, el grupo de seguridad-agile parece que hibernara. No sé, mejor me voy a hacer noni.


PD: pongo nombres de pila sin apellidos porque si no me suena como muy formal. Esos nombres estan en el programa (salvo Juani) y no me cabe poner "alguien", "el otro".

[1] https://en.wikipedia.org/wiki/Zero-knowledge_proof


miércoles, 21 de octubre de 2015

Eko 11 día 1

Aproveché la espera en la entrada para escribir lo de ayer que me había olvidado y justo cuando escribía esta mismísima linea escuché:

-¡Qué HDP's, cambiaron a las 11!

Lo que me preocupa es que justo estaba ayer leyendo en "El Chino" de  Henning Mankell (te juro que lo tenía de antes que se muriese) la parte en que cuenta de una persona que hace esperar a propósito a las otras, más tiempo según decrece su importancia.

En realidad no me preocupa, estoy convencido de que es mero desorden. Es una lástima que no hayan aceptado mi propuesta de hacer Open Space como relleno para esta situación, lo volveré a proponer el año próximo.

Algún gracioso puso un pasacalles en la puerta que decía "Volvé Katz, no te pwneo más". Él, ni lento ni perezoso envió un micro desde Paraguay y lo puso en la puerta para taparlo.

No voy a poner foto, pues además de parecerme una crueldad innecesaria, ya lo deben haber twiteado centenares de veces.



Se vió también presencia de ISSA en una esquina cercana (https://www.issa.org/)



Vampii de 2600/sysarmy/* me confirmó lo que había oido en alguna ocasión acerca de que telecom probó la centrales telefónicas digitales acá antes de instalarlas en Francia aportando que fué por el alto fraude que había por estos pagos. Esto me lleva a que lo que no te mata endurece y ahí termina,  iba a reflexionar sobre los ataques por mérito o diversión que sólo sirven para que los afectados mejoren su defensa.

De las charlas, que estuvieron muy amenas (winter is coming, arm disassembly) no puedo aportar nada. Del panel de voto electrónico llegan a lo mismo de siempre con lo cual concuerdo[1]: la falta de transparencia y el escenario del puntero que le dice a quien le compra el voto que lo puede controlar, sea cierto o no.

Cabe destacar la posición del partido de la red, pero no voy a opinar mucho por que esto es de tecnología, no de política. Confirma mi idea de que la mayoria somos más o menos igual de inteligentes, pero se manifiesta de distintas maneras, de modo tal que si la tenés muy clara en tecnología probablemente en el resto seas un cuatro de copas.


[1] http://seguridad-agile.blogspot.com/2015/08/agile-boleta.html

Ekoparty 11 Training

Perdón, no sé qué pasó ayer que me olvidé de hacer esta entrada, debe haber sido que el training al que asistí me consumió el cerebro.



Originalmente y más cuando ví que estaban con el protoboard y el soldador lamenté no haber asistido al de hardware, pero no calza bien con mi perfil en el trabajo, este de vulnerabilidades es más compatible.

Pronto dejé de lamentarlo.

Los muchachos a cargo de reemplazar a la persona original que no pudo asistir por una penosa situación personal, son muy rústicos desde el punto de vista didáctico, pero su impresionante conocimiento compensó holgadamente.

Se notó el reemplazo en algún ejercicio que no lo tenía preparado y tuvieron que investigar en el momento, eso fue muy arriesgado, pudieron no haber llegado a la solución, pero el haber visto como lo encaraban hasta llegar al resultado fue realmente impresionante. El la diferencia entre una demo y un ppt.

Algo que no puedo cuestionar pues es muy íntimo mío es que me por un momento me dió la sensación que tuve cuando cursé CCNA: si me hubiese asociado con dos personas más, por la misma plata nos comprábamos un libro,  tres routers y en menos tiempo aprendíamos lo mismo y nos quedában los routers.

En este caso no es resultó igual, ya que a diferencia de antes, ahora no tengo el tiempo disponible para semejante proyecto. Según nos contaron, lo que vimos en dos días ellos lo vieron en el trabajo en dos semanas.

Así que esa sensación sólo fué pasajera, tuve dos o tres momentos de (ah, no me acuerdo de la palabra y me niego a buscarla) que difícilmente hubiera logrado solo.

Los temas vistos... están en la descripción del curso. En conclusión, alcanzó y superó mis expectativas.


miércoles, 23 de septiembre de 2015

Por qué no biometría - redux

A partir de noticias como [1] e intensos momento de reflexión seguidos de cursar Computer Science and Privacy[2], he llegado a la conclusión de que lo que había expuesto en [3], aunque esencialmente correcto, no está correctamente encarado. Además, esta reciente noticia [4] que cuenta que han sido obtenidas 5.5 millones de huellas dactilares tornan las profecías apocalípticas de quienes estamos encontra de la biometría en inminente realidad.

Que vamos hacia una pesadilla Orweliana no hay duda [5]. Que sea inevitable o no, trasciende los alcances de mis humildes cavilaciones técnicas.

Se suelen poner juntitos Autenticación, Autorización y No Repudio como carácterísticas del acceso a la Información, repasando:

Autenticación es la verificación de que sos quien decís ser.

Autorización es lo que podés hacer.

No Repudio es que no puedas negar lo que hiciste.

Y falta algo implícito, la Identificación. Yo me Identifico y luego me Autentico y según mis Autorizaciones afecto la Confidencialidad, Integridad y Disponibilidad de la Información sin poder Repudiar mis actos.

Como no estoy seguro de que mi Autenticación sea legítima, hay Múltiples Factores de Autenticación: lo que sé, lo que soy, lo que tengo.

Lo que sé es un Secreto y suele ser una clave.

Lo que tengo es algo, por ejemplo una tarjeta de coordenadas o un SMS OTP. Mejor dicho una linea de teléfono celular por la que recibo en el celular una clave de uso único y corta vida.

Este mecanismo es muy endeble, basta una sencilla apk maliciosa que tome el SMS y lo retransmita al atacante para que no sea "lo que tengo".

Siempre he cuestionado que lo que sé, si está escrito en un papel, es lo que tengo. Si pudiera memorizar la tarjeta de coordenadas, pasa a ser lo que sé. Yo no puedo, pero hay mucha gente que si. Yo puedo memorizar algunas contraseñas complicadas, la mayor parte de la gente no o no tiene el interés en hacerlo.

Lo que soy es... el huevo y la gallina. Es mi Identidad, que fue con lo que empezamos. Mis factores biométricos son lo que soy.


Mi error es que la biometria tiene que ver con la Identificación, no con la Autenticación como lo enfoqué en la otra entrada del... 2013!!! cómo pasa el tiempo!!![6].

¿Y qué pasa si tengo motivos legítimos para tener dos identidades en un mismo contexto? Si mi factor biométrico es la Identidad, no puedo, mmmh.

Dado que es relativamente sencillo "extraviar" lo que soy, la única solución que veo, ya que vamos a perder, es que se use la biometría como Identificación con una clave para la Autenticación. Una huella digital no implica VOLUNTAD, el ingreso de contraseñas si.

Algunos sistemas de alarmas aceptan una contraseña que aunque "desactiva", avisa que la persona ha sido forzada. Los factores biométricos no ofrecen esta funcionalidad.

De todos modos el escenario sigue siendo "dame la clave (Autenticación) o te corto los dedos y luego te los corto igual (Identificación)".

Volviendo a la noticia que me impulsó a finalmente publicar esto, ¿qué va a pasar cuando se pierdan, vendan como usados o se den de baja esos lectores que hay en las puertas? ¿Y los discos donde se almacenan? ¿Y los backups? Nuestros factores biométricos de Identificación o Autenticación van a ser más que públicos. Va a ser como ingresar a un sistema con el DNI como clave.


[1] http://americans.org/2015/07/ 03/mastercard-to-start- verifying-payments-via- selfies/
[2] http://www.dc.uba.ar/events/eci/2015/cursos/prost
[3] http://seguridad-agile.blogspot.com/2013/11/por-que-no-biometria.html
[4] https://www.washingtonpost.com/news/the-switch/wp/2015/09/23/opm-now-says-more-than-five-million-fingerprints-compromised-in-breaches/
[5] http://www.itworld.com/ article/2832804/it-management/ attention-shoppers--retailers- can-now-track-you-across-the- mall.html
[6] http://seguridad-agile.blogspot.com/2013/11/por-que-no-biometria.html

sábado, 8 de agosto de 2015

Agile Boleta

Un éxito completo, 66% de asistencia de los inscriptos, que podríamos llevar a 80% si consideramos que uno de los inscriptos avisó varios días antes que no iba a asistir.

Todo esto relativizado a que asistimos cinco.

Pese a esta introducción engañosamente desalentadora, el encuentro fue más rico de lo que podiamos esperar de los presentes, ya que ninguno tenía algún conocimiento extraordinario del tema, pero al tener distintos puntos de vista y experiencias relacionados con las elecciónes (uno había sido en otra ocasión presidente de mesa) y las vulnerabilidades en general, logramos un buen intercambio.

Por supuesto en algún momento terminamos hablando de la vedette en la cabina del avión[1], espero que no sea el nuevo Hitler[2].


Lo que a continuación transcribo, es el resultado de mi opinión amalgamada con lo conversado, no es un registro fiel.

Voto vs Boleta


Hay que distinguir entre "voto electronico" y "boleta electrónica". Lo primero es la utilización de una aplicación para registrar el voto y podría incluso ser online. Lo que hemos vivido es lo segundo, el reemplazo de la boleta previamente impresa por una que se imprime en el momento más los adicionales optativos de contéo automático y la transmisión.

Las vulnerabilidades de la transmisión de los resultados.

Esta fue una de nuestras dudas no resueltas, si se contemplaba como parte del sistema la transmisión de los resultados por Internet.

Las vulnerabilidades asociadas al chip.

Si los chips utilizados son como los del conocido sistema de pago de transportes, una clave se obtiene en una horas[3] y el resto en minutos[4]. Alguien había entendido que sólo se podían grabar una vez.

Las medidas de represalia tomadas contra los investigadores.

¿Se puede considerar que por tratarse de un acto electoral las vulnerabilidades deban ser tratados de un modo distinto al de cualquier otro sistema?

Estuvimos todos de acuerdo en que fue una acción política (en el sentido que se le dá en el trabajo, como cuestión de poder, de bandos) más que de índole legal.

El proceso fue más eficiente.

Nuestro asistente que fue presidente de mesa en otra elección ha dado fé que hay gente que tarda un tiempo absolutamente injustificable en el cuarto oscuro. Suponemos que se debe a algún tipo de acto de auto satisfacción sexual, pues ahora esta vez todo parece haber sido más rápido.

Otra ventaja es que no había posibilidad de equivocarse, como lo ocurrió a alguno de los asistentes que en una oportunidad impugnó involuntariamente su voto al hacer mal los cortes de boleta.


La transparencia de este método frente al tradicional.

Como bien dijo Vampii en la lista de la eko, el proceso tradicional es extremadamente sencillo, cualquiera puede comprenderlo. Habiendo una computadora de por medio, hay mucha gente que queda afuera. El simple hecho de que quienes estábamos presentes, que tenemos una cierta cultura en informática y seguridad, no tuviéramos muy claro el asunto, además de revelar una cierta falta de responsabilidad y empeño de nuestra parte, indica que hay bastante confusión.

La transparencia de este método frente al tradicional.

Si es código para una función del Estado, ¿no debería ser este si no Open Source al menos de acceso público para su escrutinio por quien tenga el interés?

Nueva vulnerabilidad detectada

Hay un leak de información. La única manera de "impugnar" un voto es no votando ni siquiera en blanco. Se ha dicho que en realidad la impugnación no es una opción, si no un defecto del proceso tradicional.

Entendimos que para impugnar el voto ahora hace falta romper el chip o no imprimir nada. Tanto uno como otro acto es inmediatamente detectado por quienes estén presentes, así que si impugnás estás "cantando" el voto de modo involuntario.


Escenarios de ataque

Anulación de votos: según entendimos no se podía regrabar, pero si arruinar el chip de modo remoto. Con un emisor lo suficientemente potente, se puede pasar cerca de la urna y anular toda una mesa.

Fidelidad de votos comprados: se le puede decir a quien va a votar que se están monitoreando las computadoras para que que los votos comprados sean efectivamente realizados a quien los compra. Está claro que no hace falta que sea verdad, con que el vendedor de su voto lo crea, alcanza.

Descubrimiento de votos: desde el momento en que se pueden leer las boletas, con el equipamiento apropiado se puede consultar permanentemente todos los votos en la urna y revelar a quien vota cada persona, si no directamente leer a distancia en el momento de acercar la boleta a la urna. Lo que no sé bien es con que equipo pues alguien me contó que nfc-list, que funciona bien con tarjetas como SUBE, no vió un único ejemplar de origen dudoso.

Tambien está este [5]

Cómo se pudo haber hecho bien.

Considerando todo lo anterior, llegamos al acuerdo de que si se hubiera usado las máquinas como simples impresoras, se ganaba la eficiencia detectada.

Consideramos superfluos el chip y la conectividad.


En el conteo, se podía usar la computadora pero controlando que coincidiera lo del papel con lo detectado. No sabemos si el software tiene la capacidad de "corregir" errores, por ejemplo si alguien marcó varios votos, lo cual engañaría a la computadora, lo impreso igual es correcto y debería valer, no impugnar.


Haciendo los deberes

Lamentablemente ninguno de los asistentes es telépata, así que cuando se me ocurrió que teníamos que ir con el asunto bastante estudiado viendo al menos algunos links, nadie me leyó la mente.

Varias de las dudas nos las pudimos haber despejado en el momento, pero aunque el tema nos produjo el suficiente interés como para reunirnos, no fue lo suficiente como para que ninguno prendiera una computadora y se fijara en las noticias o el reglamento electoral.

Esta noticia aclara algunas: 

"Dado el diseño del sistema, el voto no se puede cargar a mano, por lo que se creó una nueva categoría: 'Voto no leído por motivos técnicos'. Para el escrutinio definitivo será tenido en cuenta, pero no en el provisorio. En elecciones ajustadas, la diferencia podría ser motivo de conflictos."[6]



Algunas reflexiones mías posteriores

A partir de lo conversado y mi propias reflexiones, en el momento en que alguno de los actores principales decide hacer fraude, no hay medida técnica que lo pueda impedir. Tiene que tener el sector afectado un aparato de fiscalización en las mesas con cobertura total. Así que toda esta discusión puede ser muy instructiva, pero a la hora de las piñas, es intrascendente.


Pensé que el error que cometió el muchacho allanado[7] fue considerar esta vulnerabilidad como un habitual problema técnico, sin considerar bien las implicancias de negocio.

El problema es que es político. No político por las elecciones sino de negocios y poder. Por definición cualquier problema con el sistema de elecciones es político pues se trata de negocios y poder. Hay bandos enfrentados con intereses opuestos. Una cosa es que la vulnerabilidad la reporte la Fundación Sadosky, que tiene respaldo y la otra es que sea un actor técnico, ingenuo e independiente, que resultará probablemente lastimado. Una situación parecida ocurriría si a alguien se le ocurriera revelar una vulnerabilidad en los sistemas del INDEC justo cuando esta bajo escrutinio.

Yo hubiera reportado de modo anónimo, pero eso implica perder el mérito, que no es poca cosa para quienes hacen actividades voluntarias.





[1] http://seguridad-agile.blogspot.com/2015/07/boxeadores-en-la-cabina-de-un-avion.html
[2] https://es.wikipedia.org/wiki/Ley_de_Godwin
[3] mfuk
[4] mfoc
[5] https://twitter.com/mis2centavos/status/622765428411121665
[6] http://www.perfil.com/politica/Detectan-problemas-de-vulnerabilidad-en-el-nuevo-sistema-de-voto-electronico-20150704-0006.html
[7] http://www.clarin.com/policiales/Voto-electronico-allanaron-domicilio-irregularidades_0_1387661308.html

miércoles, 15 de julio de 2015

Boxeadores en la cabina de un avión



No se si es leyenda urbana o realidad el que a los boxeadores de cierta categoría se les prohibe pelear fuera del ring, se los considera armados. Suena razonable que tenga algún tipo de restricción alguien que te puede matar de una piña.

Si es historia el caso del famoso hacker Kevin Mitnick[1] a quien se le prohibió usar computadoras y teléfonos dada su capacidad de utilizarlos para cometer delitos.

A la luz del mediático caso de la chica en la cabina, cuyo nombre no citaré dado que los abogados son muy creativos, me parece que una restricción similar se debería aplicar a ciertas personas en relación a su atractivo físico.

No sé cuantas mujeres puedan comprender realmente este punto de vista que la mayor parte de los hombres si no comprenden, al menos sufren. Lo cual no es atenuente: esos pilotos sean bastante pelotudos.

Si la invitaron a la cabina es como si hubieran provocado a Tyson, son unos insensatos suicidas.

Si ella tomo la iniciativa, se debería considerar que en las simulaciones, además de los escenarios como "fallo en motor 2", halla que agregar "entra vedette a la cabina"

Hechos como este lo más probable es que no sean inusuales[2], la diferencia es que fue durante una maniobra delicada y que quedó filmado. Ahí está la clave, la evidencia.

Echando a los pilotos lo que se gana es "no seas pelotudo, no filmés", que es un punto de vista completamente legítimo para los actos privados. Apuesto a que aunque ahora es imposible entrar a una cabina, en unos pocos meses esto pasará al olvido y volverá la normalidad.

Si los pilotos brindan capacitación, contando su experiencia, quizás se puede rescatar "no seas pelotudo, no hagas pelotudeces". Además pagarían su deuda pasando vergüenza delante de centenares de otros pilotos. Tambien hay que recordar que "los conversos son los peores" y tras semejante cagada, no tienen mucha opción, ¿no?

Me pregunto que pasaría en el caso inverso, un galancillo entrando en la cabina de una tripulación femenina.

Quizás la solución de fondo es que las tripulaciones sean mixtas.

¿Qué tiene que ver esto con Seguridad y Agile? Mmmh, se complica. La verdad es que me gustó la comparación con el boxeador y lo de la simulación, le escribí todo esto alrededor como para que no sea un twitt.

Podría rescatar que en Agile el error se suele utilizar más para aprender que para castigar, suponiendo que quien erra está en mejores condiciones de no volverlo a hacer y quienes están alrededor tienen la oportunidad de aprender de la falla sin transitarla.

[2] perdón, pero a este tipo de noticias no amerita que las documente mucho, recuerdo haber visto algo por ahí.


sábado, 11 de julio de 2015

RTFN

Para mi hay cuatro maneras principales, útiles y necesarias de documentar. Ninguna es descubrimiento mío ni tampoco es novedosa esta agrupación.


Nombres significativos en el código

Esto viene para contrarrestar la práctica iniciada con la falta de memoria, las tarjetas perforadas y la programación matemática y científica de usar letras en lugar de nombres. Esta ok usar x,y y z cuando estás hablando de coordenadas, pero no cuando deberían ser yaOrdenado, cantidadPajaros o nombre.

Esto lo he sacado del dolor de ver código ajeno o propio un tiempo despues.

xDoc (javaDoc, phpDoc, etc [1])

La vida es corta, por favor leé [2], no confundir con xDoc[3]


Intenciones y motivos

¿Por qué elegí sequential search en lugar de binary search? Pues por que se invoca dos veces en toda la ejecución y son cien elementos, no vale la pena ordenar.
El código puede ser muy claro, los nombres muy significativos, pero el propósito y los motivos es algo externo al programa o a su código fuente.

Esto lo he aprendido en un excelente curso de arquitectura de sofware en la ECI y el libro del docente que lo dictó [4]

Tests


Los test son de las mejores documentaciones, pues a diferencia de las anteriores, no se desincroniza con el código. Es común encontrar ejemplos que no se pueden ejecutar por algún motivo, pero los tests, si están funcionando, sí se pueden ejecutar, valga la redundancia.
Los tests son autodocumentación, aunque no tengan ningún comentario. Muestran exactamente como se utilizan los artefactos, que reciben y que deben devolver.


Quizás esto no cumpla con las normativas, pero si con el pragmatismo de "código funcionando antes que documentación exhaustiva" [5]


Voy a suponer que aunque no del todo de acuerdo, al menos me has comprendido.


¿Quá hay de malo en:

/**
 * Load configuration
 */
void loadConfig() {....}
?

¿Ya viste? ¿No? ¿Y ahora?

/**
 * Set date
 */
void setDate() {....}

/**
 * Get date
 */
Date getDate() {....}

/**
 * XXXX YYYY
 */
void xxxxYyyyyyy() {....}


Es esto casos es difícil defender xDoc y me frustra el haber usado "nombres significativos". ¿Para qué voy a ponerle nombre significativo y despues ponerle lo mismo en la documentación? Me recuerda esta atrocidad:

//increment cycle counter
countC++;



Propongo entonces la incorporación de un nuevo tag xDoc que sea RTFN (Read The Fucking Name)

/**
 * @RTFN
 */
void setDate() {....}

Como humanos no tenemos ninguna dificultad en entenderlo y si hiciera falta, se podría enseñar a xDoc o Doxygen a interpretarlo, cuando lo hallen que pongan en la descripción o el mismo nombre de la función o método o reemplacen según un mapa o una heurística.

El mapa puede tener nombres comunes como
[
   "setDate":"Set the date",
   "drawButton":"Draw the button"
]

Y la heurística se aprovecharía de camelCase:

setDate -> Set Date

Parece poco, pero la verdad es que poner uno esa documentación es kafkiano.

No tengo el ímpetu ni el tiempo para hacer los patches necesarios a las herramientas para poder ofrecerlas a sus desarrolladores (no es lo mismo "te propongo una idea" que "te propongo una idea y acá tenés la implementación"), pero estoy dispuesto a secundar a quien lo haga.

Gracias por las ilustraciones a Greta[6]



[4] Software Architecture: Foundations, Theory and Practice - Nenad Medvidović y otros http://www.wiley.com/WileyCDA/WileyTitle/productCd-EHEP000180.html