El software comercial viene de Estados Unidos y tiene nombre: Microsoft, Apple. Ellos abren puertas traseras en su software o hardware para espiarnos. Es necesario poder mantener la libertad de las comunicaciones, por lo que debemos hacer un cambio al software libre y adaptarnos a su uso, codificarlo y evitar que lean nuestras comunicaciones y revisen nuestros registros y operaciones.
Si ejecutas software libre en hardware propietario, tienes control sobre el hardware. Claro, eso siempre que el hardware sea programable y pensado para ser utilizado por un sistema operativo.
#8Si ejecutas software libre en hardware propietario, tienes control sobre el hardware. Claro, eso siempre que el hardware sea programable y pensado para ser utilizado por un sistema operativo.
El control que tienes sobre el hardware es el que el hardware te permite, ni más ni menos.
Nada impide que el hardware contenga piezas de software propietario no actualizable con puertas traseras que permitan acceso completo al sistema.
#13Pero eso no es una puerta trasera. La puerta trasera estará en el software que use esa tarjeta de red, el sistema operativo, lo cual incluye a los drivers.
Efectivamente, tal como yo mismo ya indiqué en #10: Nada impide que el hardware contenga piezas de software propietario no actualizable con puertas traseras que permitan acceso completo al sistema.
Y la única forma de conocer cuantas partes del hardware contienen software que se ejecute es conociendo el diseño de ese hardware.
En caso contrario la parte de software libre que se ejecute en el dispositivo puede ser solo una parte de todo el software que se ejecuta en ese dispositivo, por lo tanto tendríamos la ejecución de software libre y software propietario.
Podríamos pedir que todo el software de un dispositivo fuera software libre pero sin conocer el hardware debemos tener fe en que nos dicen la verdad cuando nos digan que nos han entregado todas las piezas de software que se ejecutan en él. Mientras que si disponemos del diseño del hardware podemos verificar si eso es cierto o no.
En ese contexto nos encontramos también por ejemplo con el caso del generador de números aleatorios que viene incorporado en procesadores y que fue sospechoso de contener una vulnerabilidad para generar números pseudoaleatorios. Por muy software libre que esté funcionando en el resto del dispositivo esa vulnerabilidad seguirá ahí.
Además, un volcado de memoria física a día de hoy puede suponer múltiples gigabytes que luego hay que transmitir por red. Un firmware no puede buscar nada concreto en un objetivo aleatorio. Contemplar esa posibilidad significa que el atacante debe dirigir su ofensiva hacia un punto muy concreto de un sistema muy concreto.
El dispositivo puede ejecutar el software libre en un contenedor de software propietario, obteniendo así control total sobre el sistema. No puedes conocer si eso ocurre o no a menos que conozcas cómo funciona el hardware del dispositivo.
Cuando ejecutas software libre en hardware propietario estás haciendo el acto de fe que ese dispositivo únicamente ejecutara el software que le has proporcionado y no otro que tenga internamente y que no puedas modificar. El cual puede contener puertas traseras.
Sólo tienes que echar un vistazo a las memorias ROM y flash que lleve integrados.
Al igual que con el software propietario basta con echar un vistazo a las llamadas al sistema que hace el código. Claro, varitas mágicas y eso.
Que se desconozca el diseño interno del hardware no supone ningún riesgo. Basta con hacer una inspección del PCB para averiguar si es seguro o no, y en cualquier caso existen mecanismos para evitar escuchas haciendo uso de cifrado.
Lo mismo puedes decir del software propietario, que basta con decompilarlo o esnifar su tráfico.
El dispositivo no puede ejecutar software libre en un contenedor hecho con software propietario. Es el software propietario el que ejecuta software libre. Eso se llama Hypervisor. Un Hypervisor es por ejemplo el de PlayStation 3 que fue vulnerado y desmenuzado.
¿Estás diciendo que las vulnerabilidades en un Hypervisor no suponen ningún riesgo para el software que corre en él? ¿O que un hardware propietario no puede ocultar un Hypervisor de código propietario?
Si tu eres incapaz de ver ningún riesgo en ejecutar tu software en un hardware desconocido es que para ti la seguridad es algo superficial.
Supongo que las conferencias black hat utilizarán varitas mágicas.
Supongo que existiendo las conferencias de black hat el software libre no aporta nada en el ámbito de seguridad.
No puedes decir lo mismo del software propietario. El software es varias órdenes de magnitud más complejo que el hardware para poder hacer un análisis mediante ingeniería inversa, existiendo de técnicas de ofuscación de código. La comparación carece de sentido.
Osea que es lo mismo. Gracias por confirmarlo.
¿Estás diciendo que la mermelada es salada o que la sal contiene mermelada? No lo sé, tú tampoco.
Bien, por fin admites el problema.
Es obvio que no hay riesgos directos.
Yo no he dicho ni que fuesen directos ni indirectos. Hay riesgos, por lo tanto para la seguridad es tan necesario el software libre como el hardware libre.
¿Eres incapaz de ver la diferencia? No compares ejecutar software privativo con utilizar software libre sobre hardware de diseño cerrado.
Claro que veo las diferencias y las similitudes. Y no, yo no he comparado ejecutar software privativo con software libre sobre hardware propietario, sino ejecutar software libre sobre hardware libre y software libre sobre hardware propietario.
Y ya lo he dicho al principio: El software libre es necesario, pero también el hardware libre.
NO HAY PUNTO DE COMPARACIÓN.
Ni falta que hace, no necesitamos elegir entre lo uno o lo otro sino que debemos reclamar ambos.
El generador de números aleatorios no es vulnerabilidad de ningún tipo. Un generador de números aleatorios defectuoso no es una puerta trasera ni tampoco es una vulnerabilidad. Por definición. No mezclemos churras con merinas.
Efectivamente. Y la única forma de conocer cuantas partes del hardware contienen software que se ejecute es conociendo el diseño de ese hardware.
Sólo tienes que echar un vistazo a las memorias ROM y flash que lleve integrados. Por otra parte la frase que te cito y respondo no tiene nada que ver con lo que tu citaste de mi comentario. Trolecito de tres al cuarto.
El dispositivo no puede ejecutar software libre en un contenedor hecho con software propietario. Es el software propietario el que ejecuta software libre. Eso se llama Hypervisor. Un Hypervisor es por ejemplo el de PlayStation 3 que fue vulnerado y desmenuzado.
Que se desconozca el diseño interno del hardware no supone ningún riesgo. Basta con hacer una inspección del PCB para averiguar si es seguro o no, y en cualquier caso existen mecanismos para evitar escuchas haciendo uso de cifrado. Además, que una parte del sistema sea potencialmente maliciosa no es un problema. Por ejemplo: This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.
Si el software libre no emplea el protocolo de comunicación no hay peligro. Si el software libre no colabora con el hardware de una forma potencialmente insegura, no hay problema.
Al igual que con el software propietario basta con echar un vistazo a las llamadas al sistema que hace el código. Claro, varitas mágicas y eso.
Supongo que las conferencias black hat utilizarán varitas mágicas.
Lo mismo puedes decir del software propietario, que basta con decompilarlo o esnifar su tráfico.
No puedes decir lo mismo del software propietario. El software es varias órdenes de magnitud más complejo que el hardware para poder hacer un análisis mediante ingeniería inversa, existiendo de técnicas de ofuscación de código. La comparación carece de sentido.
¿Estás diciendo que las vulnerabilidades en un Hypervisor no suponen ningún riesgo para el software que corre en él? ¿O que un hardware propietario no puede ocultar un Hypervisor de código propietario?
¿Estás diciendo que la mermelada es salada o que la sal contiene mermelada? No lo sé, tú tampoco.
Si tu eres incapaz de ver ningún riesgo en ejecutar tu software en un hardware desconocido es que para ti la seguridad es algo superficial.
Es obvio que no hay riesgos directos. ¿Eres incapaz de ver la diferencia? No compares ejecutar software privativo con utilizar software libre sobre hardware de diseño cerrado. NO HAY PUNTO DE COMPARACIÓN.
Desde la ignorancia pregunto esperando que alguien me explique: ¿Los que no tenemos ni idea de programación para protegernos qué alternativa tenemos? ¿Acaso el software libre no se puede hackear también?
#9¿Los que no tenemos ni idea de programación para protegernos qué alternativa tenemos?
El mero hecho que sea software libre es disuasorio. Una empresa difícilmente publicará el código fuente de una puerta trasera.
Puede ocurrir pero es menos probable que si el software es propietario.
De todas formas hay que tener en cuenta que entre el código fuente publicado y que tú puedas usarlo hay varios pasos, en cualquiera de ellos se pueden incluir las partes maliciosas.
Si por ejemplo el fabricante publica un firmware de tu teléfono móvil es muy complicado verificar si ese firmware se corresponde al código fuente publicado o bien le han introducido cambios. Por ello para esos casos se necesitaría hacer uso de procesos de compilación determinísticos, de forma que cualquiera pueda compilar ese mismo código y obtenga el mismo archivo publicado siendo ambos idénticos (el mismo código fuente puede producir dos binarios distintos).
Y finalmente está el paso al hardware, si subes ese firmware a un hardware de tipo propietario no puedes saber si hay algo escondido ahí dentro que pueda actuar de puerta trasera. El software está supeditado a lo que el hardware le permita hacer.
¿Acaso el software libre no se puede hackear también?
Si contiene errores sí, lo que supuestamente se evita son las puertas traseras intencionales. Si se esfuerzan mucho pueden disimular la puerta trasera como un error de programación pero eso no es en absoluto sencillo.
Y menos en referencia a la privacidad, que requeriría de subir información del usuario a servidores públicos.
En cualquier caso si el código está publicado se puede exigir que se corrija ese error y ver si efectivamente cierran esa vulnerabilidad o no.
En conclusión, el software libre es una pieza del conjunto y aunque ciertamente únicamente es útil para expertos los no expertos se ven indirectamente beneficiados por el hecho que otros puedan hacer esa revisión y publicar lo que encuentren.
#11 Gracias, aunque reconozco que no logro entender por completo tu explicación porque como te digo no tengo ni idea de estas cosas, con la conclusión me ha quedado más clara mi duda.
El hardware por sí mismo no puede contener puertas traseras. Según tu definición una tarjeta de red es una puerta trasera en sí misma. Puede ser explotada por cualquier dispositivo conectado a Internet. Pero eso no es una puerta trasera. La puerta trasera estará en el software que use esa tarjeta de red, el sistema operativo, lo cual incluye a los drivers.
El hardware por sí mismo no puede identificar datos aleatoriamente. Tiene que ser concebido para un propósito específico con un objetivo específico. Y eso incluye al mismo firmware.
Así que no, el software no está supeditado a lo que el hardware le permita hacer. Es más bien al contrario, el hardware es controlado por el software.
http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor
The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices to be inherently bad targets because of this back-door.
Como puedes observar el software controla al hardware incluyendo el módem, que lleva un procesador. Además, en plataformas IA32/AMD64 existe el uso de las IOMMU que permiten al sistema operativo proteger la memoria entre dispositivos como se hace entre procesos, por lo que volcar la memoria física resulta imposible si no es mediante target de una vulnerabilidad concreta de un sistema operativo concreto. Por otra parte, resulta imposible acceder a la memoria y datos de otro dispositivo, por ejemplo de un disco duro. Los mecanismos de acceso a memoria son de acceso a memoria principal no a otros dispositivos que vete a saber tú qué interfaz tienen.
Además, un volcado de memoria física a día de hoy puede suponer múltiples gigabytes que luego hay que transmitir por red. Un firmware no puede buscar nada concreto en un objetivo aleatorio. Contemplar esa posibilidad significa que el atacante debe dirigir su ofensiva hacia un punto muy concreto de un sistema muy concreto.
Comentarios
El software libre es necesario, pero también el hardware libre.
#2 Y la cerveza libre. Yo además la tomo por convicciones religiosas, así que es un producto de primera necesidad.
#3 #4 ¿Estáis confundiendo libre con gratis?
Si ejecutas software libre en hardware de tipo propietario no puedes saber con certeza si existen puertas traseras o vulnerabilidades.
#6 Y si bebes cerveza libre en vez de cerveza propietaria?
#4 #6 Dicen que está buena la cerveza libre http://es.wikipedia.org/wiki/Free_Beer
Si ejecutas software libre en hardware propietario, tienes control sobre el hardware. Claro, eso siempre que el hardware sea programable y pensado para ser utilizado por un sistema operativo.
#8 Si ejecutas software libre en hardware propietario, tienes control sobre el hardware. Claro, eso siempre que el hardware sea programable y pensado para ser utilizado por un sistema operativo.
El control que tienes sobre el hardware es el que el hardware te permite, ni más ni menos.
Nada impide que el hardware contenga piezas de software propietario no actualizable con puertas traseras que permitan acceso completo al sistema.
#13 Pero eso no es una puerta trasera. La puerta trasera estará en el software que use esa tarjeta de red, el sistema operativo, lo cual incluye a los drivers.
Efectivamente, tal como yo mismo ya indiqué en #10: Nada impide que el hardware contenga piezas de software propietario no actualizable con puertas traseras que permitan acceso completo al sistema.
Y la única forma de conocer cuantas partes del hardware contienen software que se ejecute es conociendo el diseño de ese hardware.
En caso contrario la parte de software libre que se ejecute en el dispositivo puede ser solo una parte de todo el software que se ejecuta en ese dispositivo, por lo tanto tendríamos la ejecución de software libre y software propietario.
Podríamos pedir que todo el software de un dispositivo fuera software libre pero sin conocer el hardware debemos tener fe en que nos dicen la verdad cuando nos digan que nos han entregado todas las piezas de software que se ejecutan en él. Mientras que si disponemos del diseño del hardware podemos verificar si eso es cierto o no.
En ese contexto nos encontramos también por ejemplo con el caso del generador de números aleatorios que viene incorporado en procesadores y que fue sospechoso de contener una vulnerabilidad para generar números pseudoaleatorios. Por muy software libre que esté funcionando en el resto del dispositivo esa vulnerabilidad seguirá ahí.
Además, un volcado de memoria física a día de hoy puede suponer múltiples gigabytes que luego hay que transmitir por red. Un firmware no puede buscar nada concreto en un objetivo aleatorio. Contemplar esa posibilidad significa que el atacante debe dirigir su ofensiva hacia un punto muy concreto de un sistema muy concreto.
El dispositivo puede ejecutar el software libre en un contenedor de software propietario, obteniendo así control total sobre el sistema. No puedes conocer si eso ocurre o no a menos que conozcas cómo funciona el hardware del dispositivo.
Cuando ejecutas software libre en hardware propietario estás haciendo el acto de fe que ese dispositivo únicamente ejecutara el software que le has proporcionado y no otro que tenga internamente y que no puedas modificar. El cual puede contener puertas traseras.
Sólo tienes que echar un vistazo a las memorias ROM y flash que lleve integrados.
Al igual que con el software propietario basta con echar un vistazo a las llamadas al sistema que hace el código. Claro, varitas mágicas y eso.
Que se desconozca el diseño interno del hardware no supone ningún riesgo. Basta con hacer una inspección del PCB para averiguar si es seguro o no, y en cualquier caso existen mecanismos para evitar escuchas haciendo uso de cifrado.
Lo mismo puedes decir del software propietario, que basta con decompilarlo o esnifar su tráfico.
El dispositivo no puede ejecutar software libre en un contenedor hecho con software propietario. Es el software propietario el que ejecuta software libre. Eso se llama Hypervisor. Un Hypervisor es por ejemplo el de PlayStation 3 que fue vulnerado y desmenuzado.
¿Estás diciendo que las vulnerabilidades en un Hypervisor no suponen ningún riesgo para el software que corre en él? ¿O que un hardware propietario no puede ocultar un Hypervisor de código propietario?
Si tu eres incapaz de ver ningún riesgo en ejecutar tu software en un hardware desconocido es que para ti la seguridad es algo superficial.
Supongo que las conferencias black hat utilizarán varitas mágicas.
Supongo que existiendo las conferencias de black hat el software libre no aporta nada en el ámbito de seguridad.
No puedes decir lo mismo del software propietario. El software es varias órdenes de magnitud más complejo que el hardware para poder hacer un análisis mediante ingeniería inversa, existiendo de técnicas de ofuscación de código. La comparación carece de sentido.
Osea que es lo mismo. Gracias por confirmarlo.
¿Estás diciendo que la mermelada es salada o que la sal contiene mermelada? No lo sé, tú tampoco.
Bien, por fin admites el problema.
Es obvio que no hay riesgos directos.
Yo no he dicho ni que fuesen directos ni indirectos. Hay riesgos, por lo tanto para la seguridad es tan necesario el software libre como el hardware libre.
¿Eres incapaz de ver la diferencia? No compares ejecutar software privativo con utilizar software libre sobre hardware de diseño cerrado.
Claro que veo las diferencias y las similitudes. Y no, yo no he comparado ejecutar software privativo con software libre sobre hardware propietario, sino ejecutar software libre sobre hardware libre y software libre sobre hardware propietario.
Y ya lo he dicho al principio: El software libre es necesario, pero también el hardware libre.
NO HAY PUNTO DE COMPARACIÓN.
Ni falta que hace, no necesitamos elegir entre lo uno o lo otro sino que debemos reclamar ambos.
Y hay quién vota esto irrelevante?! Yo flipo.
Por eso se le suele ver usando macs con tanta frecuencia
a por el software libreeeeeeeeeee..
El generador de números aleatorios no es vulnerabilidad de ningún tipo. Un generador de números aleatorios defectuoso no es una puerta trasera ni tampoco es una vulnerabilidad. Por definición. No mezclemos churras con merinas.
Efectivamente. Y la única forma de conocer cuantas partes del hardware contienen software que se ejecute es conociendo el diseño de ese hardware.
Sólo tienes que echar un vistazo a las memorias ROM y flash que lleve integrados. Por otra parte la frase que te cito y respondo no tiene nada que ver con lo que tu citaste de mi comentario. Trolecito de tres al cuarto.
El dispositivo no puede ejecutar software libre en un contenedor hecho con software propietario. Es el software propietario el que ejecuta software libre. Eso se llama Hypervisor. Un Hypervisor es por ejemplo el de PlayStation 3 que fue vulnerado y desmenuzado.
Que se desconozca el diseño interno del hardware no supone ningún riesgo. Basta con hacer una inspección del PCB para averiguar si es seguro o no, y en cualquier caso existen mecanismos para evitar escuchas haciendo uso de cifrado. Además, que una parte del sistema sea potencialmente maliciosa no es un problema. Por ejemplo: This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.
Si el software libre no emplea el protocolo de comunicación no hay peligro. Si el software libre no colabora con el hardware de una forma potencialmente insegura, no hay problema.
Dos no se pelan si uno no quiere.
Al igual que con el software propietario basta con echar un vistazo a las llamadas al sistema que hace el código. Claro, varitas mágicas y eso.
Supongo que las conferencias black hat utilizarán varitas mágicas.
Lo mismo puedes decir del software propietario, que basta con decompilarlo o esnifar su tráfico.
No puedes decir lo mismo del software propietario. El software es varias órdenes de magnitud más complejo que el hardware para poder hacer un análisis mediante ingeniería inversa, existiendo de técnicas de ofuscación de código. La comparación carece de sentido.
¿Estás diciendo que las vulnerabilidades en un Hypervisor no suponen ningún riesgo para el software que corre en él? ¿O que un hardware propietario no puede ocultar un Hypervisor de código propietario?
¿Estás diciendo que la mermelada es salada o que la sal contiene mermelada? No lo sé, tú tampoco.
Si tu eres incapaz de ver ningún riesgo en ejecutar tu software en un hardware desconocido es que para ti la seguridad es algo superficial.
Es obvio que no hay riesgos directos. ¿Eres incapaz de ver la diferencia? No compares ejecutar software privativo con utilizar software libre sobre hardware de diseño cerrado. NO HAY PUNTO DE COMPARACIÓN.
Desde la ignorancia pregunto esperando que alguien me explique: ¿Los que no tenemos ni idea de programación para protegernos qué alternativa tenemos? ¿Acaso el software libre no se puede hackear también?
#9 ¿Los que no tenemos ni idea de programación para protegernos qué alternativa tenemos?
El mero hecho que sea software libre es disuasorio. Una empresa difícilmente publicará el código fuente de una puerta trasera.
Puede ocurrir pero es menos probable que si el software es propietario.
De todas formas hay que tener en cuenta que entre el código fuente publicado y que tú puedas usarlo hay varios pasos, en cualquiera de ellos se pueden incluir las partes maliciosas.
Si por ejemplo el fabricante publica un firmware de tu teléfono móvil es muy complicado verificar si ese firmware se corresponde al código fuente publicado o bien le han introducido cambios. Por ello para esos casos se necesitaría hacer uso de procesos de compilación determinísticos, de forma que cualquiera pueda compilar ese mismo código y obtenga el mismo archivo publicado siendo ambos idénticos (el mismo código fuente puede producir dos binarios distintos).
Y finalmente está el paso al hardware, si subes ese firmware a un hardware de tipo propietario no puedes saber si hay algo escondido ahí dentro que pueda actuar de puerta trasera. El software está supeditado a lo que el hardware le permita hacer.
¿Acaso el software libre no se puede hackear también?
Si contiene errores sí, lo que supuestamente se evita son las puertas traseras intencionales. Si se esfuerzan mucho pueden disimular la puerta trasera como un error de programación pero eso no es en absoluto sencillo.
Y menos en referencia a la privacidad, que requeriría de subir información del usuario a servidores públicos.
En cualquier caso si el código está publicado se puede exigir que se corrija ese error y ver si efectivamente cierran esa vulnerabilidad o no.
En conclusión, el software libre es una pieza del conjunto y aunque ciertamente únicamente es útil para expertos los no expertos se ven indirectamente beneficiados por el hecho que otros puedan hacer esa revisión y publicar lo que encuentren.
#11 Gracias, aunque reconozco que no logro entender por completo tu explicación porque como te digo no tengo ni idea de estas cosas, con la conclusión me ha quedado más clara mi duda.
El hardware por sí mismo no puede contener puertas traseras. Según tu definición una tarjeta de red es una puerta trasera en sí misma. Puede ser explotada por cualquier dispositivo conectado a Internet. Pero eso no es una puerta trasera. La puerta trasera estará en el software que use esa tarjeta de red, el sistema operativo, lo cual incluye a los drivers.
El hardware por sí mismo no puede identificar datos aleatoriamente. Tiene que ser concebido para un propósito específico con un objetivo específico. Y eso incluye al mismo firmware.
Así que no, el software no está supeditado a lo que el hardware le permita hacer. Es más bien al contrario, el hardware es controlado por el software.
Para muestra, un botón: https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor
http://redmine.replicant.us/projects/replicant/wiki/SamsungGalaxyBackdoor
The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices to be inherently bad targets because of this back-door.
Como puedes observar el software controla al hardware incluyendo el módem, que lleva un procesador. Además, en plataformas IA32/AMD64 existe el uso de las IOMMU que permiten al sistema operativo proteger la memoria entre dispositivos como se hace entre procesos, por lo que volcar la memoria física resulta imposible si no es mediante target de una vulnerabilidad concreta de un sistema operativo concreto. Por otra parte, resulta imposible acceder a la memoria y datos de otro dispositivo, por ejemplo de un disco duro. Los mecanismos de acceso a memoria son de acceso a memoria principal no a otros dispositivos que vete a saber tú qué interfaz tienen.
Además, un volcado de memoria física a día de hoy puede suponer múltiples gigabytes que luego hay que transmitir por red. Un firmware no puede buscar nada concreto en un objetivo aleatorio. Contemplar esa posibilidad significa que el atacante debe dirigir su ofensiva hacia un punto muy concreto de un sistema muy concreto.
cc #12.
Y la energia también que coño!!!