Archivo de la categoría: PlanetaLinux

Si, esta categoría engloba todo lo “sindicalizable” por planeta Linux Venezuela; de acuerdo a estándares de calidad on-topic (por favor, dejemos de repetir que Debian etch es estable!, ya lo sabemos!, seamos originales aqui!)…

Garimpeiros digitales

bitcoin1

Introducción

¿Qué es minar?, ¿como es eso de echar pico y pala en una red?, ¿por qué nace Bitcoin?, ¿debería estar minando?, sería interesante conocer para “al menos” estar informado y que no te agarre por sorpresa, aquí algunos conceptos previos:

Glosario:

Criptografía: Se trata de un ámbito de la criptología, dedicado a la construcción de reglas de cifrado o codificado de información para permitir su “ocultamiento” y transmisión, para hacerlo inentendible por ojos no autorizados; la criptografía además es todo un ámbito de las matemáticas científicas destinada a elaboración de técnicas de cifrado mediante algoritmos y pruebas matemáticas.

Hash (cadena): Se conoce como “hash” a la cadena generada por algún algoritmo criptográfico de suma resumen (o función hash), algunas sumas no pueden ser resueltas al valor inicial, por ejemplo:

“hola mundo” en SHA256 es: 41d85e0b52944ee2917adfd73a2b7ce3d3c8368533a75e54db881fac6c9ad176, la suma no puede ser “devuelta” a la forma “hola mundo”, en su defecto, ámbos lados de la operación (cliente y servidor) conocen la cadena “hola mundo” y se intercambian los hashes resultantes, así, comprueban que están usando la misma cadena origen.

Otros algoritmos de resumen, como “base64″, son deterministas, es decir, una cadena siempre devuelve la misma suma, por lo que la “reversión” es posible.

Entre los algoritmos de función hash más comunes estan:

* Base64
* CRC
* MD5
* SHA1
* SSHA
* SHA256
* SHA512
* Whirlpool

Cryptocurrency (cryptomoneda): Se trata de un concepto de pago entre 2 usuarios, utilizando una “moneda” común entre ámbos, la transacción es “cifrada” utilizando reglas matemáticas criptográficas de alta seguridad, para evitar que más nadie fuera de la red pueda alterar, falsificar o reversar la transacción, por utilizar reglas matemáticas tanto para su cifrado, como para su “demostración” (resolución) a dicha moneda se le conoce como criptomoneda; las criptomonedas más comunes hoy día son:

* Bitcoin
* Litecoin
* Dogecoin
* PeerCoin

Bitcoin: Criptomoneda de uso más común y más popular, su símbolo monetario es BTC, en la actualidad se cotiza alrededor de los 310US$ por Bitcoin, es una moneda multidecimal (a diferencia de los dólares o bolívares, que no tienen más de 2 decimales), con un valor mínimo de 1 Satoshi (igual a 0.00000001 ฿), llamado así por Satoshi Nakamoto, el *creador* de Bitcoin (coloco entre comillas, puesto que la verdadera identidad del creador del Bitcoin es un misterio).

Altcoin: Se conocen como altcoins a todas las monedas alternativas surgidas a raíz de bitcoin, diseñadas con propósitos especificos o como alternativas directas al bitcoin.

Red P2P: Una red P2P (Point-to-Point o “punto a punto”) es una red colectiva de usuarios, cada individuo de la red interactúa directamente con los otros individuos, evitando la existencia de un ente “central”, las emisiones en una red P2P son distribuidas (broadcast) por lo todos los usuarios reciben la información que generó cada uno de ellos.

Red de la cryptomoneda: La criptomoneda opera en una red distribuida (P2P) de usuarios, dicha red permite a todos los usuarios emitir o recibir pagos en la criptomoneda, mientras todo el conjunto de usuarios valida las transacciones para aumentar la seguridad de dicha red, como cada usuario auto-contiene el conjunto global de transacciones realizadas, la red se auto-protege contra fraudes (como por ejemplo el “doble gasto”, nadie puede gastar su dinero 2 veces, los usuarios de la red determinarán cual de las transacciones es la única correcta); además, es descentralizada, ya que no hay ente central (Banco Central) que dicte las normas o sea el contenedor de único de las transacciones de la red; además, al ser descentralizada y distribuida, todos los usuarios cuentan con los mismos derechos dentro de la red.

Dirección (address): es una dirección física que identifica a un usuario en la red de la cryptomoneda, tiene la forma de una larga secuencia de dígitos y letras, para mantener el anonimato de los usuarios, un usuario puede tener múltiples direcciones físicas asociadas a una billetera (wallet) y puede usar una dirección para una única transacción, por ejemplo VrV1WaEMBcQmK6e4w4ydU27M5WQG3bnP75 es mi dirección para pagos con Vertcoin.
Las transacciones son emitidas usando una “dirección” del usuario “A” hasta la dirección del usuario “B”.

Transacción: Es el proceso de enviar crytomoneda desde A hasta B, es un proceso sencillo en el cual, la dirección “A”, emite un conjunto de crytomonedas almacenadas en su billetera, para realizar un pago a “B”, cada transacción (o conjunto de transacciones) es almacenada en una estructura de datos conocida como “bloque”.

Wallet (Billetera): también conocida como “monedero”, es una cuenta dentro de la red de la cryptomoneda, dónde almacenas tus monedas y permite generar direcciones para realizar o aceptar pagos, el wallet es tu propio “banco central”, pues se sincroniza con la red de la cryptomoneda y almacena la cadena de bloques mostrando todas las monedas que están “a tu nombre”.

Bloque: Cada transacción (o varias) realizadas en cryptomoneda, son almacenadas en una estructura (registro o “record”) conocida como “bloque”, esta estructura contiene el tamaño total del conjunto de transacciones pendientes de ser permanentemente almacenadas, la información de las transacciones (las “direcciones” que realizaron la misma), el contador de la cantidad de transacciones contenidas, un número mágico (siempre el mismo para cada tipo de cryptomoneda) y obviamente el espacio de descripción de las transacciones, además de una referencia al bloque predecesor, el proceso de “capturar, identificar y resolver” dicho bloque, se conoce como “resolución de bloque”, el conjunto de todas las transacciones ya permanentemente almacenadas se conoce como “cadena de bloques”.

Resolución de bloque (solving block o “romper el bloque”): además de la información transaccional, cada bloque provee una “prueba de trabajo” (proof-of-work), que es única por cada bloque (por la alta aleatoriedad y la baja probabilidad de cada bloque), ningún bloque es registrado permanentemente en la cadena de bloques si no es “resuelta” esta prueba, luego de que algún “usuario” de la red “resuelve” el bloque (y se gana la “recompensa”), el resto de usuarios puede validar fácilmente que la solución que encontró es la correcta; al tratarse de de hashes, hay múltiples soluciones posibles, pero solo es necesaria que se encuentre una para determinar que el bloque es correcto y se registra en la cadena de bloques.

Confirmación de bloque: Cuando se captura, identifica y resuelve el bloque, se produce un proceso de “confirmación”, aunque alguien haya “resuelto” el bloque, no se espera sino hasta un número de confirmaciones (usuarios que indican que la resolución de bloque es correcta) para determinar que el bloque es “legal” y debe ser registrado en la cadena de bloques; con muchas confirmaciones se evita que alguien pueda “reversar” la transacción. La cantidad de confirmaciones depende de la cryptomoneda, en la red bitcoin se requiere de al menos 6 confirmaciones para la validez de un bloque.

Reward (recompensa): Cuando ocurre un conjunto de transacciones entre “A” y “B”, un tercer usuario “C” encuentra y “resuelve” el bloque para demostrar que la transacción entre A y B es válida, para “recompensar” a dicho usuario C, la red de la cryptomoneda emite “monedas nuevas” como gratificación (bounty) por su dedicación a resolver el bloque, es como un “coste de transacción” o fee, pero que no es pagado ni por A ni por B, sino con la emisión de monedas nuevas. El valor de dicha recompensa es fijo, pero decrece con el tiempo al aumentar la complejidad (y la cantidad total de clientes) de la red de la cryptomoneda, por ejemplo:

* Bitcoin: 25BTC por bloque
* Litecoin: 50LTC por bloque
* Dogecoin: 15mil DOGE por cada bloque

Por ejemplo, en bitcoin la recompensa se reduce a la mitad cada 210 mil bloques (que ocurre aproximadamente cada 4 años).

Mining (Minería): Se conoce como “minería” a la “competencia” que ocurre entre todos los usuarios de la red, de encontrar un bloque y “resolverlo” para ganarse la recompensa, el tiempo de resolución depende del algoritmo de la moneda, en Bitcoin es aproximadamente 60 segundos, en dogecoin son 70 segundos, si en el tiempo de resolución (confirmation time) quien “encontró” el bloque no resuelve el bloque, otro más podrá resolverlo.
Como la red de la cryptomoneda es “broadcast” (de difusión) la probabilidad de ser quien “encuentre” un bloque sin resolver es la misma para todos los nodos dentro de la red, pero la velocidad con la cual resuelves el bloque depende de tu poder de resolución (“hashing power”).

Miner (software|hardware): Consiste en un software o una pieza de hardware, diseñada para capturar los bloques y resolverlos, la resolución del mismo se basa en un algoritmo de prueba de trabajo (POW: Proof-of-Work) que determina la validez de la solución; para Bitcoin se han diseñado dispositivos FPGA (Compuertas lógicas programables) y más recientemente Circuitos programables de aplicación específica (ASIC) que computan la solución de la prueba de trabajo; en algunos casos la solución de la misma no es resoluta vía FPGA o ASIC (ASIC-Resistant), entonces se utiliza para minar algún software que usa trabajo del CPU o de la GPU.

Cadena de bloques (blockchain): Consiste en todo el conjunto de bloques (transacciones) generados durante la vida de la cryptomoneda (desde sus inicios), por ejemplo, la transacción cero (génesis) fue incorporada a la red Bitcoin por Satoshi Nakamoto en 2009. Para mantener la “descentralización” de la moneda, todo operario (cliente) debe mantener junto a él el bloque transaccional; esto es debido a la forma como se calcula cada bloque, como cada bloque contiene el bloque anterior, para cambiar un bloque, se requiere la re-generación de todos los predecesores, re-haciendo además todo el trabajo que ellos contienen (recalcular sus hashes), esto protege la cadena de bloques contra su manipulación, por ende, todos los usuarios de la cryptomoneda poseen la misma cadena de bloques (idéntica) evitando así que alguien pueda cambiarla.

El tamaño actual de la cadena de bloques es de:

Bitcoin: 33GB
Dogecoin: 6GB
LiteCoin: 4GB
Feathercoin: 800MB

Proof-of-work (POW): Una prueba de trabajo, es un pequeño pedazo de información que es muy difícil de obtener/generar (consume tiempo y trabajo por parte del cliente) y usualmente es calculado/generado por el computador del cliente, el POW (La prueba de trabajo) se usa para evitar ataques de denegación de servicio ya que para el cliente debe ser moderadamente difícil de generar (es un proceso aleatorio y de baja probabilidad de obtención de 2 resultados iguales), pero a su vez debe ser sumamente trivial para el servidor determinar la validez de la prueba de trabajo una vez resuelta y enviada por el cliente.

Algoritmos de prueba de trabajo: Para determinar que “en verdad” has trabajado en la resolución de un bloque, se realiza una prueba de trabajo, que consiste en calcular un hash correspondiente al bloque actual, combinado con el bloque anterior, dicho cálculo utiliza un tipo determinado de algoritmo (muchos de hechos diseñados específicamente por la criptomoneda en cuestión), por ejemplo:

