Ghost over Ethernet
Posted 17 October 2012 - 12:42 PM
In related news, happy Halloween!
Posted 18 October 2012 - 05:01 AM
As for generating your own, I could be wrong, it might be done with modified drivers but how you'd see them based on them being dropped by the rx'ing NIC chipset I'm not sure. I don't think C raw buffer's allow you to specify preamble or sfd as the NIC handles that for you (its a 'flavour of ethernet' NIC after all so is complying with the standards). Everything I've seen on programming the raw frames starts at MACDST, but if you find a way then post your findings.
Posted 18 October 2012 - 10:27 AM
A typical NIC will drop ghost frames - they are normally an indication of electrical interference (wiring problems). Usually the NIC will deny all knowledge of ghosts and since the software is relying on what the chipset is telling it, it wont be reported in software either (interface stats, test tool interface etc).
Perfect! That's exactly what I was hoping to hear, although it does sound much more difficult than I was expecting. Makes sense though, layer 2 is meant to interface with hardware, so obviously it's going to be more difficult to work with.
My end goal is to have two computers communicating using ghost frames. Since the frames would be dropped, there would be no record of them on the destination machine like you said, allowing for an obscure means of communication with no logs of any significance at the higher layers (no info on packets, no info on the segments, no sessions, no problems). Really, the only major task is finding a way to recognize and subsequently pull data from a dropped frame. I was thinking you might still be able to see the frame using a network sniffer, but I'm not too hopeful. Then again, who really needs to pull data from the frame? If enough ghosts were sent with a specific timing, you could just write a program to record how often you receive a ghost, and then map that to something like morse code, or some cipher. All I'd really need then would be a trigger, to tell the program to start listening for dropped frames. Of course actual collisions, other traffic, and interference would cause a problem, but hey one step at a time right?
You've given me a good bit to think over here. This should be fun. Let me know if you come up with anything as well.
BinRev is hosted by the great people at Lunarpages!