diff --git a/Handshake-Snooper-Attack.md b/Handshake-Snooper-Attack.md
index bfb291c..883f6f9 100644
--- a/Handshake-Snooper-Attack.md
+++ b/Handshake-Snooper-Attack.md
@@ -17,17 +17,24 @@ or with parameters:
 export FLUXIONWIKillProcesses=1; ./fluxion.sh
 ```
 
-1. When prompted, select a network interface which supports injection.
-2. Run a scan utilizing the selected wireless interface & select a target network.
-3. Select an attack on the target network, in this case, choose `Handshake Snooper`.
-4. Select a method of attack.
+1. Select an attack on the target network, in this case, choose `Handshake Snooper`.
+
+2. Select a target network; if one was previously selected, you'll have the option to continue with it.
+* You must select a network interface which **supports monitor mode**.
+* Optionally, you'll have the chance to select an interface for target-tracking.
+* The **target-tracking** interface must be an **independent interface** due to the fact it requires channel hopping, which will cause issues for interfaces which require a fixed-channel.
+
+3. Select a method of attack.
 * A `passive` method of attack forces the radio to go completely silent, making the attack subtle (undetectable), and allowing for better listening. This method should work best for situations where the target is far away. The downside is the fact **the radio must keep listening until someone connects to the target** access point, which could take a very long time.
 * An `aggressive` method of attack uses a deauthenticator, either `aireplay-ng` or `mdk3`, and sends deauthentication packets to the target access point's clients. This method is considered aggressive because it is essentially jamming the connection between the target access point and its clients, effectively cutting the connection between the two. Once the connection has been broken, some devices will automatically attempt to reconnect, sending a 4-way handshake which fluxion's radio could catch. **This method could be considered illegal.** Make sure to follow governing laws applying to you. We're not liable for your irresponsibility.
-5. Select a hash verifier.
+
+4. Select a hash verifier.
 * This sets the tool used to check if a valid hash was caught.
-6. Select a verification interval.
+
+5. Select a verification interval.
 * This sets how often you want to check for a handshake.
-7. Select the verifier's synchronicity.
+
+6. Select the verifier's synchronicity.
 * This sets how verification occurs in relation to capturing data, either simultaneously (`asynchronously`), or back-to-back (`synchronously`). 
 * The `asynchronous` option will run the verifier while the computer is still capturing data. **This could cause an issue in slow systems**, because `pyrit ... stripLive` might be interrupted by the captor overwriting data too early. **The probability of encountering that problem increases over time**, since more data needs to be examined by `pyrit ... stripLive`. I suggest avoiding this if possible, or to limit its use to places were the handshake file will be caught relatively quickly.
 * The `synchronous` option will halt data capturing before attempting to check for a handshake, to prevent the issues described before. The downside of this method is the fact it'll stop listening while checking for handshakes, meaning it could miss a handshake while checking for one.