* Hashcash de doble iteración: Bitcoin utiliza un algoritmo HASHCASH de doble iteración (doble cifrado) usando el algoritmo de función hash SHA256, es hashcash es difícil de obtener con CPU o con GPU, pero a dispositivos FPGA programados para ello se les hace trivial (y muy barato) resolver dicha función.

* Scrypt: En vista de que el algoritmo hashcash es fácilmente resoluto con equipos específicos de puerta lógica de baja memoria (FPGA) y con la alta proliferación de dichos equipos para la resolución de bloques Bitcoin, se diseñó Scrypt, que incorpora algoritmos que requieren el uso intensivo de memoria (al usar mucha memoria, reducen la eficiencia de los FPGA), para su resolución es más útil el uso de GPU (Graphic Process Unit, comunmente encontrados en tarjetas de video) con un buen ancho de banda de memoria (ejemplo, tarjetas AMD Radeon o NVIDIA). Dogecoin, Litecoin y otras cryptomonedas usan scrypt como algoritmo de prueba de trabajo.

* NeoScrypt: con el diseño de circuitos integrados de aplicación específica (ASIC) que resolvian muy fácilmente el algoritmo scrypt, se diseño neoscrypt, un combinado de algoritmos de cifrado (Salsa20/20, ChaCha20/20, Blake2, etc) con un uso altamente intensivo de memoria que lo hace resistente a su descifrado con dispositivos ASIC. Phoenixcoin y Feathercoin utilizan NeoScrypt.

* X11: Es un algoritmo de prueba de trabajo, que combina 11 algoritmos diferentes en cadena para la resolución de la prueba, haciendolo ASIC-resistant y GPU-oriented, Darkcoin y otro conjunto de criptomonedas usan dicho POW.

* Lyra2RE: Con el diseño de ASIC que resolvían Neoscrypt y scrypt, Vertcoin diseñó un algoritmo de prueba de trabajo conocido como Lyra2RE, al igual que neoScrypt y scrypt-N, Lyra2RE es realmente un combinado de cifrados que incluye NIST5, Blake-256, Lyra2 y Groestl-256, debido a su naturaleza, la paralelización y la optimización de Lyra2RE es prácticamente imposible, con lo cual, paralelización vía múltiples nodos con GPU u optimizaciones agresivas de la GPU son inútiles con el mismo, garantizando los mismos derechos a todos los usuarios de la red.

* M7M: Con el advenimiento de ASIC que minan scrypt y neoscrypt y con el hash-power de granjas de GPU, la criptomoneda MAGI (XMG) diseña M7M, es una POW que combina 7 algoritmos únicamente resolutos vía CPU (ASIC-Resistant, GPU-Resistant).

La razón del cambio de la prueba de trabajo, es para evitar la “centralización de minería” y evitar “que los ricos se hagan más ricos”, personas con gigantescas granjas paralelas de ASIC que pueden resolver cualquier bloque con facilidad, llevándose el máximo de las recompensas, por ejemplo, la distribución de la riqueza en la red bitcoin es:

Top 10 usuarios: 6.29%
Primeros 100 usuarios: 21.20%
Primeros 1000 usuarios: 40.03%
Resto: 63.41% Total

Como vemos, 10 usuarios concentran 6% de la riqueza bitcoin (unos 700 millones de US$), 1000 usuarios concentran el 40% de la riqueza, en cambio en la red vertcoin, hay solo 1 cuenta con más de 1 millón de vertcoins (unos 27 mil US$) y el 85% de la riqueza está distribuida en la mayoría de los usuarios.

Proof-of-Stake (prueba de participación): Nuevas monedas como Peercoin introducen la “prueba de participación”, es el sistema actual de las cuentas con intereses de los bancos, cada usuario gana por su participación en la red un “interes” y dicho interés es calculado en base a la cantidad de monedas con las que participe en la red, eso asegura que botnets (grandes robots minando día y noche) sin participación monetaria en la red, pudieran ganar algún interés.

Hash Power: Es la cantidad de hashes (resoluciones del algoritmo de cifrado) que puedes computar en un segundo, el Hash power requerido para resolver rápidamente un bloque depende enormemente de la complejidad inherente de la red, de la cantidad de usuarios compitiendo y de la cantidad de moneda disponible, la unidad de medida es el Hash/Segundo, mientras más Hashes/segundo puedas computar, más rápidamente obtendrás la resolución del bloque/segmento, algunas monedas requieren pocos KiloHashes/segundo mientras por ejemplo, Bitcoin requiere equipos que pueden estar rondando los varios GigaHashes/segundo (GH/s).

Velocidad Hash/Hash Rate: La tasa de hash o “hash rate” es la unidad de medida de la potencia total de la red de procesamiento de la criptomoneda, es la combinación de todo el poder encontrado en la red durante un momento en el tiempo, esto determina la dificultad con la cual se captura/procesa/resuelve cada bloque, en la actualidad el Network Hash rate de algunas monedas:

* Bitcoin: 290 PH/s (Petahashes sobre segundo)
* Litecoin: 1.3TH/s (Terahashes sobre segundo)
* Dogecoin: 1.2TH/s
* Darkcoin: 78 mil GH/s (Gigahashes sobre segundo)
* Vertcoin: 2500 GH/s

Solo mining (Minería en solitario): Consiste en conectarse a la red P2P de la criptomoneda y dedicar tu poder de procesamiento directamente a descubrir y resolver bloques, cuando minas solo, la totalidad de la recompensa recae en el usuario; sin embargo, debido a la aleatoriedad y alta complejidad de los bloques, se requiere una buena conexión y un alto poder de resolución de hashes (además de mucha suerte) para ser el primero en encontrar un bloque y resolverlo.

Pool Mining (Minería en grupo): Debido a que es una red P2P (distribuida), no importa si tienes un terahash/segundo de poder (eso sólo ayudará a que resuelvas más rápido un bloque, no a que te otorguen más bloques), como el otorgamiento de resolución de bloques es broadcast (distribuido) entonces cuando muchas personas de diferentes partes del mundo se juntan para resolver un único bloque, entonces se incrementa el chance no solo de resolver más rápido (el bloque total se divide en shares, que son resueltos por cada uno de los minadores) sino de además hay más nodos con probabilidades de capturar un nodo, así las ganancias se distribuyen entre todos los participantes del Pool.

Minería para no-mineros

bitcoin-miner

Conocidos algunos conceptos previos, entendamos el proceso de manera general y sin tanta jerga técnica, en el mundo real, todos compramos con dinero, el dinero es una representación o fracción de la “riqueza total” de una nación y solamente el banco central de un país puede emitirlo; “A” toma su riqueza (en oro y bienes) y las convierte en “dinero”, que usa para pagarle a “B” otros bienes, que su valor ha sido calculado con anterioridad en base a su proporción “riqueza-dinero”.

En el mundo digital, ocurre algo semejante, Sujeto “A” desea pagarle a Sujeto “B” una cierta cantidad de dinero, entonces, entre A y B ocurre una “transacción”, dónde “A” le pasa a “B” el dinero demandado por algún bien o servicio; para asegurar la transacción de ojos “curiosos”, “A” y “B” cifran su transacción con la lógica que la criptomoneda que estén usando ha diseñado; para validar que *en verdad* A y B movilizaron dinero, en vez de Bancos y Banco Central, están otros sujetos alrededor de la red P2P, que ven la transacción de “A” con “B” y sirven de testigos, le gritan al mundo “Si!, A le envió dinero a B!”, la transacción es confirmada y el dinero es debitado de la billetera de “A” y es confirmado en la billetera de “B”.

Para que sea “rentable” participar como testigo de dicha red P2P, cada transacción paga un fee (impuesto) que es otorgado a la primera persona que *aparece* como testigo de A->B, además, la propia red P2P (así como el Banco Central imprime más billetes cuando ha incrementado la riqueza del país) emite “monedas nuevas” que son otorgadas adicionalmente al término de cada transacción (recompensa), así, la riqueza de cada uno va incrementándose a medida que se incrementa la riqueza de la red P2P en general.

Adicionalmente, hay personas que toman dinero del mundo “real”, y compran monedas del mundo digital (a sujetos que ya tienen monedas en su poder) en casas de cambio (Stock Exchange), lo que incorpora más “nodos” a la red P2P, por ende más complejidad, más emisión de moneda y más “riqueza”.

En la actualidad la red Bitcoin cuenta con 4100 millones de US$ en dinero circulante mientras que la red litecoin cuenta con 75 millones de US$.

Garimpos del Bitcoin

Se conoce como Garimpeiro (palabra portuguesa que significa  “trabajador de los Garimpos”, sitio remoto de minería ilegal), a aquellos trabajadores que destinados a sitios de minería que realizan su explotació de manera manual, ineficiente, ilegal y a veces en condiciones infrahumanas, los Garimpeiros suelen “arriesgar su vida” dedicados a la minería ilegal en zonas muy alejadas, expuestos a venenos como mercurio o cianuro y a la destrucción ecológica.

En algunas regiones del mundo, pero por sobre todo en latinoamérica, han proliferado los que he descrito como “Garimpeiros digitales”, ¿por qué?, se dedican a minar sin un ápice del conocimiento arriba descrito, a veces simplemente colocan máquinas a minar y creen que la máquina está “haciendo plata solita” (como un Garimpeiro toma 2 toneladas de tierra, le inyecta mercurio y saca 2 gramos de oro y cree que le fue “bien”), sin entender los conceptos de resolución de bloque, transaction fee o bounty reward, tampoco entienden los algoritmos con los que están cifrados los bloques (algunos que he hablado con ellos, ni siquiera entienden el concepto de “bloque”), minando en condiciones “infrahumanas” (por decirlo de algún modo) con un profit (beneficio) ínfimo.

¿A qué se debe esto?, veamos …

La tragedia de los comunes

Aunque la tragedia de los comunes es un principio descrito por el ecologista Garret Hardin para describir el comportamiento de cómo individuos, incluso inocentes, todos motivados únicamente por un interés personal y de manera independiente uno del otro (con un comportamiento racional, desconociendo las intenciones de los demás) pueden llegar a acabar y/o destruir un bien común limitado, incluso con pleno conocimiento (como individuos y/o como conjunto) de que dicha destrucción no beneficiará a nadie en el largo plazo, (un ejemplo de ello es la contaminación, los individuos siguen contaminando porque consideran que su impacto individual es ínfimo, pero el proceso en conjunto terminará por destruir la atmósfera y acabar con la vida en el planeta a largo plazo); en la red bitcoin se hace uso de ese principio una y otra vez, ¿por qué cada vez más gente entra a minar aunque las transacciones para usarlo no crecen con la misma intensidad?, pues el beneficio intrínseco e individual de minar, ganar “como moneda” simplemente por el hecho de quedarse con el botín y venderlo para adquirir otra moneda (la moneda como mercancía, fábrica de la especulación), sin embargo, con la incorporación de más y más nodos (y su hash-power) matemáticamente la complejidad de la red bitcoin se irá incrementando, reduciendo a su vez el botín, acercándose cada vez más a nivel de recompensa “0” (cero), ¿qué significa esto?, que los usuarios minadores sólo obtendrán como recompensa los ínfimos transactions fees generados, convirtiendo a los minadores en individuos sub-pagados (margenes de ganancia efímeros comparados con el poder de procesamiento que tuvieron que invertir para resolver los bloques), haciendo que los minadores en esas condiciones se retiren y toda la red bitcoin dejaría de funcionar correctamente.

