5 ms·

Probably a fair amount. 10? How much memory do you think you need per exploit if you have a carefully coded C program that uses system libraries?

akira2501 13y ago
To me it depends; a simple exploit, sure. The air-gapped ip over bare audio seems like it would take a fair amount of processing on its own, unless the system libraries provide signal analysis functions. Also, unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well.
- nitrogen 13y ago
  Look at the 4KB demo scene from the early PC era to see just what is possible with sound and video in a tiny amount of space. Audio processing algorithms can be extremely simple and tiny.
- OvidNaso 13y ago
  This is way out of my league and maybe not relevant at all, but the Demoscene has forever changed how much I think about what can be accomplished with tiny amount of code. https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene
- Amadou 13y ago
  unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well. I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues. The other option is that you don't have to do full tcp/ip over the "audio link" since it would only be used for specific types of traffic. If you control how the sender transmits you can ditch a ton of the tcp/ip logic and just hardcode to a minimalist subset of functionality.
  - lawnchair_larry 13y ago
    > I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues. Ignoring that this doesn't make any sense as a symptom for communication over an audio channel - the whole reason he believes that it is communicating is because a packet counter increased. Not because he has any logs, or because he observed it being controlled, or because he saw any code doing this. Why are we even discussing the feasibility of the covert channel if the only reason that this topic was even introduced was because he saw packet counts increasing? I can think of a million benign reasons why packet counts would increase on an unplugged system. That in no way means that the system is compromised or communicating externally. It's not even a reason to be suspicious.
    - Amadou 13y ago
      if the only reason that this topic was even introduced was because he saw packet counts increasing? He saw packet counts increasing and it stopped when he disabled the audio hardware. Then there is all the other circumstantial evidence regarding booting from a CD, "self-healing" and systemic blocking of his debug attempts. I think it is absolutely fair to critique the individual symptoms but the one critique that doesn't fly is that an individual symptom is the only symptom. Ignoring that this doesn't make any sense as a symptom for communication over an audio channel In what way does that not make sense?
      - tedunangst 13y ago
        Was the audio hardware disabled on a live system? Or was the computer turned off first?
      - lawnchair_larry 13y ago
        > He saw packet counts increasing and it stopped when he disabled the audio hardware. I guess if you think that detail adds meaning, there's not much I can say. > Then there is all the other circumstantial evidence regarding booting from a CD This is extremely common. Macs have had flaky CD booting issues for ages. https://discussions.apple.com/thread/4292694 https://discussions.apple.com/thread/4292694 "After doing a software update, my Mac Pro got stuck on the gray screen after restart (seems like a very common problem recently). I am able to boot into safe mode by holding shift (only works like 10% of the time) and verified permissions. It says I need to repair my disk, but i can only do this by booting from my install disk. However, I can not boot from my install disk. It gets stuck at the gray screen every single time." > "self-healing" Didn't happen. Because there was nothing to self-heal. > and systemic blocking of his debug attempts. It didn't block any debug attempts. He says it disappears on him when he goes to look at it. That's because it isn't there. That's like saying the ghost beside me is evading my photography attempts, and citing this evasion as proof that something is up. > In what way does that not make sense? Beeps on the speakers or listening on the mic doesn't involve packets to begin with! Even if that was true, it wouldn't make packet counts go up. You would have to go out of your way to implement this in the stupidest possible way for your audio channel to have anything to do with a network interface. Compared to the obvious way, it would take way more code, completely ruin your stealth, be far less reliable, and add a ton of packet header overhead over what is already extremely low bandwidth. You cannot be smart enough to implement this malware and also be stupid enough to put your covert channel through network interfaces. Yet we are supposed to believe it's so stealthy that no debugging tools can see it ever, and it's disappearing from low level memory accesses and disk reads wherever he looks for it. But it's spewing packets out on an interface that it doesn't actually need to communicate. I mean...really?
- tavish1 13y ago
  Why do you need IP over airgap? A basic carrier sense scheme with maybe a 44khz fft can ensure atleast a slow speed networking even an arduino with 16kb(or probably even 8kb) flash can do this. This isnt like wifi where you would need complex signal analysis.
