Jump to content


Photo
- - - - -

Ghost over Ethernet


  • Please log in to reply
2 replies to this topic

#1 TheFunk

TheFunk

    SUP3R 31337

  • Members
  • 183 posts
  • Country:
  • Gender:Male

Posted 17 October 2012 - 12:42 PM

In my networking class the other day, the teacher spoke briefly of frames traveling along an Ethernet cable without a start frame delimiter/preamble being known as a "ghost". My question is, how does the typical computer react to a "ghost" frame? And how difficult would it be to modify frames to be sent between computers so that they would be made to not include a SFD, and would thus be made into ghost frames? (oooh spooky!)

In related news, happy Halloween!

#2 wwwd40

wwwd40

    DDP Fan club member

  • Members
  • 53 posts
  • Gender:Male

Posted 18 October 2012 - 05:01 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). Its the same as jam events on a collision domain.

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.

Cheers,

wd

#3 TheFunk

TheFunk

    SUP3R 31337

  • Members
  • 183 posts
  • Country:
  • Gender:Male

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!