¿Por qué ocurre esto?, las condiciones son diferentes en varios países, aunque en Venezuela tiene una explicación lógica, CADIVI y la restricción cambiaria.

La moneda como mercancía

Durante siglos la moneda fue el instrumento de canje con el que se tasaban productos y servicios y permitía intercambiarlos, en un mercado convencional, individuo “A” siembra una mazorca de maíz, su coste de producción es tasada en 5 monedas, por lo que individuo “A” la vende (para ganarle algo) en 8 monedas al productor de harina “B”, que le suma sus costes de producción (2 monedas por mazorca) y de dicha mazorca obtiene 2 envases de harina de maíz que tienen un coste de 5 monedas por paquete, vendiéndolas al comprador “C” en 8 monedas cada una.

En la actualidad, ciertas monedas se convierten en mercancía, como el dólar, esto es debido a las restricciones cambiarias impuestas en Venezuela, que hacen imposible a ciertos individuos acceder a los dólares necesarios para realizar sus compras e importaciones; entonces, individuos inescrupulosos toman el dólar adquirido a precio “A” más bajo y lo venden con sobreprecio a precio “B” a los interesados, no hubo ni bienes ni servicios, sino exclusivamente un intercambio de una moneda de un valor “ficticio” (impuesto por una entidad cambiaria alejada de la realidad) a otro valor ficticio (impuesto por los especuladores de moneda, en base a la capacidad de compra de los clientes).

El Bitcoin (y otras criptomonedas) se han convertido entonces en monedas de intercambio (la gente “genera” bitcoins, compra con ellos dólares, y vende los dólares en el mercado paralelo), no estoy criticando su uso (aunque me parece controversial el concepto de moneda como mercancía) sin embargo, mucha gente se dedica a minar desde la ignorancia, afectando el desempeño general de la red; aunque ciertamente es complicado escribir “recomendaciones de minería” que pudieran verse como “intentos” de adquirir divisas por métodos no descritos en la legislación y cometer un ilícito cambiario.

Sería interesante saber, por ejemplo, si el “distinguido” empresario Venezolano que compró una empresa que fabricaba dispositivos ASIC de minería (ASIC-miners) y su inventario de equipos por 1.2 millones de US$, los usará para generar una red bitcoin y una estructura de pagos alrededor de él (tipo MercadoPago pero con bitcoins), o será otro “garimpeiro más” que se dedicará a generar bitcoins para luego comprar dólares y venderlos en el mercado paralelo.

Otra pregunta sin respuesta, pero eso es otra historia …

Wow!, mino 1US$ diario, le estoy ganando a CADIVI!

Fue la expresión de alguien hace algún tiempo, cuando dedicó su computador 24/7 a minar litecoins usando una combinación de CPU/GPU, esto representaba 365US$ anuales, ciertamente un poco más de lo que CADIVI asigna anualmente para gasto electrónico (300US$), sin embargo, con la complejidad del bloque Litecoin, una GPU decente (una AMD RADEON R9 290, por ejemplo) tiene un costo de entre 400 a 800US$, a menos que tengas muy muy bien refrigerado tu centro de datos, el quemar la GPU de tu tarjeta de video (muy probable con la alta tasa de computo a la que es sometida diariamente) te llevará 2 años de minería recuperarla.
Incluso adquirir ASIC destinados a resolver los algoritmos scrypt y neoscrypt (o scrypt-n) de ciertas altcoins, será una inversión “a mediano-largo” plazo, puesto que la velocidad de resolución contrastará con la siempre incremental complejidad de la red.
A este factor, se unen 2 factores más que no tienen nada que ver con el usuario, la pésima velocidad de la red en Venezuela y una mucho más pésima infraestructura de servicios; si, ciertamente la velocidad del Internet promedio deja mucho que desear cuando una red exige 60 segundos de respuesta a un bloque que mide aproximadamente 500Kb y que hay que procesar con una prueba de trabajo cada vez más compleja (en el transcurso de redactar este artículo, ABA de CANTV me ha dejado sin conexión 3 veces), además cuando el blockchain (cadena de bloques) de Bitcoin mide 33GB sincronizarlo (un usuario nuevo tardaría 40 horas en descargarlo completo), pero esto no es nada al enfrentar un apagón de vez en cuando que pudiera “freir” nuestros equipos sin la protección debida (y la inversión necesaria en protección eléctrica y UPS sería mayor que la tasa de rentabilidad -profitability- que pudieramos obtener, por ejemplo, en la red Bitcoin) o simplemente “dejarnos a oscuras” y fuera de la red por mucho tiempo.

¿Me quedo mirando mientras los demás se hacen ricos?

No, no estoy diciendo eso, pero vale la pena entender los recursos que tenemos y/o pudieramos tener y dedicarnos a la red que más se adecúe a nuestros recursos, con la complejidad de los algoritmos actuales, la minería en pool parece más rentable que la tentadora pero traicionera minería en solitario (en promedio, una red como Litecoin “pudiera” otorgarte un bloque cada 300 días, aunque esto como es aleatorio, pudiera darse en mucho menos tiempo).

Minar Bitcoins con CPU es absurdo hoy en día (y costoso incluso a los costos de la electricidad en Venezuela), a menos que se apueste por minería de CPU como VertCoin o Darkcoin, si aún *considera* que tendrá suerte minando bitcoins y uniéndose a un pool, sería recomendable hacer una inversión inicial en ASIC Miners modernos que soporten *al menos* el algoritmo Scrypt (para permitirle “cambiar” a minería de Litecoins o Dogecoins); si con lo que cuenta es con tarjetas de video (perfectamente refrigeradas para que no se quemen) entonces busque altcoins con algoritmos ASIC-Resistant pero que tengan una alta rentabilidad; en general, es un proceso “a futuro” y la minería de altcoins (exactamente igual como pasó con Bitcoin en un inicio) es un proceso a largo plazo, por ejemplo, un dogecoin vale solamente 0,00005 de BTC (y bajo las perspectivas actuales de uso, su precio se mantendrá estable por un largo tiempo), en cambio, los Darkcoin tienen una alta expectativa de crecimiento a mediano plazo, Los peercoin y Paycoin mantienen un precio estable, mientras que Litecoin pierde el interés de inversionistas frente a otras altcoins más modernas.

Yuppies de sillón

Minar, y en general trabajar con criptomonedas, es un proceso de conocimiento, tanto de economía de moneda, de mercado, como de matemáticas y computación, no es “puse mi portátil a minar litecoins porque un amigo de facebook me dijo que eso hace plata”, hay “yuppies” que pasan toda su vida en Wall Street y ganan lo necesario para vivir y otros que llegan con el conocimiento, las ganas de invertir y se hacen ricos en 30 días.

Sería interesante saber de cual tipo de yuppie quisieras considerarte …

 

Happy Mining!

Historia de un script

Siempre me gusta tener un repositorio Debian en un disco portable, una conexión decente en dónde vivo (Guanare) es inexistente y de igual manera en el resto de ciudades, es mejor instalar Debian rápidamente que tener que esperar 2 horas de descargas.

Sin embargo, actualizarlo es otra cosa muy distinta, debo contar con una conexión “decente” (por encima de los 200kB/s) o podría pasar días enteros esperando a que “sincronize”, a veces, los archivos quedan “truncados” o no se descargan correctamente (uso rsync y si un archivo no se descarga correctamente, salta al siguiente y ese queda en falla).

