Mainly catches the instant ladder and too large moves, generalize step
to have general "reset" as condition instead of "ground", don't limit by
a distance.
* Not actually a fix for anything we encountered.
* Nailed down blockinteract.visible raytracing issues to bad end-points
for raytracing.
* Also test/prepare logging test-cases for raytracing in general. Not
enabled, because we should have some flag/permission/command to check
before logging ~ 5KB per interact event.
This makes logging all violations potentially useful to use alongside
with the "ncp debug player" command in production environments. The flag
debugonly must be set with at least one backend being activated.
Similar to TestNCP but reduced/different features:
* Config: trace for the log file and notify to send to notify channel.
* It's not possible to confine whose messages you receive (yet).
Meant for better local/quick testing in the first place.
* Make attribute methods consistent (remove the sprint boost modifier
from the generic speed multiplier, because it's inconsistent).
* Add missing implementations.
* Adjust default sprinting speed modifier.
* Add more guards for the latest compat module (1.8_R3).
* Add a reflection based compat module for CB, to cover minor updates.
* Possibly other minor fixes/changes.
[Hail "insufficient data written"!]
When the respawn/login location is obstructed, the respawn event shows
that location, but the first move will start at several blocks above,
without having a teleport event to rely on, thus this workaround.
Vertical velocity handling can be much simplified (and possibly extended
to including downwards velocity) with using a friction-based modeling.
Absolute envelopes can still be checked extra, where appropriate.
Not very efficient in terms of code-output, but enabling us to log test
cases for visible (and potentially passable too), using real-life
examples.
* Add the capability to log a FakeBlockCache as java code.
* Add utility to record map parts (cuboid, ray-tracing with margin) to a
FakeBlockCache.
Missing:
* Actually log stuff (visible).
This is not the thing (lots of yet), but it is a small step.
Refactor:
* Use access methods for several details on vertical velocity.
Fixes:
* Dont reset the current jump phase if there is vertical freedom left,
because the next jump might then cause a violation.
* Fix clearActiveVerVel (remainder used to clear hVel, yet unused).
* Clear vertical velocity on removeAllVelocity (!).
* Keep setting sfDirty if velocity is found, to prevent premature reset.
Missing:
* Some resetting conditions for sfDirty might be missing.
* Implement an error counter increasing with velocity-add by 1.0 or
slightly more , decreasing with violations, but undo violations if count
is > 0.0. Use at least for vertical accounting, in order to go stricter
on cheating with velocity.
* Revise setting sfDirty on horizontal velocity as well.
* Switch to AxisVelocity (vertical), accounting for + and -.
* Use a LinkedList for storing past locations (prevents overriding if
t_last = t_now, also allows storing differences there right away).
* Calculate the yaw difference vs. the maximally possible value (180).
* Add switching the target as an extra weight.
The workarounds in InteractRayTracing and using multiple
reference-targets in Visible have all been removed in favor of using the
actual looking direction for ray-tracing.
On quick testing, there remain false positives, allowing to somewhat
escalate violation levels, if intended to. On normal playering false
positives seem to happen very near the very edges between blocks on
occasion.
* More tests for PassableRayTracing (room, rays from outside).
* Alter InteractRayTracing to account for the block interacted with.
* Added tests for InteractRayTracing.
Problems:
* RayTracing may end x-th digit off target, thus in the wrong block.
Suggested fix is to keep correcting t by the absolute coordinates of the
blocks, i.e. calculate the absolute position rather than adding up.
* InteractRayTracing with strict set to false (like in the
blockinteract.visible check) will be too lenient with 1-thick wall
setups and fail test cases.
Previously only "random" transitions were taken, for simplicity. For the
sake of better debugging and consistency we check all combinations of
transitions now, calling the iteration with all transitions done at once
the "primary line", while calling step with a subset of transitions done
would be the "secondary line".
Currently an iteration might still end x-th digit off the target, so it
does not necessarily end on the target block itself. This is not a
problem for passable, but might be one for interaction and other
applications, thus this should be fixed at some point.
To avoid cheaters accumulating velocity dealt by damage, we skip dealing
fall damage, if they would not have received any, without taking the
current move into account. This is only for the case a player causes a
violation for which NoFall would usually have dealt fall damage.
* Update lastKeepAliveTime from KeepAliveFrequency (even if that is
disabled).
* Update lastKeepAliveTime from FlyingFrequency too.
* Allow to test for feature tags efficiently.
* lastUpdate is always set calling update().
* Negative diff can not affect update (time ran backwards).
* Use lastUpdate instead of lastAccess where appropriate.
* More comments/formatting.
While we can/could control which stream to log to within onDisable, we
should still assume that an asynchronous task could be using the logging
system. Since we don't have a clean entry to onDisable, we have to catch
the exception.
* Extend CheckConfigFactory with a remove-all method.
* DataManager.clearConfigs() now uses CheckType for getting factories.
* Split off Check.hasBypass method to check exemption + permission.
* Allow null permissions in CheckType (interpret as no bypass).
* Add Check types for FlyingFrequency and SoundDistance.
* Add exemption and actions to FlyingFrequency, alter defaults.
* Add a test for moving a simple config value (not sections).
* Add a flag to @Moved to allow explicitly skipping sections.
(Should enable moving values into a child path of the previous one.)
* Don't set values before inside of processMoved...
First attempt to detect if a moving event would fire. This might not be
100% accurate, as a) we can'T really know and b) lastTo is not minitored
in the most reliable way (e.g. teleport on highest priority, resetting
logic favors set-backs).
* Use a HashMap for data, as we intend to use the primary thread.
* Move redundant move checking into a method.
* Ignore on-ground, if it is sent too often.
* Log if redundant move checking has to be disabled.
Removes access by name and entity-id for now. Access by name might be
re-added, though any kind of mappings will likely be maintained
somewhere near DataManager.
Measuring the time from sprint to attack doesn't work well. The
ctrl-sprint thing also adds to it. Better would be measuring the
toggle-sprint frequency and possibly combine it with some other measure
(packet level attack frequency?) then rather deal attack penalty time.
We can now decide on base of the Minecraft version, which value to use,
with the config entry set to "default". Used with
pvp-knock-back-velocity and enforce-location (first move exploit).
Activated features are shown in the version info ("ncp version"). The
version info is now logged to the log file after post-enable and after
reloading the configuration.
* Add methods to NoCheatPlusAPI to add/set/get version tags.
* Display all tags in the ncp reload command.
* Alter test framework to set a dummy API.
* Add tags for blocks, net checks, FastConsume.
Contained changes:
- Melon and pumpkin block break timings: 1.8-specific, keep workaround.
- Don't run all horizontal move checking if no move.
- Utility method for checking for air.
- Some formatting.
A cheat client could move such that they are inside of a block, but
CraftBukkit will not fire an event, because the distance and looking
direction don't change enough. Teleporting other players or yourself to
that location would result in getting someone into a block. Consequently
we also have to block commands like /sethome at such locations.
Our first attempt to patch that will monitor teleports that use the
TeleportCause.COMMAND (might miss out on plugins that are not using the
appropriate cause, and on plugins that use items for teleportation), in
addition we monitor certain commands (configurable prefixes), to catch
things like "sethome" and "sethome2". The world spawn is exempted. Only
teleports into blocks are monitored.
This does not yet sanity-check the distance to the last tracked
location, but it will ignore if none is set.
Details:
* Only trim commands from the left side (both on feed and check).
* Ensure versions with and without leading '/' are fed into trees.
* Move methods to feed CharPrefixTree from configs to CommandUtil.
Potentially fixes (untested):
* Only deny the sub-commands for a prefix, example: feed 'version ' to
consoleonly, in order to allow 'version' but not 'version NoCheatplus'.
* Might fix some plugin/server specific prefixes not being detected,
example: feed "/version" and expect "/bukkit:version" to be blocked.
* Some cleanups (spaces, commented out references updated).
* LogManager implement INotifyReload, but gets processed extra (not
added with addComponent).
This is the first simple version, just setting debug for all checks for
the player(s). It can only be undone by removing the data, e.g. with
"ncp remove (player)", reloading does it too, but is much heavier.
For debug output now data.debug is used instead of config.debug, so the
data is initialized with the config.debug value. As an effect of this,
removing the data or reloading will override flags that have been set by
means of API-access only.
Affected:
* Adds getDebug and setDebug to ICheckData.
* Adds appropriate configs to all constructors of check data.
* Some per-check debug flags have been removed.
Extras:
* spaces
* import cleanup.
* Remove on-ground check.
* Always increase VL by 1, because clients could control it anyway.
* Skip if the player is in a vehicle.
* Remove adapting to lag.
* All logging is also going into the log file (always), debug output is
mostly/only going into the log file. File logging uses an asynchronously
processed queue now (!).
* Specify an existing directory (e.g. logs) and log files will named
after date + sequence number, changing with every reloading of the
configuration.
* Console and ingame logging remain within the primary thread.
* No extra configurability for customization, yet.
* Not all places have been cleaned up, concerning log levels. target
streams and package naming.
* Work in progress.
Hinting at further changes to unify permission access and caching. Later
permission caching can also be done for moving checks, though checking
for the current thread may be exchanged in favor of config flags.
Generic configuration will allow to set individual timeouts for checks,
check groups and default. There could also be change policies like
"world change only", possibly listening to permission updates, if
feasible.
CheckData / AsyncCheckData are not as simple to unify, if we want to
keep the footprint as low as possible there. There could even be more
implementations to match different policies.
* Always log location of logout if debug is set.
* Also check inconsistent logout if manahattan distance is > 0.
* Only perform "passable check" only if enabled and not dead/sleeping.
* Try to actually set-back.
Since other fixes migth be in focus, some changes are commited
merged/commented out:
* Prepare AxisVelocity to carry positive and negative values.
* Prepare MovingData to use vertical AxisVelocity. Rename hVel.
* Prepare CreativeFly (...), do not count velocity for height limit.
(Most preparations were unfinished, just hinting at the direction.)
AxisVelocity will later represent per-axis velocity accounting for both
directions along an axis.
There have been no changes to the functionality, so it still only
accounts for positive values.
Previously the max. bounds hitting the block edge would not be
considered as colliding, this can now be controlled with a flag.
If the flag is set, you will collide at offsets of 1.0 for either
coordinate (not if the offset is < 1.0).
* Better coverage of block-transitions: One step per axis, dT can be 0.
* Cover one step always, also if no distance is covered.
There might be more false positives, due to newly intoduced bugs, or due
to not all block-transitions being checked (a x + z transition will have
two variations to test extra to the ordinary diagonal path, but only one
is checked).
To make this works we change LogUtil to allow logging to console, and
initialize BlockProperties with MCAccessBukkit and use a fake
BlockCache, that allows to set blocks with an access method, so that we
can test ray-tracing.
The testEmptyCorner test would fail with the current implementation.
Trying to prevent a burst propagate and cause a violation, it will be
smoothed onto following buckets, if they have less than max packets,
stopping after adding to the first non-empty one.
Uncertain effect on cheating, first tests seem to show no huge
difference.
Original pull request:
https://github.com/NoCheatPlus/NoCheatPlus/pull/24
This probably is not the final implementation, but it allows some
minimal freedom:
* Specify number of entries to show.
* Specify check types (and groups!).
* Specify what to sort by.
There might be need for some merged view, combining several different
check types somehow, or just shortcuts for specific selections, e.g. for
fighting-related checks.
----
+ Fix root command not showing sub commmand usage.
- Replaces all tabulators with spacebars
- Splits Commands to Commands and Auxiliary Commands
- Commands and Auxiliary Commands are ordered alphabetically now
This way, using the speeding permission as a workaround for all
individual speeds is possible. A player moving faster than default will
likely move faster in web too, and so on. There seems to be little
reason for keeping it confined to walking + sprinting only.
Moving it to the end also allows a quicker return for walking and
sprinting, though that policy might be questionable as well, because
some calculations might use hAllowedDistance, subject to review.
This should be better in case the vanilla command allows UUIDs some day.
At least during testing in uuids did not work, so we added a warning
message if uuids are used for banning.
Using player names for actions should be safe anyway.
Access by id may or may not be changed internally, depending on what
happens on the API side.
For performance reasons we might like to do without passing on extra
stuff like Material, or even do String-comparison.
If ids will become more expensive to use than other ways, or if it will
be possible/accepted that ids get reused during runtime, then we will
have to change all internals.
A merge can happen if the maximum distance between any two points
exceeds the merge distance, because LocationTrace attempts to balance
distances entries. Thus this test must not bne able to walk further than
the merge distance.
For whatever reason it was commented out, it is now put back, assuming
that the reason was "it did not help with mcMMO", because mcMMO used to
fire extra BlockBreakEventS.
Now we use a tri-state and set it to MAYBE if instantBreak is set
already on lowest priority, to have a rough indicator if a plugin set
it, or if the server might have done it. Later we might let FastBreak
assume some maximal duration for either case, instead of ignoring these.
Fixes:
* On passable-violations useLoc might have been passed as newTo.
Reduce potential for accidental future misuse:
* Call useLoc.setWorld(null) as late as possible.
* Do not reset world of MoveInfo.useLoc in MoveInfo.set.
An implementation for NCPCompatBukkit is missing.
Note that the native access can not set lastYaw nor lastPitch in
PlayerConnection (private), but it could set lastYaw and lastPitch in
EntityPlayer.
Can't guarantee this actually helps with stuff like derp/magnet, because
we can not really set the outcome of a PlayerMoveEvent without
rubberbanding the whole planet. Hacks could send enough packets per tick
to keep freezing people - we might be able to keep track of yaw/pitch
correction and cancel (most) attacking for the same tick after yaw
correction (invalidate "same" with in-bounds yaw).
"Magnet" refers to a player seemingly freezing other nearby players onto
the spot, causing them to yaw-glitch, seemingly getting attracted by the
cheater.
Thanks again @Iceee for reporting and @Amaranth for finding cause +
suggested fix.
Not sure this both helps and prevents false positives, so it could get
redone a couple of times, might also result in being impossible to fix
with a plugin in an acceptable way.
- Never skip undoing changes. This is necessary to also process commands
that are not registered or that are fall-back aliases.
- Check adding all plugin commands always.
- Check for aliases as well for decision if to match a command.
These seem not to have been affected beforehand, due to the nature of
the SimpleCommandMap, however we don't want to exclusively rely on
fetching that one successfully.
Setting a set-back location with a null World will now lead to a
NullPointerException. Setting null worlds on set-back locations is not
intended by contract, however due to using temporary Location instances
with Entity.getLocation(Location) and setting the world to null
afterwards to prevent memory leaks, also considering the number of
places where setSetBack is used, this seems to be an appropriate measure
to track better or help excluding violations of that contract.
This does not change the used methods much, thus it will rather allow
much more cheating, however it allows some basic testing for false
positives. The reach implementation has been slightly optimized to run
faster. The current implementation is not final and only uses trace
elements that were added in the current tick, the latest is always
included.
Next steps will probably be:
* Stricter methods for an individual TraceEntry (demand near-exact hit).
* Don't allow random latency shifting. Maintain a window-thing.
* Probably get rid of the classic method for attacking other entities.
No change for the function of the plugin, except if there are new bugs.
Actual changes:
* Keep track of squared distance to the previous element in a trace.
* Balance mergeDist: prevent merging the latest entry, if the squared
distance from the latest to the second latest element is greater
than mergeDist. Never merge if there are only two entries in total.
* Add convenience methods for resetting and updating the trace.
* Maintain the moving traces actively. With intended use being
player-player interaction, we will not reset with every teleport.
Just the raw implementation + initial test cases. To keep memory use
constant, a ring-buffer with some maximal size will be used. The
iterators are meant for faster implementation, rather than fastest
iteration. Later some trigonometric functions could be added to
LocationTrace, depending on if that may gain a lot of performance.
Next we will add the logics for adding entries and resetting the trace
to NCP (moving, teleporting, joining), on Logout the trace must not stay
in MovingData but should be garbage collected. That should be a
milestone dev build, though it does nothing for the user, it might help
finding crash bugs :p.
Soon to follow will be changing some fight checks to be able to use the
moving trace, then alter them to actually use it. Fight and interact
checks could also do moving consistency checking (tp exploit).
Who reads this?
The cancelled BlockPlaceEvent will lead to an extra sign being dropped,
while the item in hand stays. Odd enough, the cactus is removed before
the BlockPlaceEvent - need to check if a ticket exists for CraftBukkit
already...
