Hello! We use a product called Deepfreeze to restart and shutdown PC's. There are 1200 PC's reporting to the Deepfreeze server / console. I have a test environment with one PC reporting to a test server that mirrors our current configuration. We have an issue where workstations are restarting / shutting down "on their own". Unfortunately due to the nature of workplace (us vs them) and the finger pointing has started. So on to my question; In my test environment I have done a capture of the restart / shutdown command between server and client PC. 8 TCP packets were captured. server -> client: psh, ack client -> server: ack server -> client: psh, ack client -> server: psh, ack server -> client: ack client -> server: psh, ack server -> client: ack client -> server: rst, ack Somewhere in there is the data that triggers the restart / shutdown. How do I go about finding that "string" so that I can filter on it in the production environment? Thank you! Giles asked 05 Apr '13, 09:09  Malarky |
2 Answers:
The list of packets you quoted doesn't help much since there is no payload to examine and the capture is incomplete since there is no handshake - I'd have to be a techno-psychic to tell you that it is "in THAT packet". But even if you provide a trace file it is probably difficult to spot the command unless the deep freeze protocol is simple to reverse engineer. If I were you I'd try to contact the vendor support to ask them how to determine that a shutdown command was issued. Maybe they'll be able to tell you how the protocol works - otherwise, you'll have to do a lot of research to find out yourself. I would probably try to do a differential analysis where I compare traces of "normal" deep freeze operations to traces where I am certain that a shutdown command is sent. With enough trace data it should be possible to determine how a shutdown command looks like - unless the protocol is using encryption, in which case you'd be out of luck. answered 06 Apr '13, 04:33  Jasper ♦♦ |
I don't think there is any cleartext magic string that triggers a restart/shutdown. After all this is an enterprise solution and I'm pretty confident, that they use some form of authentication (OTP according to their web site) and/or encryption to authorize any action on the target. If they don't protect the communication, everybody in your network would be able to capture that magic string and restart/shutdown any PC at will. Regards answered 06 Apr '13, 09:06  Kurt Knochner ♦ |
Thank you for your reply.
The handshake is established when the PC first checks in with the server, so you if the PC has been up for 4 hours that handshake would have taken place then.
In my test environment;
1 client PC. 1 Server.
I started a capture and observed traffic for an hour and noticed that an 8 packet exchange sequence occurs every 30 seconds that I assume is a polling of online PC's that registered with the server when powered on.
At the end of one of those exchanges I issued the restart command so I can be confident that what I captured is specific to the aformentioned restart issued command.
re- differential analysis. I am willing to do that. Just looking for suggestions on how to dive deeper and if wireshark has the capability to help me differentiate between the data of normal polling data and command issued data?
Thank you! Giles
Wireshark has no special capabilities to help you with differentiation, you'll have to do it yourself. I would load two conversations (or partial conversations) into separate Wireshark instances and compare them manually, which is why my workstation setup always has at least two monitors as an absolute minimum. You could also double click packets in the packet list to open additional decode views if you need to compare packets within the same trace. I guess you can ignore everything including the TCP/UDP headers and concentrate on the payload.
If I'd already know that some parts of the trace contain normal polling events I would compare one of them with the one where I know I issued a restart command to see where the difference in the payload is. This may also involve using hex editors and/or scientific calculators to determine what payload byte/word is a command code and what is a parameter. I have to admit that a lot of that comes down to intuition and lots of experience, so if this is the first time you do this it'll take a while.
BTW i converted your answer to a comment to keep things clean.