Entonces escribí este script (https://github.com/phenobarbital/check_debian_repository), que, aunque está en sus inicios, aplica la filosofía del IDM (Internet Download Manager) y de los Download Accelerators, para descubrir qué archivos faltan en un mirror Debian y descargarlos en paralelo.

Por qué haría algo así? y por qué nadie había hecho algo parecido?, bueno, cuando tu velocidad promedio de descarga es:

>f+++++++++ pool/main/libr/libreoffice/libreoffice-help-zh-tw_4.2.6-1~bpo70+1_all.deb
1.93M 46% 162.71kB/s 0:00:13

162kB/s (y estaba rápida, son las 4 am) mientras amigos en países incluso consideradores “tercer mundo” con El Salvador o Guatemala poseen conexiones de 5MBps ó 10MBps, yo me tengo que conformar con “viajar” a Barquisimeto y conectarme al ABA de CANTV de la casa de mi mamá qué cuando funciona “de maravilla” (como ahora, a las 4am) reporta que es de 1.2MBps (aunque pago por 2MBps). La cosa no es que la conexión “sea cara” es que literalmente no existe.

Entonces, uno termina haciendo cosas que solo sirven para países en condiciones como las nuestras, espero que alguien más, con la necesidad de tener un mirror Debian multi-arch sincronizado y que tenga una conexión pobre, le sirva este script.

Saludos.

[iptables] Descargando listas negras con Shorewall

Una de las características más importantes que debe realizar un firewall hoy día es reaccionar ante atacantes y/o conjuntos de atacantes, uno de ellos son los firewalls que protegen servidores de correo.

Las RBL (Realtime Blackhole List) son listas negras en tiempo real, generadas por muchísimas empresas e instituciones (spamhaus, por ejemplo) y que nos permiten obtener un listado bastante grande de IPs y subnets que son vigiladas por SPAM.

Hoy voy a probar hacer 2 listas negras, una desde Spamhaus y otra, de las subredes chinas más comunes utilizadas por los hackers.

Preparando a Shorewall para listas negras

Shorewall posee un archivo llamado /etc/shorewall/blacklist, de no poseer ese archivo, no hay problema, ya que crearemos un script que lo generará.

Pero primero, debemos indicar que la disposición de las IPs y subredes dentro del archivo BLACKLIST sea DROP.

Para ello ejecutamos:

sed -i "s/^BLACKLIST_DISPOSITION=.*$/BLACKLIST_DISPOSITION=DROP/" /etc/shorewall/shorewall.conf

Y refrescamos shorewall.

shorewall refresh

Script para descargar listas negras

Ahora debemos crear un script, que se ejecute mensualmente y que se dedique a “llenar” el archivo blacklist con listas dinámicas de varios sitios:

  • DShield Blacklist
  • Spamhaus DRBL
  • OKEAN Chinese and Korean Spammers
  • Wizcrafts (russian botnets)
  • RBN: Russian Bussiness Network
  • OpenBL

Con este conjunto de listas, creamos el script:

#!/bin/bash
cat <<EOF > /tmp/blacklist
#ADDRESS/SUBNET PROTOCOL PORT
# block all between ports 1 and 31
- tcp 1:31
# block unused ports
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898
# block all from spamhaus, dshield and wizcrafts
EOF
echo "# dshield blocklist" >> /tmp/blacklist
wget -q -O - http://feeds.dshield.org/block.txt | awk 'NF && !/^[:space:]*#/' | sed '/Start/,+1 d' | awk '{ print $1 "/24"; }' >> /tmp/blacklist
echo "# spamhaus DRBL" >> /tmp/blacklist
wget -q -O - http://www.spamhaus.org/drop/drop.lasso | awk 'NF && !/^[:space:]*;/' | awk '{ print $1 }' >> /tmp/blacklist
echo "# chinese and korean spammers" >> /tmp/blacklist
wget -q -O - http://www.okean.com/sinokoreacidr.txt | awk 'NF && !/^[:space:]*#/' | awk '{ print $1 }' >> /tmp/blacklist
echo "# Wizcrafts Russian botnets, attackers and spammers" >> /tmp/blacklist
wget -q -O - http://www.wizcrafts.net/russian-iptables-blocklist.html | awk -F\> '/^pre>/{print $2}' RS=\< | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "# RBN Russian IPs" >> /tmp/blacklist
wget -q -O - http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "# OpenBL.org 30 day List" >> /tmp/blacklist
wget -q -O - http://www.openbl.org/lists/base.txt | tr -d $'\r' | awk 'NF && !/^[:space:]*#/' >> /tmp/blacklist
echo "#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE" >> /tmp/blacklist
mv /tmp/blacklist /etc/shorewall/blacklist
shorewall refresh &>/dev/null

El script simplemente descarga todo en una lista temporal, que luego reemplaza el archivo blacklist y refresca la configuración del shorewall.

Luego, simplemente hacemos un enlace simbólico a /etc/cron.monthly

Para verificar, simplemente ejecutamos:

iptables -L -n --line

O en su defecto,

shorewall show blacklst

Que serían aproximadamente unas 28 mil IPs que quedarían permanentemente bloqueadas y que mensualmente se renovaría la lista.

Conclusiones

Atrás quedaron aquellas románticas (pero estúpidamente inútiles) épocas donde la gente escribía sus breves y concisos archivos de “reglas iptables” y los ponía en producción (aun queda *peligrosamente* gente así), en la actualidad es sumamente complicado mantener protegido un Firewall, con constantes botnets, malware, troyanos y un pare de contar de ataques y aprovechar estas listas, muchas actualizables incluso en tiempo real, nos ahorra mil dolores de cabeza y protege un poco más nuestros servidores.

¿imaginen qué pudieramos hacer si integraramos fwsnort al Firewall de nuestro equipo? …

 

[iptables]: Usar geoIP y Shorewall para bloquear paises

Y no, no es para hacer embargos! …

Preámbulo

Se estaba presentando el caso de un ataque de fuerza bruta contra un servidor públicamente visible, el ataque venía mayormente de China y Hong Kong y decidí, que sería interesante aprovechar las capacidades del módulo de xtables XT_GEOIP para ubicar una IP geográficamente con un porcentaje más o menos preciso.

Por ejemplo, GeoIPLookup (que hace uso de la base de datos de GeoIP), puede retornar la siguiente información:

geoiplookup 186.92.27.1
GeoIP Country Edition: VE, Venezuela

Lo cual resulta muy útil, ¿se podrá usar para bloquear tráfico desde países completos? …

Pre-requisitos

Los pre-requisitos son los siguientes:

  • Shorewall, versión 4.5 o superior
  • xtables-addons-common
  • libtext-csv-xs-perl (para procesar la base de datos de georeferencia).

Por ende, es simplemente instalar las dependencias y tener configurado Shorewall.

aptitude install xtables-addons-common libtext-csv-xs-perl

Creamos el directorio que requiere el módulo:

mkdir /usr/share/xt_geoip

Y montamos el módulo:

modprobe xt_geoip

Ahora, nos toca descargar la base de datos:

/usr/lib/xtables-addons/xt_geoip_dl

Veremos algo como:

root@proxy:/etc/shorewall# /usr/lib/xtables-addons/xt_geoip_dl
–2014-06-24 22:07:01– http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
Resolving geolite.maxmind.com (geolite.maxmind.com)… 108.168.255.243, 2607:f0d0:3:8::4
Connecting to geolite.maxmind.com (geolite.maxmind.com)|108.168.255.243|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 823979 (805K) [application/octet-stream]
Saving to: ‘GeoIPv6.csv.gz’
100%[====================================================================>] 823,979 91.0KB/s in 9.3s
2014-06-24 22:07:11 (86.9 KB/s) – ‘GeoIPv6.csv.gz’ saved [823979/823979]

Y por último, convertimos este CSV en una forma binaria empaquetada que requiere el módulo xt_geoip:

/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv
1 IPv6 ranges for VC Saint Vincent and the Grenadines
23 IPv4 ranges for VC Saint Vincent and the Grenadines
38 IPv6 ranges for VE Venezuela
230 IPv4 ranges for VE Venezuela
0 IPv6 ranges for VG Virgin Islands, British
48 IPv4 ranges for VG Virgin Islands, British
2 IPv6 ranges for VI Virgin Islands, U.S.
47 IPv4 ranges for VI Virgin Islands, U.S.
32 IPv6 ranges for VN Vietnam
257 IPv4 ranges for VN Vietnam
5 IPv6 ranges for VU Vanuatu
14 IPv4 ranges for VU Vanuatu

Y ya estamos listos para hacer uso de esta base de datos en Shorewall.

Configurando Shorewall

Desde Shorewall 4.5 existe soporte para GeoIP y su uso es extremadamente fácil, por ejemplo, podemos agregar al archivo /etc/shorewall/rules la siguiente regla:

DROP net:^[CN,TW,JP] fw - -

Y estaríamos bloqueando (DROP) desde mi zona “Internet” (net) a China (CN), Taiwan (TW) y Japón (JP), con destino a mi firewall (fw) de absolutamente todo tráfico UDP y TCP.  el formato del país es ISO-3661.

Podríamos por ejemplo, aceptar pero con información (LOG) todo tráfico WEB reportado como IP de Venezuela:

ACCEPT:info              net:^[VE]        fw          tcp          80,443

Podemos bloquear todo tráfico que sea explicitamente declarado como un proxy anónimo (según las reglas de GeoIP):

DROP        net:^[A1,A2]                  fw              -             -

Y listo!, verifiquen sus reglas y disfruten!.

Conclusiones

Los 2 comandos de arriba para descargar la base de datos de GeoIP podemos meterlos en un script, que se ejecute mensualmente, con esto, el sistema se actualizaría solo:

vim /etc/shorewall/scripts/updategeoip.sh

#!/bin/bash
# update geoip database (xt_geoip)
/usr/lib/xtables-addons/xt_geoip_dl > /dev/null 2>&1
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv > /dev/null 2>&1
# refresh configuration
shorewall refresh &>/dev/null

hacerlo ejecutable:

chmod 0770 /etc/shorewall/scripts/updategeoip.sh

Y colocar un enlace simbólico en cron.monthly:

ln -s /etc/shorewall/scripts/updategeoip.sh /etc/cron.monthly/updategeoip.sh

Y ya tendríamos un Firewall que bloquea (con una precisión del 74%) todo acceso desde el gigante asiático.

 

 

Del por qué un desarrollador NO ES un Database Administrator?

O del por qué podría ser, pero debería primero cambiarse la camisa …

Este POST no busca explicar postgreSQL, ni siquiera es un artículo acerca de trucos o buenas prácticas, es simplemente una reflexión acerca de cómo pequeñas cosas que muchos pasan desapercibidas causan impacto profundo en el diseño de una aplicación.

Preámbulo

Tomé un servidor físico GNU/Linux que únicamente ejecutaba una base de datos y lo mudé a una máquina virtual restringida (¡conchale!, hay que ahorrar recursos!, pensé), pensando que todo quedaría bien.

Sin embargo, los usuarios del sistema (en producción) comenzaron a quejarse de lentitud, además, los administradores de sistemas comenzaron a notar excesivos picos de uso de CPU (¿en un equipo que sólo tiene postgreSQL?) e incluso en varias oportunidades se iba a SWAP.

Antes de devolver la base de datos al equipo físico, decidí hacer una revisión (les dije, “no solo monto sistemas, también sé de programación y mucho de base de datos, lo olvidan?”) y estas son las impresiones de la muy breve (pero exitosa) revisión.

El análisis

Lo primero que siempre hago cuando voy a analizar un sistema conectado a postgreSQL, es activar el slow log, esto es, comenzar a medir aquellos queries que consumen más del tiempo que uno supone debería asumir cierto tipo de consulta; paralelamente es daba una clase rápida de postgreSQL, de la importancia de entender el ciclo de parsing/análisis de una consulta SQL y más aún, de la importancia de entender SQL; por ejemplo, dos casos reales extraídos de este caso:

“fecha_inscrito” es un campo VARCHAR, donde almacenan algo como “12/04/2012″; si desean sacar el año, hacen un SPLIT de la cadena con un SUBSTR y sacan el tercer valor luego del “/” … ¿les parece eso correcto?, pues veamos el resultado:

postgres=# SELECT substr(’12/04/2012′, 6);
substr
——–
/2012
(1 fila)
Duración: 61,300 ms

Versus:

postgres=# SELECT EXTRACT(year from ‘2012-04-12′::date);
date_part
———–
2012
(1 fila)
Duración: 0,468 ms

Y comenzaron las alarmas!, 60 milisegundos menos!, pero chamo, a mi no me gusta trabajar con formato ANSI!, y luego les recuerdo que existe la variable de conexión DATESTYLE:

postgres=# SET datestyle to sql;
SET
Duración: 0,124 ms
postgres=# SELECT ‘2012-04-12′::date;
date
————
12/04/2012
(1 fila)
Duración: 0,154 ms

INSOLITO! ¿cómo es posible que una simple función SET cause que todas las fechas salgan con el formato que yo desee?, esto pasa cuando se desconocen los detalles de la base de datos con la que se trabaja.

Igual sucede cuando la gente comprende la diferencia entre usar ON y USING cuando se construyen JOINS (diferencia claro está, a nivel de planificador).

El tercer caso de no-entendimiento de postgreSQL ocurría con un “pseudo-ORM hecho a mano” por los mismos programadores, que no solamente escapaba mal las cadenas:

Esto:

(‘Empresa’, ‘   MATURIN’, ’15/04/2014′, …

No es igual a esto:

(‘Empresa’, ‘MATURIN’, ’15/04/2014′, …

Ya que la cadena ”    MATURIN” no es igual a “MATURIN”, a menos que se haga un TRIM adicional, afectando el performance de la consulta, sino que además, hacen cosas como esta:

’21’, ’32’, ’16’, ‘8’, …

¿Esos son cadenas o números?, luego de ejecutar un DESCRIBE a la tabla, encontramos con que son campos numéricos, y aunque postgreSQL hace la conversión, lanza un WARNING indicando que esos valores son “not integers”, lo cual obviamente no es para nada óptimo.

Esto es lo que pasa cuando los programadores, pensando como programadores, intentan diseñar bases de datos.

El extraño caso del CPU consumido

Me he encontrado con una consulta muy repetida, con esta forma:

SELECT * FROM sol_solvencia WHERE cod_aport = $1 and estatus = $2;

La consulta se repetía muchísimo (sobre todo en temporada de mucho uso de la aplicación web hecha en PHP) y los logs del postgreSQL reportaban que su duración, promedio, era de 550 milisegundos … grité (como gritó Emmet Brown cuando le dijeron que debía alimentar el D’lorean con 1.1Gigawatts) ¡550 milisegundos!, yo en 550 milisegundos corría una nómina y ellos sólo ejecutan un query!.

Luego de usar EXPLAIN ANALYZE nos encontramos con la sorpresa de que la tabla no posee índices de ningún tipo (alegan que es un sistema legado y viene así de informix) y en la actualidad posee unos 98 mil registros; por ende, postgreSQL no le queda de otra para hacer el WHERE que ejecutar un SEQUENTIAL SCAN; o lo que es lo mismo, postgreSQL iteró de manera secuencial por los 98 mil registros para sacar ámbos criterios, ¿en conclusión?, allí se van los 550 milisegundos.

Si el query se ejecuta a un ritmo de hasta 50 veces en un minuto, se imaginan el uso de CPU de postgreSQL para poder mantener ese ritmo.

Indizar, y sino, indizar también …

Luego de construir un par de índices sencillos:

CREATE INDEX idx_sol_solvencia_cod_aport ON sol_solvencia USING btree (cod_aport NULLS FIRST);

Y

CREATE INDEX idx_sol_solvencia_estatus ON sol_solvencia USING btree (cod_estatus);

El EXPLAIN cambia considerablemente:

Aggregate  (cost=32.19..32.20 rows=1 width=4)
  ->  Index Scan using idx_solvencia_fecha on sol_solvencia  (cost=0.00..31.96 rows=94 width=4)
        Index Cond: (fecha_now = ’11-04-2014′::date)
        Filter: ((estado = 1) OR (estado = 15))

Al realizar un escaneo sobre índices y luego una función de agregado sobre ámbos índices, la consulta se ejecuta en 1.7 milisegundos …

¡toda una mejora!, ¿no les parece?

Prepáralo, ponlo para llevar

Luego, les expliqué el concepto del planificador, del GeQo de postgreSQL, y de cómo se analizaban las consultas, luego de ello, les dije “¿y se imaginan que ese tiempo pudiera bajarse más?” … te miran con cara de gallina comiendo sal y tú les muestras PREPARE.

PREPARE genera sentencias preparadas, toma una consulta común, la pasa por el planificador, construye el plan en base a criterios pre-definidos y compila este plan, presto a simplemente recibir los parámetros, ¿y qué ganamos con esto?, ¡ahorrarnos milisegundos valiosos de planificación!.

PREPARE pln_obtenersolvencia (int, varchar) AS
SELECT * FROM sol_solvencia WHERE cod_aport = $1 and estatus = $2;

Como ven, la sentencia preparada es simplemente un QUERY tradicional, al cual hemos pasado sus condiciones (que deben ser criterios, no metadatos) como parámetros, así, postgreSQL puede analizar, planificar y compilar la sentencia y esperar únicamente a que pasemos los parámetros:

EXECUTE pln_obtenersolvencia(682185, 1);

Total runtime: 0.473 ms
(1 filas)

De 1.7 a 0.4 ha sido una mejora interesante, ¿no?.

Conclusiones

No busco “echarme de enemigos” a los desarrolladores, yo también soy uno (de diseñado APIs, frameworks, y módulos en python y PHP), pero, cuando se trata de bases de datos, los desarrolladores deben quitarse los audífonos, la sudadera geek y ponerse en la camisa y anteojos nerd de los DBA; porque al final del día, la aplicación no se está diseñando para yo sentirme cómodo para trabajar con fechas o agregar y agregar campos sin mantener un diccionario de datos simplemente porque me pidieron en un lugar meter el RIF como J310210423 en otro como J-31021042-3 y en otro el tipo de contribuyente por un campo y el código del mismo por otro; no se trata de nuestra comodidad (o de nuestro limitado conocimiento como desarrolladores) sino de la eficiencia y la funcionalidad que deben garantizar que sea el USUARIO FINAL (y sólo él, porque al final, es el que usará todos los días la aplicación) quien disfrute el uso de nuestra aplicación.

Por cierto, como colofón, habrán notado que la tabla se llama “solvencia”, si, es un sistema que genera solvencias al público en general, ahora las consultas duran menos de un milisegundo (y no casi un segundo en cargar) por lo que la mejora impacta a miles de personas que solicitan la solvencia en ese sistema …

… Y ya el CPU no se agota en la máquina virtual! …

 

Instalar openWRT a un TP-LINK WR-741ND

He tomado un viejo enrutador TP-LINK pre-N (150Mbps) que tenía por allí para actualizarle el firmware e instalar openWRT, mis razones de por qué openWRT y no DD-WRT?

tplink

  • Lo que no podés hacer por la interfaz, lo hacés por consola
  • El soporte a VLANs es exactamente igual al nativo en Linux, si aprendí en Linux, lo sé hacer en openWRT
  • Selección: Varios “optware” (módulos opcionales) y mod-hackings presentes para openWRT me son útiles (como soldarle un puerto USB y usarlo como servidor de impresión)

Entre otras cosas, DD-WRT es bastante óptimo en estos equipos para cosas como permitir gestionar la inalámbrica, múltiples SSID (es lo bueno del software libre: elección) pero en mi caso, usaré el equipo para más cosas y por ende openWRT es mi opción.

Actualización del Firmware oficial

Lo primero que debemos hacer es actualizar el firmware oficial de la página de TP-LINK, esto con el fin de evitar inconvenientes y tener un firmware “oficial” de respaldo ante cualquier inconveniente.

or seguridad, actualizar a la última versión de la versión 1 (V1.6 en mi caso).

Descargar cualquier versión v1 del ROM oficial acá:

http://www.tp-link.com/ve/support/download/?model=TL-WR741ND&version=V1

– Descargar y descomprimir:

wget -c http://www.tp-link.com/resources/software/201011814560814.zip

unzip 201011814560814.zip
cd 201011814560814

– Ir a System Tools > Firmware Upgrade y cargar el binario que descargamos (wr741nv1_en_3_12_4_up(100910).bin)

– Reiniciar el equipo y luego un “factory defaults”

downgrade

Listo, actualizado a la última versión “oficial”, pasamos a obtener OpenWRT.

Obtener openWRT

Para obtener openWRT podemos ir a la página oficial del enrutador:

Página oficial: http://wiki.openwrt.org/toh/tp-link/tl-wr741nd

Y aprovechar el WIKI en español que nos ofrecen:

Wiki de openWRT en español: http://wiki.openwrt.org/es/toh/tp-link/tl-wr741nd

Para descargar la última versión estable para el enrutador (Backfire) apuntamos a:

– Descargar la última versión backfire:

http://downloads.openwrt.org/backfire/10.03.1-rc3/ar71xx/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin

– O con la última versión del trunk:

http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-factory.bin

También he descargado la última versión Beta (2014) (versión de actualización):

http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Con esto descargado, ahora si procedemos con el enrutador.

Desactivar opciones en el Router

Por seguridad deberíamos cumplir los siguientes criterios:

  • Estar conectados por la red alámbrica
  • Desactivar la red inalámbrica
  • Tener un firmware oficial descargado
  • Energía eléctrica estable (se los aseguro!, lean el último capítulo)

 

Preparando el TP-LINK para instalación

– Conectarse al equipo vía cable (parece obvio, pero hay que recordar que no se puede hacer este procedimiento vía wireless).
– Hacemos un respaldo del mismo (System tools > Backup & Restore > Backup)
– Reiniciamos el equipo a sus valores de fábrica (System Tools > Factory Defaults)
– Entramos al equipo con sus valores por defecto (IP: 192.168.1.1, user:admin, password:admin)
– Deshabilitamos el radio del equipo, para ello:
* vamos a la opción “wireless”
* desmarcan el checkbox “enable wireless radio”
* presionan el botón “SAVE”
* hagan click en el link “reboot” y luego en el botón “reboot”
* vayan a “status” y confirmen que Wireless está DISABLE.

wireless-disableAhora, ya podemos iniciar la instalación de openWRT.

Instalación vía Web

– Vamos a Firmware Upgrade (System Tools > Firmware Upgrade)

firmware-upgrade

Allí escogemos el archivo del firmware openWRT que seleccionamos y le damos “UPGRADE”.

Luego de unos minutos verán:

completed

Y el equipo se reiniciará en openWRT.

Accediendo al openWRT por primera vez

Al encender nuevamente el TP-LINK y conectarnos por red inalámbrica, nos dará una IP de la subred 192.168.1.0; nos conectamos al router a través de http://192.168.1.1/

Nos exigirá asegurar el equipo con una clave:

dd-wrt-first

Y luego de insertar la clave veremos que solicitará que aseguremos el acceso SSH:

no-password

 

Hacemos click en “Go to password configuration”:

Y configuramos la clave del usuario root:

openwrt-first

y el acceso SSH, luego presionan “SAVE & APPLY”:

save-apply

Y ya estamos listos para configurar, o para actualizar a la versión trunk “attitude adjustment”.

Actualizando a una nueva versión

descagar attitude_adjustment: http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Para actualizar se puede contar con varios modos, acá explicaré el modo SSH, el modo SCP (failsafe) y el modo Web

Modo Web

El modo web es muy sencillo, simplemente van a SYSTEM > FIRMWARE UPGRADE y cargan la versión de firmware que contenga la palabra “sysupgrade”:

system-flashing-openwrt

Vigilen los LEDs, cuando vean que el equipo esté completamente activado, verán que pierden el acceso Web, es porque hay un par de módulos que se deben activar “a mano” en esta versión de openWRT.

Acceso SSH:

  • Acceden por SSH al equipo 192.168.1.1 con el usuario “root” y la clave que le proporcionaron.

openwrt-ssh

Ejecutan los siguientes comandos:

opkg update
opkg install luci

/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

Y listo!, ya pueden acceder a la interfaz web.

Actualización via SSH

Podemos acceder vía SSH al TP-LINK y actualizarlo vía SSH

– Con acceso a Internet

Si es con acceso a Internet, simplemente, nos vamos al directorio TMP

root@OpenWrt:~# cd /tmp

Descargamos el FIRWMARE “sysupgrade” necesario:

root@OpenWrt:/tmp# wget -c http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin
Connecting to downloads.openwrt.org (78.24.191.177:80)
openwrt-ar71xx-gener 100% |*****************************************************************************************************| 2880k 0:00:00 ETA

Ejecutar la actualización:

root@OpenWrt:/tmp# sysupgrade -v /tmp/openwrt-ar71xx-generic-tl-wr741nd-v1-squashfs-sysupgrade.bin

Upgrade completed
Rebooting system…

Al finalizar el reboot, hacer un “cold reset” (desconectar la energía, esperar 10 segundos y reconectar).

Volver a conectarse vía SSH y activar la interfaz web:

opkg update
opkg install luci
/etc/init.d/uhttpd start
/etc/init.d/uhttpd enable

– Sin acceso a Internet

Si no cuentan con Internet, pero el firmware lo han descargado a un equipo al que están conectados alámbricamente entonces usan SCP para copiarlo a /tmp en el TP-LINK

root@OpenWRT:/tmp# scp -P 22 root@192.168.1.2:/home/jesuslara/Descargas/openwrt/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin .
Host ‘192.168.1.2’ is not in the trusted hosts file.
(ssh-rsa fingerprint md5 81:05:23:57:67:f5:bd:79:8a:08:2b:d9:eb:14:aa:00)
Do you want to continue connecting? (y/n) yes
root@192.168.1.2’s password:
openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin 100% 3840KB 768.0KB/s 00:05

Y actualizamos:

root@openWRT:/tmp# sysupgrade -v /tmp/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
Saving config files…
etc/sysctl.conf
etc/shells
etc/rc.local
etc/profile
etc/passwd
etc/inittab
etc/hosts
etc/group
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/dropbear_dss_host_key
etc/config/system
etc/config/firewall
etc/config/dropbear
etc/config/dhcp
killall: watchdog: no process killed
Failed to connect to ubus
Switching to ramdisk…
Performing system upgrade…
Unlocking firmware …
Writing from <stdin> to firmware … [w]
Upgrade completed
Rebooting system…
Connection closed by foreign host.

Igual que los anteriores, actualizamos el opkg update y accedemos vía web.

Modo Failsafe

El modo “failsafe” es un modo busybox que es útil para recuperación, incluso en modos cuando ningún acceso es posible, en los TP-LINK el modo FAILSAFE se logra de la siguiente manera:

  • Desconectar cualquier cable de red que se tenga conectado
  • Desconectar de la corriente, esperar 10 segundos
  • Volver a conectar, observando los LEDs
  • Cuando el LED “SYS” comienza a parpadear y antes de quedar fijo, presionar varias veces el botón QSS
  • El LED “SYS” comenzará a parpadear muy rápidamente “Flash-blinking”, están en modo FAILSAFE

Para conectarse al modo FAILSAFE, deberán configurar manualmente su interfaz eth0 a la subred 192.168.1.0, yo en Debian ejecuté:

  • Desactivé el network-manager (service network-manager stop)
  • ifconfig eth0 up && ifconfig eth0 192.168.1.2 netmask 255.255.255.0

Y nos conectamos vía Telnet:

root@tafil:~# telnet 192.168.1.1
Trying 192.168.1.1…
Connected to 192.168.1.1.
Escape character is ‘^]’.

=== IMPORTANT ============================
 Use 'passwd' to set your login password
 this will disable telnet and enable SSH
 ------------------------------------------
BusyBox v1.19.4 (2014-04-23 10:39:15 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ ________ __
 | |.-----.-----.-----.| | | |.----.| |_
 | - || _ | -__| || | | || _|| _|
 |_______|| __|_____|__|__||________||__| |____|
 |__| W I R E L E S S F R E E D O M
 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r40555)
 -----------------------------------------------------
 * 1/2 oz Galliano Pour all ingredients into
 * 4 oz cold Coffee an irish coffee mug filled
 * 1 1/2 oz Dark Rum with crushed ice. Stir.
 * 2 tsp. Creme de Cacao
 -----------------------------------------------------

A partir de acá, la actualización procederá igual al modo SSH con o sin Internet.

Acceso Web a la versión trunk

Por seguridad, al actualizar, openWRT les exigirá reconfigurar la clave y el acceso SSH (con su nueva interfaz):

password-openwrt-2

y SSH:

ssh-openwrt-2

Luego, ya podemos configurar la inalámbrica:

configure-wifi

Y listo!, en próxima entrega otros experimentos! …

PD: ¿Y el modo recovery?

Cuando me encontraba experimentando con las diversas versiones y hacks de openWRT (Gargoyle, “attitude adjustment”, etc) durante un proceso de upgrade hubo un bajón de electricidad (bueno, técnicamente se fue la luz en mi casa) y el TP-LINK había quedado en un estado “BRICK” (un gran ladrillo), con el botón SYS completamente colgado. Es allí cuando el modo “recovery” entra en operación.

Para ello, accedemos vía telnet tal como expliqué, no sin antes borrar todo en la memoria existente:

Primero, ejecutamos “firstboot”

root@(none):/# firstboot

This will erase all settings and remove any installed packages. Are you sure? [N/y]
y
/dev/mtdblock3 is not mounted, erasing it
erasing 0 10000
erasing 10000 10000
erasing 20000 10000
erasing 30000 10000
erasing 40000 10000
erasing 50000 10000
erasing 60000 10000
erasing 70000 10000
erasing 80000 10000
erasing 90000 10000
erasing a0000 10000
erasing b0000 10000
erasing c0000 10000
erasing d0000 10000
erasing e0000 10000
erasing f0000 10000
root@(none):/#

Cambiamos al directorio TMP

root@(none):/# cd /tmp

Luego, usamos SCP para copiar un firmware COMPLETO (no un sysupgrade) a /TMP:

root@(none):/tmp# scp -P 22 root@192.168.1.2:/home/jesuslara/Descargas/openwrt/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin .

/usr/bin/dbclient: Warning: failed creating /root/.ssh: Read-only file system

Host ‘192.168.1.2’ is not in the trusted hosts file.
(ssh-rsa fingerprint md5 81:05:23:57:67:f5:bd:79:8a:08:2b:d9:eb:14:aa:00)
Do you want to continue connecting? (y/n) yes
root@192.168.1.2’s password:
openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin 100% 3840KB 768.0KB/s 00:05

Y lo cargamos con sysupgrade:

root@(none):/tmp# sysupgrade -v /tmp/openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
Saving config files…
etc/sysctl.conf
etc/shells
etc/rc.local
etc/profile
etc/passwd
etc/inittab
etc/hosts
etc/group
etc/dropbear/dropbear_rsa_host_key
etc/dropbear/dropbear_dss_host_key
etc/config/system
etc/config/firewall
etc/config/dropbear
etc/config/dhcp
killall: watchdog: no process killed
Failed to connect to ubus
Switching to ramdisk…
Performing system upgrade…
Unlocking firmware …

Writing from <stdin> to firmware … [w]

Upgrade completed
Rebooting system…
Connection closed by foreign host.

El equipo “volverá a la vida” después de eso, de no ser así, podrían montar un TFTP y cargar el firmaware, usar MTD o incluso podrían fabricarse un cable USB-to-SERIAL para conectarse al TP-LINK (requiere algo de experiencia y soldadura!).

Incluso, podríamos usar el modo FAILSAFE para devolver el equipo a un firmware STOCK.

¿Qué más?

OpenWRT es bastante completo, lástima que su interfaz no sea “tan elaborada” como la de DD-WRT, sin embargo, tiene mucho más desarrollo (la versión TRUNK de mi TP-LINK es de Marzo de este año), por lo que sirve para tener cosas tan avanzadas como un kernel 3.3 o soporte a openFlow y openVswitch, entre otras.

En próximo artículo, VLANS y múltiples SSID.

 

¿Y DD-WRT?, si, también lo instalé en el TP-LINK, la forma de instalación es muy semejante … comenta si deseas que haga un artículo.

Happy Hacking!

 

 

 

Linux Disks: Rescatando data de un disco de portátil VIT de las garras de la muerte

Mil disculpas por tener abandonado el blog!, ciertamente el no tener portátil y trabajar con portátil prestada, me limita en las cosas que podría y/o debería hacer en el equipo, además el trabajo, múltiples ocupaciones hacen imposible dedicarle mucho tiempo a escribir …

Pero sucedió algo … ;-)

Me encontraba usando una portátil VIT (modelo 2400), en vista que mi anterior portátil Thinkpad fue robada en diciembre pasado, con el equipo todo iba bien salvo algunas cosas:

  • Ligeros congelamientos en el mousepad
  • Keycodes disparados (visibles en el dmesg) sin haber presionado ninguna tecla especial
  • Algunos problemas con la red
  • Incompatibilidad con Debian Jessie e imposibilidad de usar un kernel liquorix con la tarjeta inalámbrica que trae.

Bueno, todo iba bien con el equipo, hasta que un día, de improviso y sin siquiera avisarlo el smartctl, el disco duro se congeló!, el equipo literalmente se congeló por completo, una larga espera y tuve que apagarlo forzado.

Al encender, veo que insólitamente el BIOS ni siquiera ve el disco!, es decir, el disco duro se ha “esfumado”, tratando de “dilucidar” tan extraño comportamiento de la BIOS (imaginándola tal vez desactualizada y jamás dudando de un disco duro SATA3 de menos de un mes de uso), decido probar suerte y meto un Live-USB de Debian Installer.

Pero, por si acaso, presiono “TAB” para editar la entrada del “Advanced Options > Rescue Mode” y escribo:

idebus=66 pci=routeirq

La primera opción, hace que el disco funcione como un IDE-66 (PATA-compatible) y la segunda opción cuestiona la decisión de asignación de IRQ de la tarjeta madre y decide que el kernel la haga por si mismo (esto me permite en algunas tarjetas madre “buggy”, como la que usan en VIT, detectar hardware con problemas).

Insólito!, el disco aparece en el dmesg!

[ 2377.833672] end_request: I/O error, dev sdb, sector 4007
[ 2377.833689] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833695] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833708] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833745] end_request: I/O error, dev sdb, sector 4007
[ 2377.833767] sd 9:0:0:0: [sdb] Unhandled error code
[ 2377.833774] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2377.833784] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 0f a7 00 00 08 00
[ 2377.833820] end_request: I/O error, dev sdb, sector 4007
[ 2414.775081] sd 9:0:0:0: [sdb] Unhandled error code
[ 2414.775083] sd 9:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2414.775086] sd 9:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 41 00 00 02 00

