.png "PC Bootup Baseline Setup")
This article will not address or reference applications that are encrypted, or use encryption in any way since that is a whole other topic.
In this article, I show you how to configure Wireshark, and more importantly why I configure certain options to capture the command sent by Contacam (https://www.contaware.com/contacam.html) and how to mimic that using another video player (https://www.videolan.org/vlc/) .
I wanted to ensure that you understood what I did and why so you can replicate this simple methodology with other applications.
Enjoy
I have never been much of a gamer, at least not since PacMan and Space Invaders disappeared from the arcades (shortly before the arcades disappeared from shopping malls, which was not long before shopping malls went out of favor). I have played Call of Duty a few times, but without my son’s Med Kit to save me, I would not have lasted long. The life-like qualities of this and other newer games are astonishing.
Many of us view video games as a classic waste of time, something you do while sitting on the couch munching Doritos – say, for example, during a pandemic. They are often blamed for America’s obesity problem, as well as the lost-opportunity cost of not reading, learning a new language, or pursuing a musical instrument. Only more recently have psychologists begun to recognize some benefits of playing video games.
Video games have been cited as good training for manual dexterity and are correlated with surgical skills for advanced medical procedures. They have found use in physical therapy for stroke victims. They also improve brain connectivity – basically a workout for the gray matter in our skulls – aiding memories, spatial navigation, and muscle control. Improvements in vision, persistence and mental health have been associated with video games by various researchers. Most advanced multi-level video games involve complex situations, making them good tools for developing problem solving skills. Whether the psychologists publishing these studies were gamers themselves is unclear.
It is a safe bet that few if any of these benefits would be realized with video games which play themselves. Once such “game” that has held my fascination over many years is the cellular automaton conceived by Cambridge mathematician Dr. John Conway.
As a youngster with an incipient interest in science, I looked forward to each new issue of Scientific American, where I would usually head straight for the Mathematical Games column of Martin Gardner. Years later, while I was a college engineering student, Dr. Conway sent a 12-page letter to Mr. Gardner, suggesting a multitude of ideas for his column. On page 9, under the heading “The Game of Life”, the basic rules for his cellular machine were laid out.
The playing field consists of a grid of little squares and at each tick of the clock, the squares turn black or white according to a prescribed set of rules based on the state of the surrounding squares. Martin Gardner called this a “fantastic solitaire pastime”, while Dr. Conway saw it as a “no-player, never-ending game.” It was the least favorite of all of Conway’s proposals for Gardner’s column, and yet it was the one for which he received the most notoriety.
As more people watched this allegedly “mindless” field of blinking squares, some began to notice special patterns and structures. One of the first of these to emerge was the “glider”, a five-celled creature that wiggles across the field. The “glider gun”, which produces a steady stream of gliders came about shortly thereafter. Also documented in the early days was the “blinker”, which behaves just as the name suggests. As recently as 2018, a special “spaceship” (named Sir Robin) was discovered. For those who believe this all sounds rather frivolous, it should be noted that The Game of Life inspired the incorporation of cellular automata in the field of complexity science, where the technique was used to simulate ants, traffic patterns and cloud behavior.
Dr. Conway once confessed that he used to go around saying “I hate Life”, but when people began introducing him as “John Conway, Creator of Life”, he rather liked it. Some of his fellow mathematicians describe Life as a gateway drug, leading newcomers into an infinite new universe of different Life-like rules.
The Game of Life may not train surgeons or teach problem solving, but it is far from trivial entertainment. Spend a little time with Life, and it will soon become apparent that a tiny change in the starting conditions can have a profound effect on the output, which may include total annihilation (a blank field), total never-ending chaos, or a frozen pattern that never changes. It is fascinating to observe how a very simple beginning can sometimes lead to a great deal of complexity. Mathematician John Allen Paulos remarked that Life’s most vital lesson is that “Uncertainty is the only certainty there is and knowing how to live with insecurity is the only security.”
The course of Life is not predictable, but neither is it random. An example of The Game of Life is shown in the three sequential frames at the top of this article. Once the clock is started, “LiFE” soon dissolves into near total chaos and finally ends up with the little black square which never changes. Dr. Conway referred to this final pattern as a “still life”, for which there is no Med Kit.
Domain Name System or DNS is one of the most important protocols in your network and out on the Internet. Why is that? Because you can't route a packet through a network using a word. It's just like when you are driving, and your GPS tells you to turn right, or go straight based on your current position. It uses your latitude and longitude, not the name of your current street. In the same way, routers use the numerical address to check their routing tables for the best path to send packets onto their destination. Computers are simply faster when using numbers instead of words. DNS is the protocol that converts the easy-to-remember words we want to use, into the numbers that routers and hosts need. It's the connection between the names and the actual addresses where the services reside.
When you're troubleshooting DNS you need to have filters ready to go. There's no time to create them once you're on that bridge call. You know the one, "It's SLOW!". DNS is the beginning of most conversations, so best practice is to check DNS first. There is even a haiku for this philosophy written by SSBroski.
It's not DNS
There's no way it's DNS
It was DNS
Here are 5 Wireshark filters to make your DNS troubleshooting faster and easier. Add them to your profiles and spend that extra time on something fun.
Usually this is what we are looking for. IMHO DNS servers should respond within a few milliseconds if they have the data in cache. Capture closest to the server to check server response time - no network roundtrip time to subtract. DNS errors will usually take longer to send, so they are excluded from the filter. We'll look at errors later in this post. Why greater than 100 milliseconds? Back in 2009, Amazon found that 100 milliseconds cost them 1% in sales revenue. https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales I have always used it as the point where a user notices "it is slow".
dns.flags.rcode eq 0 and dns.time gt .1
When the world is perfect, there is one DNS request and one reply. However in real life, things don't always work out that way. Filtering for a transaction ID lets you focus on a single transaction, no matter how many packets or servers are involved. If the client times out without an answer they will either:
Retransmit the query with the same transaction ID to their primary server
Retransmit the query with the same transaction ID to their secondary (or ternary) server
If they have to retransmit the query to either their secondary or ternary servers, the UDP stream number will change. However, the transaction ID will not.
Your goal is to filter for the transaction id - here is the important part - for the packet you already have selected. This syntax of fieldname eq ${fieldname} works for any field. It's pretty powerful.
dns.id eq ${dns.id}When you are looking at a pcap and notice something interesting, you often want to filter for that conversation. Maybe the server is an unexpected IP address, or a zone transfer is refused. The key with context sensitive filters is to save them as a button on your toolbar for easy access.
udp.stream eq ${udp.stream}
tcp.stream eq ${tcp.stream}A word of warning, if you try to create the UDP filter and you are on a TCP packet, or vice versa, the syntax check will be red. If you are creating this filter, be sure to select the packet of interest first.
Secondary servers should request all records (type 252) when they are first set up. After that, the primary should send a Notify (op code 4) after any changes. Then the secondaries send an incremental records (type 251) request to get the new records. If something goes awry, this filter will get you the whole picture.
dns.qry.type in {251 252} or dns.flags.opcode eq 4
Finally, you'll need a filter for DNS errors. Anytime a server responds with anything besides yes, it's a bad thing. In DNS, a positive reply still isn't necessarily a positive reply. This happens with queries for an IPv6 address. Instead of sending a "no such name" error, the server replies with no error code and no IPv6 address! Seems a bit passive aggressive to me, but the clients understand the response and move to the next step. Yet there is still no IPv6 address.
dns.flags.rcode != 0 or (dns.flags.response eq 1 and dns.qry.type eq 28 and !dns.aaaa)Be aware, this filter will turn the syntax check yellow due to the not equal, !=. But it's ok, the yellow is just a reminder that not equal only works as expected if the field is a single direction field. For example, ip.addr is bi-directional and http.response.code is single.
Are these all the filters you need for DNS? Of course not, but these should get you started. If you want my entire DNS profile, reach out to me on Twitter with the hashtag #ProfilesArePower. My handle is @PacketDetective.
Photo by Peter Palmer on Unsplash
Betty DuBois is the Chief Detective for Packet Detectives, an application and network performance consulting and training firm based in Atlanta, GA. She has been solving mysteries since 1997.
Experienced with a range of hardware and software packet capture solutions, she captures the right data, in the right place, and at the right time to find the real culprit.
Betty presents each year at SharkFest, the Wireshark Developer and User Conference, and is active in the Wireshark community.
Using packets to solve crimes against the network and applications is her passion. Teaching others to do the same is her calling.
Do you have a Packet mystery that you'd like Betty to solve? How about a team who needs training on how to catch the culprit themselves? Contact her at bettydubois.com information. Your mystery will be solved in no time.
