Just checked logs.
However, that looks like a false positive, so i'm sorry.
Let me explain:
How my antihack works:
It reads the memory values known as used by hacks from war2 memory. Then it sends that values to the server. And then the server compares that values to "known clean war2 values" and reports HACK if differs.
For map hack known "clean" value = XX. "Hack" value = 00.
That's why when i see value 00 from someone i can definitely say that he activated maphack. When i see XX i can definitely say that maphack is not being activated for him.
But what if value changes from XX to anything else, like 02? I have no idea if the map will be open (as in maphack) or ok (as usual), but that definitely means something strange happens. Normally that value is ALWAYS XX. That's why that will also be reported as HACK.
Another question is, what happens if reading the memory value will cause error for some reason? I've been so stupid that i didn't check that properly until last update.
Technically, value possibly be sent to the server then is not defined, but that should be 00 most likely.
I still don't understand how that can happen that defined and existing memory data in existing process can be checked most of the time, but not in several moments.
But I added that check to new version, just to be sure, marking failed-reading values as UNDEFINED.
And now what i can see in server logs:
These are several akas being marked as "HACK!":
- thaydrad:
map value: XX changed to YY and then changed back to XX.
other values also have been also changed to YY and then back to proper values.
YY is not any of known hacking values.
No idea what that can mean, but that's not kell-known hacks.
- 8472:
values have been clean most time. But sometimes changes to UNDEFINED.
- 00Kyle:
values have been ok at the beginning. But then they have been changed to UNDEFINED. After that they all have been changed to 00. And then to UNDEFINED again, many times.
00 means hack for maphack, but not for other hacks. So, 00 for all values could mean something else than hacking. No idea what exactly.
- Miron:
All values changed to UNDEFINED also.
Returning to the past:
xXxSmeagolxXx used previous version and i rechecked now:
All values have been changed from ok to 00. That could mean hack for maphack, but other values should be different.
I think that means antihack have not been able to read his memory values properly for some reason and then sent 00 instead. I classified that as hack. And i think i was wrong.
So i think that was false positive with xXxSmeagolxXx also.
I'm sorry again.
My future plans:
1. the problem in loader have been fixed. So, no more false positives. There are some more problems (not related to false positives) i plan to fix soon, so several new versions should be released.
2. my idea to consider any non-proper value as hack have been bad. I think 3 states should be shown: definite OK, definite HACK and undefined.
3. my idea to keep everything secret have been failed also. I have to discover at least several basic concepts about antihack and it's logic. Such discovering could cause the rish of hacking the antihack, but i can't keep everything secret anymore.
4. i still plan to rewrite the backend of server side from scratch to handle input data more careful. So, i'll consider these new conditions also.
I'm sorry again, but antihack project is still in testing stage. So, some bugs in code and in concept appeared in real environment only.
I'll make efforts to never repeat such situations.