Ahora bien,eso realmente no significa mucho, el disco da problemas de montaje, sin embargo, el DRIVER_OK me causa sospechas, ¿y si el disco está bueno, pero la lógica de comunicación de la tarjeta madre está operando mal?, entonces apago el equipo y reinicio el sistema de rescate, pero esta vez con dos opciones más:

libata.force=noncq libata.atapi_passthru16=0 idebus=66

Con la primera opción, fuerzo la desactivación del NCQ, es un sistema de cola de comandos de 32bits que utilizan los discos SATA y SSD más modernos para comunicarse con la tarjeta madre, un error en la lectura de comandos por parte de la controladora ATA puede “simular” un fallo de hardware y desactivar el disco; por ende, desactivar el NCQ puede ayudar a la controladora SATA a entender al disco duro.

La segunda opción, me permite tratar al disco como si fuera un viejo IDE, desactivando el soporte a comandos de 16 bits.

Con estas dos opciones, mágicamente el disco duro ahora es perfectamente detectado, he montado un disco externo, rescaté los datos a dicho disco externo y listo!, datos del disco duro “dado por muerto” rescatados.

¿y qué pasará con la portátil?

Aunque pudiera desactivar el modo AHCI en el BIOS y funcionar en modo IDE y pudiera luego pasar estas opciones en el GRUB, ciertamente estas opciones hacen que el disco vaya a muchísima menos velocidad que en condiciones normales, cómo la única posible solución documentada es una actualización del BIOS que le permita actualizar la tabla APCI y corregir el bug NCQ de la controladora ATA; será mejor devolver el equipo ya que al ser un equipo VIT ensamblado en Venezuela con piezas chinas, es poco probable que el proveedor de piezas de VIT haya sacado alguna “actualización de seguridad” del BIOS VIT.

