Hunty Zombie Security Script Code
Hunty Zombie Security Script Code
The script implements incremental warnings and punitive measures based on player activity and responses. Each suspicious activity adds to a `warnCount`, and players receive incremental penalties for repeated offenses, such as strikes and warning levels, which ensure that actions taken are proportional to the severity and frequency of detected anomalies .
Potential vulnerabilities in heartbeat monitoring could include manipulation or spoofing of heartbeat signals to feign player activity. If attackers could replicate valid heartbeats, it would bypass inactivity checks. However, the system mitigates these risks by cross-verifying timestamps, limiting valid timestamps to a buffer, and enforcing strict disciplinary actions on anomalies, reducing but not eliminating this risk .
Communication security between players and the server utilizes algorithms based on cryptographic principles involving XOR encryption for basic data obfuscation and a multi-step encryption process incorporating dynamic keys for complex data validation. By using player-specific keys and synchronizing timestamps, the script secures data exchanges, ensuring both confidentiality of the content and integrity of the transmission .
The system uses player-specific keys and timestamps for security measures. Each player is assigned a `playerKey` which is periodically rotated. Heartbeats are monitored, and players are warned or kicked if invalid timestamps or repeated failed attempts are detected. Warnings are issued at two failed attempts, and players are kicked after four warnings or if multiple failed attempts occur .
The system handles unauthorized script injections by generating encrypted data specific to each player and requiring the encrypted response to match expected results in terms of client timestamp and data. Any discrepancies or multiple failed decryption attempts trigger warnings and potential removal of the player through kicks, ensuring consistent verification against tampering .
The security system uses a combination of simple and advanced encryption techniques. A function, `simpleEncrypt`, is used to encrypt strings using a basic XOR operation with a key, while `advancedEncrypt` applies a multi-step process using user ID, timestamps, player's dynamic key, and a rotation key for complex encryption .
The `heartbeatRemote` is a RemoteEvent that monitors player connectivity and validates that encrypted data and timestamps from clients match expected values. It updates player data, rotates keys, and checks for missed heartbeats, issuing warnings or disconnections as necessary to maintain security and prevent tampering .
Key rotation effectively maintains security by frequently updating each player's `playerKey`, preventing prolonged use of a single key which could be compromised. Rotation occurs every 30 seconds, reducing the window for potential attacks. This approach is crucial for dynamic environments like gaming where interactions are frequent, providing a constantly shifting target for potential attackers .
To protect against replay attacks, the script maintains a list of `validTimestamps` for each player and checks incoming timestamps against this list. Re-used timestamps increase `failedAttempts` and trigger warnings. Timestamps are freshly generated using `getSecureTimestamp`, and repeated use of timestamps within player data triggers an increase in strikes and ultimately can lead to disconnection .
Player-specific keys are generated using a combination of static server secrets and dynamic values such as user ID and a secure timestamp. The `generatePlayerKey` function derives a key using a seed formula involving the server's `baseKey` and `saltKey` with current timestamps. The `advancedEncrypt` function further incorporates user ID and player key into a multi-step transformation using the `rotationKey`, resulting in a unique player-specific key .