The main advantage is that the state machine is not predictable while moving from one state to another, and it is driven by events coming from outside.A state machine is divided into a series of states and transfers from one to another through transitions, which are generated by events. An example of an event is a user turning on the system: the system transfers from the off state to the on state. A state machine cannot be in two states at one time. this makes it easy to query the state of the workflow. The basic idea of this project is to generate the state machine, automatically according to the system state, to build up a map of the system states from the first interaction of the honeypot with the server until the end of the session.The state machine includes four main states that will be monitored with 18 possible transitions between the states. The finite state machine can be described as the state table which shows the possibility and direction of each transition to/ from the state, the table is shown in Table 1.As mentioned earlier, there are several issues to discuss the finite state machine as well as the client honeypot in order to get a better understanding. Some of the issues such as the system states to be monitored, the transitions from one state to the next, the information saved with each state, and the tools for monitoring changes in each system state are worth mentioning here. These issues are discussed in the next section.The previous section described the state machine and its benefits for client honeypots. In order to incorporate an automated state machine into a client honeypot, the issues listed in section-1 are addressed below.The first question is what are the monitored system states? To answer this question we have to understand what are the system states during infection by malware, and other benign states.