Si a alguno le quedó el disco como “desaparecido del BIOS” en una VIT y necesitan con urgencia sacar unos datos, les indico que esta es la solución de resurrección más idónea.

Si alguien sabe como “actualizar” el BIOS de una VIT, me avisa …

Actualización

Luego de “despertar” al disco con “idebus=66 libata.force=noncq” y apagar inmediatamente el equipo, EL EQUIPO ENCENDIÓ!, normalmente, salvo que al llegar al GRUB, por precaución agregué ámbas opciones (idebus=66, libata.force=noncq) y pude llegar al GNOME para sacar sin apuro y con más vigilancia (y con un entorno gráfico) algunas cosas que no había respaldado.

Happy Hacking!

Desbloquear un Motorola Atrix 4G o ¿que consigo de menos de 100US$?

Los Motorola Atrix, a pesar de ser horrendos teléfonos (estéticamente hablando, por algo los Razr usan Kevlar para sus diseños, parecen un policía mal vestido), pasan a ser unos equipos dignos de cualquier “Geek” que se aprecie, con una relación precio/valor digna de considerar.

motorola-atrix-4g-mb860

Preámbulo

En las postrimerías de las elecciones de diciembre fui asaltado y despojado de mi viejito HTC Desire, que acababa de recibir una actualización CyanogenMod a 4.2 (Jelly Bean); pensando en el teléfono idóneo para adquirir pasé días analizando reviews, comparando dispositivos (haciendo uso de la herramienta comparativa de GSM-Arena):

