3 ms·

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 disa

by 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?
- Amadou 13y ago
  Beeps on the speakers or listening on the mic doesn't involve packets to begin with! All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance. Then there is the Blurt project - an 802.11 physical layer interface that runs over speakers and microphones. Its early stage but its just one guy hacking at it, not some billion dollar spy agency. https://github.com/piannucci/blurt https://github.com/piannucci/blurt
  - lawnchair_larry 13y ago
    > All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance. No, but evidently yours is. Sorry, this is quite straightforward to anyone who has ever used a packet sniffer. The fact that it's analog has nothing whatsoever to do with how packet sniffers work, and he wasn't monitoring a serial bus. Blurt doesn't do what is being described here. It wouldn't show up in packet logs. Which proves my point.
    - Amadou 13y ago
      Your conflating "serial bus" with serial transmission suggests that you don't even have the vocabulary necessary to participate in an informed discussion on the topic. Because of that I am kind of at a loss for where exactly to begin. Here's a simplified start: all common network interfaces transmit serially at the physical layer - one bit at a time, wired ethernet, wifi, 3G/4G/LTE, WiMAX, fibre channel, dsl. None of them are inherently packetized at the very lowest level, they are all just a series of bits. Packetization is done through either synchronous clocking (fixed transmission periods) or, more commonly today, asynchronously via a special sequence of bits that indicate start/stop of a packet. This is layer 1 of the OSI 7 layer model, we are not even talking packetization like a typical packet sniffer would see, that comes after the physical interface has decoded the transmission like OFDM and undone the 8b/10b then stripped off the bits that make up stuff like the preamble and frame delimiter in the case of ethernet. Packet sniffers typically work at layer 2, where you can see things like MAC addresses or layer 3 where you see full-fledged IP packets. You run wireshark and you won't see things frame-start bits or the 8b/10b encoding because all that stuff is going on at a level that packet sniffers aren't intended for. Any audio-based network system like Blurt and the suspected BadBios mechanism would be a full layer 1 implementation. They might do higher layers too or they might encapsulate IP packets and hand them off to the OS's network stack to handle, but the idea that "beeps" don't involve packets is pure ignorance of how modern datacomm systems work. It is ALL analog "beeps" at the lowest level, be it EM "beeps" or audio "beeps." Packetization occurs further up the stack.

by Amadou 13y ago

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?

Amadou 13y ago
Beeps on the speakers or listening on the mic doesn't involve packets to begin with! All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance. Then there is the Blurt project - an 802.11 physical layer interface that runs over speakers and microphones. Its early stage but its just one guy hacking at it, not some billion dollar spy agency. https://github.com/piannucci/blurt https://github.com/piannucci/blurt
- lawnchair_larry 13y ago
  > All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance. No, but evidently yours is. Sorry, this is quite straightforward to anyone who has ever used a packet sniffer. The fact that it's analog has nothing whatsoever to do with how packet sniffers work, and he wasn't monitoring a serial bus. Blurt doesn't do what is being described here. It wouldn't show up in packet logs. Which proves my point.
  - Amadou 13y ago
    Your conflating "serial bus" with serial transmission suggests that you don't even have the vocabulary necessary to participate in an informed discussion on the topic. Because of that I am kind of at a loss for where exactly to begin. Here's a simplified start: all common network interfaces transmit serially at the physical layer - one bit at a time, wired ethernet, wifi, 3G/4G/LTE, WiMAX, fibre channel, dsl. None of them are inherently packetized at the very lowest level, they are all just a series of bits. Packetization is done through either synchronous clocking (fixed transmission periods) or, more commonly today, asynchronously via a special sequence of bits that indicate start/stop of a packet. This is layer 1 of the OSI 7 layer model, we are not even talking packetization like a typical packet sniffer would see, that comes after the physical interface has decoded the transmission like OFDM and undone the 8b/10b then stripped off the bits that make up stuff like the preamble and frame delimiter in the case of ethernet. Packet sniffers typically work at layer 2, where you can see things like MAC addresses or layer 3 where you see full-fledged IP packets. You run wireshark and you won't see things frame-start bits or the 8b/10b encoding because all that stuff is going on at a level that packet sniffers aren't intended for. Any audio-based network system like Blurt and the suspected BadBios mechanism would be a full layer 1 implementation. They might do higher layers too or they might encapsulate IP packets and hand them off to the OS's network stack to handle, but the idea that "beeps" don't involve packets is pure ignorance of how modern datacomm systems work. It is ALL analog "beeps" at the lowest level, be it EM "beeps" or audio "beeps." Packetization occurs further up the stack.