Archive for the 'devel' Category

30 años de MUD

Según un apunte en barrapunto, hace 30 años que se puso en funcionamiento el primer MUD. Una cosa que yo ignoraba por completo (ya veis lo ignorante que llego a ser), razón de más por la que de vez en cuando hecho un vistazo a ciertos portales para ampliar o reducir mi nivel de ignorancia.

El articulo enlazado pues tiene su punto, ya que de una forma u otra, nosotros estamos "intentando" desarrolar una pequeña aplicación, un especie de juego, sobre una plataforma completamente distribuida en una red P2P.

Obviamente no tenemos ni los recursos, ni el tiempo para hacer el proximo killer MMRPOG, pero en el nivel que estamos trabajando, realizar un MUD es algo bastante más sencillo, y no llegará ni de lejos al nivel de ciertos MUD que hay por allí. Pero al menos el famoso juego del laberinto es una base para desarollar lo que queremos.

Almlys.org -D -o Port=80

Almlys.org -D -o Port=80

Remember... ./uru_lobby -D -o Port=5000

-D -> Run in daemon mode (daemon() sys call)
-o -> Pass a configuratión option, in this case "Port", by default it was 5000.

./sd7_test_server -D -o Port 7000

A very minimal monolytic and dirty server has been running for some time, but it obiously does nothing, it only exchanges some chat messages. (Note port 7000 is still bloqued in the firewall, but that's not going to be so long, there will be server code soon in the repository)

JPype

From the JPype site:

JPype is an effort to allow python programs full access to java class libraries. This is achieved not through re-implementing Python, as Jython/JPython has done, but rather through interfacing at the native level in both Virtual Machines.

Es que era seguro que existía alguna forma, pero me preocupa mucho la eficiencia. Buf... pero almenos se me ocurren unas cuantas burradas que podrían o no llegar a funcionar...

Pecera de máquinas virtuales

Primero, recordemos esto (por si hay alguien que no lo haya visto antes)

¿Cuál es la idea? ¿Para que demonios me sirve esto? ¿Que consigo con esto?

Bueno, en este caso he montado un m0n0wall que conecta el puente donde están conectadas las máquinas virtuales con la red local, en este caso un par de windozes (versión demo de pruebas que se auto-destruye automáticamente en un par de días ;-) ) y una Ubuntu Hardy (corriendo KDE 4)

¿Que me ahorro?, pues la necesidad de tener 4 o 5 torres por allí desperdigadas, poder probar otras distros y hacer todo tipo de montajes todo lo complicados que quiera.

El día que quiera dedicarlo a cultivar virus y otros malware dentro de la red virtual no esta lejos ;-) , solo tengo que dejar un windows directamente expuesto a Internet durante unos minutos y ya esta.

O dejar un Linux expuesto, dejando un ssh abierto con una contraseña que sea trivial de descubrir, y estudiar el comportamiento de ciertos individuos dentro de una zona controlada ;-)

Bien, la pregunta del millón, ¿todo esto no va muy lento?

Pues no, antes con mi viejo PC si, pero ahora pues no. Va bastante fluido. Mientras no quieras ejecutar algo que necesite tirar de gráficos aceleradas.