comparativa-atrix-motog

 

Por ejemplo, me sorprendió que el más moderno (y popular) Moto G no tenga slot para SD y solo tenga una memoria interna de 16GB (exactamente igual que el Motorola Atrix que es 2 años más viejo); pero, lo que más me impulsó a adquirir este equipo fueron las siguientes:

  • Extraordinario bajo precio: lo adquirí en una subasta en ebay por algo más de 60US$, lo que me evitaba el pago de nacionalización excesiva y el pago por compras mayores a 100US$
  • CPU ARMx9 NVIDIA dual-core, con los tunnings adecuados, puede llevarse a 1.2Ghz y su GPU brinda un rendimiento claramente mejor que un GPU Adreno.
  • NO HAY DOLARES!, este es el gran suplicio de los venezolanos, no podemos andar por allí con un fajo de billetes diciendo “aja!, dame un Razr Maxx HD de 32GB y un Iphone 5C de respuesto”.
  • Super-hackeable!: Todos los dispositivos de la serie atrix traen algo conocido como “Webtop”, que permite correr un “mini-linux” cuando se conecta a un dispositivo conocido como lapdock:

Motorola Lapdock

Por ahora, me he comprometido a meterle Android o Kali Linux al Webtop, pero eso es otro artículo.

Preparativos

El equipo que adquirí es un equipo no desbloqueado de AT&T, la versión de Android “oficial” es la 2.3.6 (gingerbread) y el número de compilación de la SBF (ROM binaria oficial Motorola) es la 4.5.145 (tomen nota de esto, encontrarán muchas confusiones acerca de esto).

Al teléfono entonces hay que realizarle un conjunto de cosas en este orden:

  1. SIM-Unlock: o desbloqueo de SIM, AT&T y otros operadores no bloquean las radios de los equipos, sino las SIM-card, no es posible meterle una SIM de otro operador
  2. Desbloquear el bootloader (con esto, podemos instalar un sistema de recuperación -recovery- y una nueva ROM)
  3. Instalar un Android Recovery
  4. Instalar una ROM nueva
  5. Instalar las Google Apps

Necesitamos:

Recovery: http://forum.xda-developers.com/showthread.php?t=1204500
Custom CWM-based Recovery 5.0.2.7-atrix

Advertencia: ESTE PROCEDIMIENTO ELIMINA EL SISTEMA ANDROID DE FABRICA (STOCK), si desean simplemente darle “root” al teléfono y dejarlo con la ROM stock, este no es tu artículo, ¡go away!.

Paso 0: Cargar el teléfono

Esto parece un paso obvio, pero no lo es, algunos teléfonos Motorola tienen la “característica” de requerir más de lo 500 mili-amperios que proporcionan los cargadores USB-genéricos convencionales, sobre todo para la primera full-charge es necesario que la carga sea usando el cargador que viene oficialmente con el teléfono (o algún cargador de pared compatible).

Entonces, encendemos el equipo.

Paso 1: SIM-Lock

He cancelado 14US$ a una empresa que vende códigos de desbloqueo por SIM, hay varias, pero nota, no busquen las más “barateras”, porque te hacen perder tiempo (bueno, puede ser que tengas “suerte”), tardan como 3 ó 4 días en decirte que “no consiguieron el IMEI” y te devuelven el dinero, yo al final del día me he ido por “http://unlockthatphone.com/” y en cuestión de día y medio (pagué una noche y al mediodía del siguiente ya tenía el código) recibí el correo electrónico con el código de desbloqueo de la SIM.

Es un conjunto de números, simplemente encienden el equipo con la SIM-card de la operadora de su elección (en mi caso, Digitel), cuando les pida el código de desbloqueo, lo escriben y listo!.

Un tutorial con video, acá: http://imei24.net/Blog/2013/08/19/como-desbloquear-un-motorola-atrix-2-mb865-de-att/

Al terminar, apagamos el teléfono.

Paso 2: Arrancar en modo RSD Fastboot

El modo RSD (Remote Software Download) permite al usuario “cargar” software al teléfono, se usa por ejemplo, para cargar absolutamente TODO el firmware:

Listado de Firmware oficial disponible para Motorola Atrix 4G: http://sbf.droid-developers.org/phone.php?device=33

Bien, al poner el teléfono en modo RSD podemos “cargar” binarios de tipo SBF al teléfono, con ello podemos por ejemplo reemplazar el firmware de la radio o cargar todo el sistema completamente a su versión “stock”:

Si deseas descargar el último Firmware oficial de Motorola para Atrix 4G: http://sbf.droid-developers.org/download.php?device=33&file=742

NUNCA carguen ROM oficiales completas vía SBF, RSD tiene lectura directa sobre el dispositivo, un fallo en la carga generaría un HARD BRICK (tu teléfono se volvería inservible, y a diferencia de un “soft-brick” no hay manera humana de regresarlo de un hard brick).

Para iniciar el modo RSD Fastboot deberán presionar el botón de Volumen arriba (Volume Up) y el botón POWER a la vez:

y lo dejan presionado hasta que aparezca en la pantalla:

RSD Protocol Support

En este momento, conectamos al equipo vía USB.

Paso 3: Aplicar el SBF

Para permitir desbloquear el bootloader, tenemos primero que descargar el sbf_flash y el pudding en una carpeta de nuestro equipo, que ya debe tener por cierto ADB (Android Debug Bridge), aunque solamente necesitaremos fastboot.

Al estar en modo RSD el teléfono, abrimos una consola de root en nuestro GNU/Linux y nos vamos a la carpeta donde descargamos el sb_flash y el pudding, ejecutamos:

chmod +x sbf_flash

Y luego ejecutamos el “flash” del archivo SBF que estaba dentro del archivo pudding.zip:

./sbf_flash 4547-fix-try2.sbf

Verán en la consola algo como esto:

moto-sb1

El teléfono se pondrá en negro varias veces y luego se apagará, de no apagarse, caerá en modo fastboot.

NOTA: En este momento, si desconectan y apagan el equipo, al encenderlo dará un error “boot 0x001″ y la gente entra en pánico (he visto hilos enteros en xda-developers), uno como linuxero, es normal, simplemente NO TIENES UN SISTEMA OPERATIVO, no hay nada que arranque, solo el fastboot!, si haces comentarios acerca de que tu teléfono “no arranca” luego de hacer este paso, estás advertido.

NOTA otra vez: ¡insisto!, el teléfono NO VA A ARRANCAR NADA SALVO FASTBOOT, ¡dejen el trauma!.

Si se llega a apagar y no logran encenderlo el truco es:

  • sacar la batería
  • esperar unos segundos
  • meter la batería nuevamente
  • Arrancar en modo fastboot (Volumen Abajo + botón de encendido) (Volume Down + Power Button)

Ahora, vamos a desbloquear el bootloader!

Paso 4: Desbloqueo del Bootloader

Si conectamos nuevamente el equipo vía USB a nuestro computador con ADB ya instalado, podrán ejecutar el comando “fastboot devices” y verán algo como esto:

./fastboot devices
TA207013NS fastboot

Ejecutamos entonces el comando para solicitar el desbloqueo del bootloader:

 ./fastboot oem unlock

Retornará lo siguiente:

...
(bootloader) Unlocking your device can permanently VOID your warranty.
(bootloader) This process cannot be reversed. If you wish to proceed,
(bootloader) reissue the unlock OEM command containing the unique ID
(bootloader) of your device: 027C108040A002D7
OKAY [ 0.001s]
finished. total time: 0.010s

Es importante hacer notar que el comando retorna un identificador único de equipo (acá en negrillas), con ese ID único repetimos el comando:

./fastboot oem unlock 027C108040A002D7

Y la respuesta será:

...
(bootloader) Device is now unlocked
OKAY [ 7.459s]
finished. total time: 7.459s

Y en la pantalla verán algo como esto:

Untitled-2

Y listo!, ya podemos instalar el recovery.

Paso 5: Instalar el CWM Recovery

He instalado una versión personalizada del CWM para el Atrix 4G, la he descargado (un archivo .img) y usando fastboot utilizo los comandos de borrar el recovery actual:

./fastboot erase recovery

Y luego cargar el recovery con:

./fastboot flash recovery “ruta y nombre del archivo .img”

En mi caso, quedó así:

./fastboot flash recovery /home/jesuslara/android/motorola/recovery-dark-green-atrix5.img
sending 'recovery' (4708 KB)...
OKAY [ 0.250s]
writing 'recovery'...
OKAY [ 0.462s]
finished. total time: 0.712s

Y ya tenemos CWM Recovery instalado.

Apagamos el equipo.

Paso 6: Inicio de instalación de ROM

Para arrancar en modo “Android Recovery”, presionan “volumen abajo” y botón de encendido (volume down+power button), encenderá con una frase “unlocked” abajo, esperen hasta que salga la palabra “fastboot”, cuando salga, podrán cambiar de “fastboot” a “android recovery” presionando varias veces volumen abajo hasta que salga la frase “android recovery”, en lo que esta frase salga, presionan volumen arriba “Volume Up” para confirmar e iniciar el Android Recovery.

Ya en el CWM, es sencillo, este recovery utiliza los botones de volumen para navegar arriba y abajo, el botón de búsqueda es ENTER (SELECT), atrás se logra con el atrás físico (BACK) y las teclas “Menú” y “Home” pueden usarse como arriba y abajo (si no se desea usar los botones de volumen).

Allí, ejecutan las siguientes tareas:

Advanced > Upgrade to ext4

* osh (webtop partition)
* /system
* /data

Luego, Advanced > Wipe Dalvik Cache

Y por último, instalamos la ROM:

Install Zip from SDCard > Choose Zip from SD Card, navegar y seleccionar la ROM (en mi caso, se llama “cm-10.1-20131211-UNOFFICIAL-epinter-olympus.zip”)

Al finalizar, le damos atrás 2 veces y presionamos sobre la opción “reboot now”, y habremos completado la instalación de la ROM.

Paso 7: pre-configuración de la ROM y Google Apps

Al iniciar por primera vez, si lo desean pueden crearse una cuenta CyanogenMod (prestan servicios como “buscar tu teléfono” y otras cosas que se encontraban con la aplicación “MotoBlur”), posteriormente, entran al menú de aplicaciones, buscan en “Configuración” > “Acerca del Dispositivo” y presionen varias veces y rápidamente en la opción “número de compilación”, eso activará un menú oculto conocido como “Rendimiento”, que permite modificar algunas cosas avanzadas de Android (lo veremos después).

Luego de finalizados estos pasos, es hora de instalar las Google Apps.

Simplemente, presionan el botón POWER unos segundos para que salga el menú, escogen “Apagar” y listo. Volvemos a iniciar en modo Android Recovery.

Igual, seleccionan “Install Zip from SDCard” > “Choose Zip from SDCard”, navegan por la SD hasta encontrar el archivo “gapps-jb-20131207-olympus.zip” y listo.

NOTA: esta versión de Google Apps para Motorola Atrix no posee ni Google Now ni Hangouts, deberán ser instalados a mano desde Google Play.

Al reiniciar el equipo (que tarda un poco más mientras se “asienta” la ROM) se iniciará el asistente para configurar la cuenta Google.

 

Conclusiones

Es un equipo modesto, de prestaciones decentes, con algunas características muy interesantes (como Webtop) que fue abandonada por Motorola, que me permitirá volver a la vida digital con un equipo del que estoy seguro, me dará más de una idea loca que publicaremos por acá.