discardorama 13y ago
> How much memory do you think you need per exploit if you have a carefully coded C program that uses system libraries? .... except, at the BIOS level, there aren't many "system libraries". It's basically bare metal.
- pgeorgi 13y ago
  Except that UEFI has "system libraries" (among others for IPv4/v6 networking) that can be used after an OpenProtocol call. In the future, AMI might add some OpenGL interfaces, too (see http://www.uefi.org/sites/default/files/resources/8_-_UEFI_Summit_AMI_July_2012v4.pdf http://www.uefi.org/sites/default/files/resources/8_-_UEFI_S...)
- bigiain 13y ago
  For a different perspective, and Arduino (Uno) has 32kb of available RAM (minus a tiny bot used by the bootloader). There's a tremendous amount of projects demonstrating amazing things that can be done with much less computing resources available than a BIOS. I have _very_ little doubt that bit-twiddled 12-20kHz audio communication could easily be implemented in under 10% of the 383kB that seems to be available. (Assuming the speaker and microphone are available as GPIO-like interfaces to the BIOS/CPU.)

akira2501 13y ago

To me it depends; a simple exploit, sure. The air-gapped ip over bare audio seems like it would take a fair amount of processing on its own, unless the system libraries provide signal analysis functions. Also, unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well.

nitrogen 13y ago
Look at the 4KB demo scene from the early PC era to see just what is possible with sound and video in a tiny amount of space. Audio processing algorithms can be extremely simple and tiny.
OvidNaso 13y ago
This is way out of my league and maybe not relevant at all, but the Demoscene has forever changed how much I think about what can be accomplished with tiny amount of code. https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene
Amadou 13y ago
unless it can just decode raw bits and somehow shuffle them to the network layer of one of the existing adapters you're going to need quite a bit of code to handle that part of it as well. I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues. The other option is that you don't have to do full tcp/ip over the "audio link" since it would only be used for specific types of traffic. If you control how the sender transmits you can ditch a ton of the tcp/ip logic and just hardcode to a minimalist subset of functionality.
- lawnchair_larry 13y ago
  > I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues. Ignoring that this doesn't make any sense as a symptom for communication over an audio channel - the whole reason he believes that it is communicating is because a packet counter increased. Not because he has any logs, or because he observed it being controlled, or because he saw any code doing this. Why are we even discussing the feasibility of the covert channel if the only reason that this topic was even introduced was because he saw packet counts increasing? I can think of a million benign reasons why packet counts would increase on an unplugged system. That in no way means that the system is compromised or communicating externally. It's not even a reason to be suspicious.
  - Amadou 13y ago
    if the only reason that this topic was even introduced was because he saw packet counts increasing? He saw packet counts increasing and it stopped when he disabled the audio hardware. Then there is all the other circumstantial evidence regarding booting from a CD, "self-healing" and systemic blocking of his debug attempts. I think it is absolutely fair to critique the individual symptoms but the one critique that doesn't fly is that an individual symptom is the only symptom. Ignoring that this doesn't make any sense as a symptom for communication over an audio channel In what way does that not make sense?
    - tedunangst 13y ago
      Was the audio hardware disabled on a live system? Or was the computer turned off first?
    - lawnchair_larry 13y ago
      > He saw packet counts increasing and it stopped when he disabled the audio hardware. I guess if you think that detail adds meaning, there's not much I can say. > Then there is all the other circumstantial evidence regarding booting from a CD This is extremely common. Macs have had flaky CD booting issues for ages. https://discussions.apple.com/thread/4292694 https://discussions.apple.com/thread/4292694 "After doing a software update, my Mac Pro got stuck on the gray screen after restart (seems like a very common problem recently). I am able to boot into safe mode by holding shift (only works like 10% of the time) and verified permissions. It says I need to repair my disk, but i can only do this by booting from my install disk. However, I can not boot from my install disk. It gets stuck at the gray screen every single time." > "self-healing" Didn't happen. Because there was nothing to self-heal. > and systemic blocking of his debug attempts. It didn't block any debug attempts. He says it disappears on him when he goes to look at it. That's because it isn't there. That's like saying the ghost beside me is evading my photography attempts, and citing this evasion as proof that something is up. > In what way does that not make sense? Beeps on the speakers or listening on the mic doesn't involve packets to begin with! Even if that was true, it wouldn't make packet counts go up. You would have to go out of your way to implement this in the stupidest possible way for your audio channel to have anything to do with a network interface. Compared to the obvious way, it would take way more code, completely ruin your stealth, be far less reliable, and add a ton of packet header overhead over what is already extremely low bandwidth. You cannot be smart enough to implement this malware and also be stupid enough to put your covert channel through network interfaces. Yet we are supposed to believe it's so stealthy that no debugging tools can see it ever, and it's disappearing from low level memory accesses and disk reads wherever he looks for it. But it's spewing packets out on an interface that it doesn't actually need to communicate. I mean...really?
tavish1 13y ago
Why do you need IP over airgap? A basic carrier sense scheme with maybe a 44khz fft can ensure atleast a slow speed networking even an arduino with 16kb(or probably even 8kb) flash can do this. This isnt like wifi where you would need complex signal analysis.

discardorama 13y ago

> How much memory do you think you need per exploit if you have a carefully coded C program that uses system libraries? .... except, at the BIOS level, there aren't many "system libraries". It's basically bare metal.

pgeorgi 13y ago
Except that UEFI has "system libraries" (among others for IPv4/v6 networking) that can be used after an OpenProtocol call. In the future, AMI might add some OpenGL interfaces, too (see http://www.uefi.org/sites/default/files/resources/8_-_UEFI_Summit_AMI_July_2012v4.pdf http://www.uefi.org/sites/default/files/resources/8_-_UEFI_S...)
bigiain 13y ago
For a different perspective, and Arduino (Uno) has 32kb of available RAM (minus a tiny bot used by the bootloader). There's a tremendous amount of projects demonstrating amazing things that can be done with much less computing resources available than a BIOS. I have _very_ little doubt that bit-twiddled 12-20kHz audio communication could easily be implemented in under 10% of the 383kB that seems to be available. (Assuming the speaker and microphone are available as GPIO-like interfaces to the BIOS/CPU.)