Solo veo un par de problemas a mi montaje actual:

  • Virtualbox todavía no soporta invitados de 64 bits, :-( (esta en desarrollo)
  • KVM si que los soporta, pero no puedo ejecutar KVM y virtualbox a la vez, y por otro lado KVM me da muchos problemas con el audio que todavía no he llegado a solventar.
  • m0n0wall no va en VirtualBox, ya he perdido demasiado tiempo intentando averiguar que falla, pero si va en Qemu, pero obviamente Qemu es algo bastante más lento que KVM/Virtualbox (a mi parecer, a ver si uno de estos días algo una comparativa de velocidad de virtualización por software versus por hardware).
  • Enseguida te quedas sin RAM, en estos momentos la cosa esta así:
    Mem:   4063568k total,  4021548k used,    42020k free,    13680k buffers
    Esto explica porque quiero ampliar tan ansiosamente a 8GB en cuanto pueda (que es el máximo soportado por esta placa).

Y por otro lado, cuando ese montaje de flash que comenté a 32 bits bajo 64 va fatal, y cuando Java simplemente no funciona todavía a 64 bits (me esta dando muchos problemas), pues ayuda mucho poder trabajar con una MV.

Ejemplo práctico, perdí toda una mañana buscando que demonios esta pasando (excepciones nunca vistas), y reinstalando el Java de 5000 maneras. Tenia unas clases que preparar, así que no me ande con milongas, aproveché una de estas máquinas virtuales que ya tenia montadas y seguí trabajando desde allí sin ningún problema.
Por cierto ¿porqué Python no me da estos problemas, y funciona tan bien bajo 64 bits?

Fue un 10 de Febrero

Estaba escribiendo algo muy profundo que no se si verá la luz, cuando de una forma u otra me acordé del 10 de Febrero del 2004 - http://almlys.org/archives/7 , porqué casualmente coincide con otra cosa.

Era joven y tonto, ese día mi fuente de ocio principal iba a desaparecer, era injusto, y estaba enfadado. Por entonces tenia aproximadamente más de 1 Gigabyte de tráfico capturado realizando todas las posibles acciones que podías hacer en el maldito jueguecito. Tenia mucho tiempo entre manos, y la carrera por así decirlo me aburría. Y yo ya estaba con el ethereal (ahora wireshark) programando con la libreria pcab en Linux (quien es el guapo que procesa toda esa información a pelo).

La distribuidora apagaba los servidores el 10 de Febrero de 2004 por allá a la madrugada sino recuerdo mal.

Ya dije que era tonto, no sabia en el embrollo legal en el que me estaba metiendo (No tienen dinero para mantener un par de servidores en funcionamiento, pero si que tienen para asustar a un estúpido y tonto niñato).

Obviamente se hizo mucha ingeniería inversa durante las semanas antes. Y creo que realmente tuvimos mucha suerte para el nivel de estupidez que había en el ambiente.

El tráfico capturado obviamente estaba cifrado, no iba a ser fácil.

Ahora la criptoanálisis que se utilizó, pues fue realmente interesante.
Todo el bicho este, como cualquier aplicación similar usaba udp para la transmisión de mensajes. Una vez estaba montado el servidor de datos, que conocíamos como "data server", poníamos un Lobby que era un simple trozo de código C de un servidor UDP que vomitaba por pantalla en hexadecimal lo que recibía. En todo momento utilizaba dos ordenadores, uno de sobremesa con un Windows XP y el juego de marras, y un viejo portátil (que en paz descanse) con una Mandrake Linux!!! :-P (que tiempos aquellos).
Como apunte importante, el juego usaba 3 cifrados diferentes, mientras de los otros todavía no tenia ni xota de como atacarlos, me centré principalmente al mas sencillo, al del protocolo.

Bien, como me puedo enrollar para horas, explico el criptoanalisis, y si ha alguien le interesa el tema que me diga algo o que use google para buscar toda la historia completa que más o menos esta por allí en cientos de posts en un par de foros de discusión.

El criptoanalisis fue la mar de sencillo, el Linux con el servidor escuchando y vomitando los datos y por el otro lado el cliente.

El cliente para iniciar la comunicación siempre enviaba un mensaje de negocación de conexión (este no nos sirve para el critptoanalisis, aunque hay que mirar que un posible vector de ataque era la marca de tiempo que contenian estos mensajes).
Bien el siguiente mensaje era el famoso NetMsgAuthenticateHello, donde estaba el login. Debido al cifrado utilizado (que yo no lo llamaría cifrado), la cosa fue tan sencilla y estúpida como poner un par de logins diferentes y apuntar la ristra hexadecimal que vomitaba el servidor y ir comparando, hasta detectar obviamente que parte de la ristra correspondía al login, hasta que se pudo mapear uno a uno cada carácter.

De forma que descubrí, que el cifrado era una simple rotación de bits, cada byte del mensaje era rotado n bits, donde n era el resultado del la posición en el buffer módulo 8. Toma ya.

A partir de aquí pude descifrar fácilmente 1GByte de información capturada, y es cuando empiezas a ver cosas muy, muy interesantes.

Esto no fue nada, con todo el resto de trabajo de ingeniería inversa que se tubo que realizar. Recordemos que UDP no esta orientado a conexión, y no es confiable, encima de UDP teníamos que montarnos nuestra propia capa, nuestro sistema que debía permitir enviar principalmente dos tipos de mensajes, los confiables y los no confiables. De forma que se implementaba una historia similar pero muy diferente a TCP sobre UDP para poder enviar mensajes confiables (que era seguro que iban a llegar).

Ahora, como averigüé que el trasto este usaba MD5-CHAP para la autenticación, es ya otra historia.

En tercero mientras cursaba redes, con los valiosos conocimientos que adquirí pude reimplementar el núcleo teniendo en cuenta dos conceptos muy importantes, el cabal y la congestión. Y aplicar y experimentar con algunos de los algoritmos de retransmisión. (Cuando alguien me pregunta porqué no quise hacer el TFC de Sistemas, aprovechando este trabajo, le doy la razón diciéndole que era porque era estúpido, joven y tonto, y que no queria complicarme)

En total fue una experiencia muy rica, algo legalmente arriesgada, aprendí mucho y aunque por aquella época yo estaba más o menos bien, me suicidé socialmente. De forma que no os lo recomiendo. Sobretodo porqué es muy difícil, por no decir "imposible" recuperarse de un suicido social como el mio. Y en estos momentos puedo decir que sigo siendo el mismo ser asocial y amargado de siempre.

Para que conste, el código

Apunte extra: Curiosamente la 2a encarnación a la cual no participé, cerró definitivamente el pasado 10 de Abril.

About the recent lack off English posts

When I started this blog, my intention was to write in the 3 languages that I know, and soon with a bit of luck I will start to study French over the next year (also I need to do an English recycling crash course). There is a small problem with that, and is that I don't have enough time to translate, so I'm contemplating some sort of possible solution, that will use automated translation. If you are already using it, you will not see any difference.

I have visitors from everywhere, so pleasing them all it's a bit difficult.

From the Spanish posts, you may have reached the conclusion that I have been having some personal problems, and well, It was a bit prioritary to me, to take care of myself first, think about everything that I have done with my life, and what I want, or what I can achieve, because the only thing that I want in this world is not possible, everything else is secundary.

Now about 7d7, there is a change in the planning since I'm on a rush. I will not support 64bits versions for now, also I cannot support windoze versions. The code is temporary stopped, because I'm working on the memory of the project, because I could writte a lot of code, but I would never have the darn document and that thing is very important, more than the code.

If for some causality the director(s) of my project is/are reading this (hello!), I'm sorry for not sending any update during the last weeks, this Friday/Monday you will hopefully receive an e-mail with part of this document.

Oups, I also need to reduce the time that I spend on this blog :-O!!

PD: There will be material in English in the future, also material of User Mode Linux in catalan and spanish, but it's not finished yet!, sorry!

Alcugs Project Repository SLOC

Totals grouped by language (dominant language first):
python:      157698 (47.05%)
cpp:         143207 (42.72%)
java:         16235 (4.84%)
cs:            7186 (2.14%)
sh:            5007 (1.49%)
php:           4255 (1.27%)
ansic:         1602 (0.48%)

Total Physical Source Lines of Code (SLOC)                = 335,190
Development Effort Estimate, Person-Years (Person-Months) = 84.64 (1,015.70)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 2.16 (25.97)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Total Estimated Cost to Develop                           = $ 11,433,895
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'.

Ahora ya me puedo pegar ese trabucazo...

Buf, son aproximadamente unos 4 años de trabajo, con una media de entre unos 3-6 desarrolladores ocasionales más pequeñas contribuciones.

Anda que las estimaciones que da sloccount están a años luz de la realidad, pero bueno.