Happy Hacking!

La cadena de custodia: NSA y software libre

Han pasado dos noticias bastante interesantes en estos días, la primera, unas declaraciones de Kevin Mitnick, asegurando que la NSA había “Infiltrado” el código del PGP (Pretty-Good-Privacy), en la otra, que la NSA había “infiltrado” las decisiones para que el dispositivo generador de números aleatorios (/dev/random) del sistema Linux, dependiera del hardware, en este caso, de extensiones de hardware de CPUs Intel y AMD, comprometiendo la seguridad del núcleo …

¿Afectan estas noticias la credibilidad del software libre?, ¡al contrario!, veamos por qué.

Comprometidos con su seguridad …

Del PGP al GNU PG

PGP es un software “comercial” (y es “a ese software” al que hace referencia Mitnick), actualmente las patentes alrededor tanto de PGP como de los algoritmos de cifrado, están a cargo de Symantec, incluyendo el cifrado IDEA que hace uso PGP; en su lugar y gracias al uso de algoritmos libres (tanto de patentes, como limpios en sus especificaciones, como RSA-AES) se desarrolló GNU PG (GNU Privacy Guard) como una implementación de openPGP y que es la versión de PGP que utilizan TODAS las distribuciones de software libre a nivel mundial.

Hay que recordar de GNU PG dos historias claves, el caso del famoso bug detectado por la gente de Entrust de 2004, que causó la re-escritura de uno de los métodos de cifrado simétrico, el otro caso, en 2006, que fue detectado por la gente de seguridad de Gentoo Linux, y que (a diferencia de otros “bugs” de 10 años de duración en Windows), tardó en corregirse sólo 6 días.

Random Number Generator

Dilbert’s Random Number Generator

“/dev/random” es un pseudo-dispositivo de software, que existe en el núcleo Linux con el único propósito de proveer de una máquina generadora de números aleatorios, “/dev/random” hace uso de extensiones de hardware en los CPUs (Intel, AMD, Texas Instruments-ARM, etc) para poder generar números “pseudo-aleatorios” (se dice “pseudo”, porque al ser un computador un sistema determinista, hay una probabilidad remota de que los números no sean realmente aleatorios).

Al igual que con PGP, en Linux existe además “/dev/urandom”, la diferencia entre ellos es clave, el primero, basado en “entropía de hardware”, puede llegar a quedarse “exhausto” de bytes, por ende, esperará a llenar el pool de entropía para entregarte “más números aleatorios”, esto hace que “/dev/random” sea en consecuencia, más lento que “/dev/urandom”, que simplemente reutiliza la fuente de entropía una y otra vez para obtener más números aleatorios por software (es por esta razón que lleva la “U” adelante, de “unblock”, es decir, no se bloquea como /dev/random).

Entonces, ¿la decisión de Torvalds compromete la seguridad de algo?, ciertamente de las distribuciones de GNU/Linux en las que “/dev/random” utilice exclusivamente la entropía del CPU (que al sol de hoy y luego de los trabajos de Gutterman y Reinman en 2006, creo que ninguna); hay parches en Debian GNU/Linux (no aprobados en la LKML -Linux Kernel Mailing List-) que modifican /dev/random para hacer uso de más entropía como ioctl (movimiento del mouse, ruido del flujo de video, ruido del tráfico de la red, etc), dichos parches se aplican desde el 2006 por requerimiento de aplicaciones “precisamente” como GNU PG y GNU TLS.

Creo que incluso, después de “descubierto” el compromiso de las extensiones de CPU Intel por parte de la NSA, un simple “parche” será cosa de algunos días.

¿no creen?

Coneheads y la NSA llegó a mi casa …

Una vez alguien me escribió que iba a “desactivar SELINUX porque era un producto maléfico de la NSA”, además del hecho de existir varios miles de ojos dentro del código de SELinux (admitir que hay código malicioso dentro del núcleo Linux es contradecir expresamente lo que se defiende acerca de las 4 libertades que la FSF defiende a ultranza), es más que claro con el hecho de arriba (/dev/random no está comprometido, sino una de sus tantas fuentes de aleatoriedad, como lo son los CPU de Intel/AMD) que el software libre ha probado, una vez más, que se deben comprometer cosas “más oscuras” que el código, para empañar la seguridad del núcleo Linux (o de freeBSD,  por ejemplo).

De Intel se cree todo, por allá por la guerra del golfo, se distribuyó por la “conspironoosfera”, una *noticia* que indicó que todos los CPU Intel “chiflaron y se quemaron” dejando inútiles miles de computadoras en Bagdad, minutos antes de iniciar la invasión a Irak ¿posible?, 100%, ¿creible?, muy creíble … de la NSA espero todo.

Pero como indicara alguien en las listas de Fedora (precisamente a la respuesta de SELINUX y su relación con la NSA), cualquier relación con “desactivar SELinux porque lo hizo la NSA y fabricar conos de papel aluminio para “librarse de lectores mentales”, es pura coincidencia … “Los conos de papel aluminio se deben hacer de 2 caras, una cara reflectante hacia afuera, para evitar que “entren” cosas enviadas con rayos mentales por la NSA, pero también con papel reflectante “hacia adentro”, para evitar que la NSA use rayos mentales para leernos la mente, ah!, hay que evitar que haya un “corto-circuito” entre ámbas capas, para no quedar comprometido”.

Es decir, si el CPU (harware) es comprometido por alguna “instrucción maléfica”, no importa el sistema operativo que tengas encima, ¿no creen? …

Claro, ahí si caemos en la retórica de la “eterna conspiración”, podríamos indicar “ahh!, pero Selinux podría *restaurar* sus *troyanos* a través del compilador”, entonces les recuerdas al compilador libre GCC (GNU C), “Ahh!, pero segurito GCC usa extensiones de CPU y si te comprometen el CPU?”, bueno, ármate tu propia máquina! (empezando por el CPU) ¿para eso hay movimientos de hardware libre?, ¿no?; de llegar a pensar así (en esa eterna cadena conspiranóica), tendrías que ponerte como algunos conspiranóicos que hablan de IPv8 (¿no sale más fácil esto si quieres privacidad?) tendremos que vivir en cuevas, con nuestro propio hardware de computadora, nuestras propias redes, fabricando hasta nuestro propio cable (inmune a las ondas electromagnéticas que USA lanza regularmente antes de cualquier invasión), rodeando nuestras cabezas con conos de papel aluminio (bien diseñados, ¡por favor!) y evitando cualquier contacto con otro ser humano “sospechoso”.

Vivimos esta realidad, hay que enfrentarla … no tratar de volver a las cuevas y el oscurantismo …

Ideas sin patentar

Nunca me han gustado las patentes, ni su idea, ni su filosofía, siquiera su existencia misma, y no, no es envidia, no envidio al hombre que “patentó” la idea de hacerle ejercicio a un gato con un apuntador láser:

patent-cat-exercise

Ni la de “dispositivo portátil electrónico para enviar y recibir correos electrónicos” patentada en 1984 por RIM y es la causa de que aún no haya ido a la quiebra, gana más por regalías de esta patente que por sus propios productos, o incluso aquél hombre que “quizo” patentar como juguete el sable láser luego de la primera película de George Lucas en 1977 … y descubrir que George Lucas ya lo había patentado …

El punto es, que en 1984 RIM no construyó ningún teléfono que enviara y recibiera correo (ni siquiera había celulares), ni el primer teléfono “touchscreen sin botones” fue el iphone (fue de LG), como tampoco fue el primer ratón de Apple (fue de Xerox Palo Alto), la cosa es, la humanidad avanza sobre ideas, si alguien toma una idea mia y la mejora, está ayudando a la humanidad, si alguien gana más dinero que yo con una idea mia, es que yo realmente no supe verle el potencial que esa otra persona vió.

Proteger los derechos de autor (y liberar mi idea como a mi me de la gana, por ejemplo, con una licencia libre) es una cosa completamente distinta, estoy protegiendo algo que YO HICE, no algo que “tengo pensado hacer en algún futuro y voy a patentarlo para que nadie más lo haga, y si lo hacen lo jodo!”.

En el software libre, uno toma ideas, las mejora y luego pone las mejoras tanto a disposición del creador original, como de la comunidad, hay quienes no creen en esta fórmula, a veces, porque consideran que serán “robados”, otras, porque se subestiman imaginando que “más nunca” tendrán otra idea importante en sus vidas (como si hacerle ejercicio al gato fuera tan importante).

Tormenta de ideas libres

Un par de días atrás, me encontraba con unos amigos (@_seraph1, @willicab) discutiendo las posibilidades de automatizar algunas cosas en GNU/Linux (soy amante de la automatización y la pereza) y surgió una idea interesante, ¿te imaginas si uno pudiera “dibujar” la sub-red completa, algo como lo hacen “GNS3″ o “autonetkit” y que un script tomara ese “dibujo” y desplegara la solución completa vía contenedores LXC?; a partir de allí, a diferencia de muchos “empresarios”, no salí con folios de carpetas a “patentar” la idea, al contrario, me puse a contactar a otros amigos (@LuisAlejandro) a ver ¿qué cosas se le ocurrían?, Luis aportó muchísimo con la idea de, en vez de usar Java Jed, Inkscape o Dia, cree una sencilla aplicación “drag-n-drop” web con node-js y flask (o lo que se me ocurra), mientras contactaba amigos de otras latitudes como Walter Stanish (aka GlobalCitizen) para ver qué posibilidades había de hacerlo usando LXC.

Por allí surgió LXC-Tools > https://github.com/phenobarbital/lxc-tools

Gracias a Walter, tengo ahora una plantilla funcional para Gentoo, también una para CentOS 6 y gracias a Javier Lezcano, tengo una funcional para Debian, o gracias a los scripts de roles y hooks hechos por Steve Kemp de los Debian Xen-tools, ahora puedo post-configurar los contenedores LXC.

Gracias a una “chuleta” (en Venezolano, una guía para “copiarse”) de Luis Alejandro, estoy creando la plantilla para contenedores LXC Canaima, gracias a Sthefane Graber de Ubuntu llegan unas plantillas de Ubuntu Server 100% funcionales y gracias a los posts de Jonathan Carter en sudáfrica, voy a comenzar a usar la API de LXC en Python.

¿Se imaginan qué sería del mundo si todos “patentaramos” y “cerraramos filas” ante cada idea interesante que tengamos? … estaríamos, imagino yo, en una época victoriana maravillándonos de las posibilidades del vitriolo blanco y sus propiedades descritas por Platón.

“Liberando” un ejemplo

Es decir, vean este “ejemplo”:

E imaginen que esa imagen está en algún formato “libre” (SVG, graphML, xfig, etc), es extraordinariamente trivial, simular toda una suerte de VLANs en Linux (usando VLAN y 802.1q), simular un “soft-layer 3″ Switch, un Switch de capa-4 con load-balancing, usar openvswitch para los túneles y la comunicación fluída entre contenedores, y claro, usar LXC para crear y “simular” cada servicio (DNS, Web, FileServer, Directory, etc), el Firewall (ej: shorewall) e incluso, gracias a GNS3, se que puedo “emular” enrutadores Cisco usando QEMU y el ISO del software del mismo y con KVM puedo emular PCs con la distribución o incluso el sistema operativo que quiera.

¿Les parece una idea “patentable” o una idea para hacerla pública y que la gente empiece a colaborar para hacerla realidad? …

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.220 seguidores

A %d blogueros les gusta esto: