Discussion on MOHAA

m0dhippY · Post by **m0dhippY** » Wed Dec 10, 2008 1:03 am

Hello everyone, I was told to come to these forums by Baker.

Before I continue, I need to congratulate Baker and Rook on their anti wallhack method for Quake.

My question is centralized on the same fix, however unlike Quake MOHAA (Medal of Honor Allied Assault) isn't open source.

MOHAA lacks many features. When EA & 2015 developed the game they rushed it's release and it's somewhat of a disappointment because it had alot of potential.
It has broken support for sv_PURE, sv_allowdownload (they were never finished)
The game doesn't have any solid AC built in, and despite the fact that there currently exists an AC called DMW, the fact that it's clientside doesn't seem to phaze the hackers out there too much.

MOHAA has been around for about 8 years now and it is just about exploited in ways you can't even imagine. When I first played the game I ran into hackers. I never even imagined that cheating was possible in multiplayer. After I have been exposed I was intrigued by learning how to exploit MOHAA myself. I offcourse never intended to exploit it to mess up the game (despite the fact that's what seems happened), instead my main intention was to learn from it and like a regular programmer learn from it and try to patch the glitch. I have been exploiting the game for a quite few years now, but in the past 2 years I have decided to turn tables and use my knowledge for fixing up the many exploits in the game.

One of the biggest exploits in the game was what I called a STWH (Shoot through Wall Hack). The reason this hack was vulnerable (no other game is vulnerable to this aside from the MOH series), is because the game doesn't check the map checksums.

There is absolutly no check so someone can rename a map called mohdm6.bsp to mohdm1.bsp & load it in a server that is running on mohdm1.bsp.

It was a complete joke, and on top of that MOHAA seems to be very glitchy when collision detection is mentioned.

Anywho, enough about my bad past, as I told Baker, I have merged with a modding team known as mods-r-us.net to create an unofficial patch to help fix the many exploits that were introduced to the game as well as fix many of the hacks used & add functionality to the broken commands that were never finished being implemented.

Currently we are looking at getting
CL & SV_PURE
CL & SV_allowdownload (from ftp & external links)

STWH fix
Wallhack Fix
Aimbot Fix
No Recoil Fix

Fixes for several crashes & ingame exploits such as getting through maps.

Here is our method described in detail for our fixes:
STWH:
STWH (this hack is possible, because clipping is glitchy) when a gun is clipping through the wall it seems to avoid all detection of the bullet\sprite until it hits a player. SO you can literally hit players across the map even if there are 5 walls between you and the enemy.
The fix for this is to calculate the degree of the muzzle to the wall. This can ONLY work if a player is leaning into a wall and the gun clips through so we check the fraction of the muzzle against the wall, if we determine that the muzzle is in the wall, we don't emit the bullet, otherwise we do. This seems to work very well.

No Recoil:
There are 2 theories I have for this/
1. Recoil is handled clientside, so what I was going to do is emulate that function and implement it directly into serverside instead of clientside in cgamex.

2. The function used for recoil is viewkick(). We also know that viewkick passes through 9 parameters. For no recoil to work 1 of 2 things need to happen, all parameters need to be modified clientside and commented out so it has no effect or the values need to be 0'd out. It can also be done through memory, but the same concept is used. When viewkick is called ingame, it returns RETN so that it never makes the jump, it exits right away. Similar to a unconditional jump. At any rate going back to what I said, every weapon has their own specific values that make up the 9 parameters. Each one is unique to the weapon. What I was thinking of doing was intercepting the function before it happens and validate the values with the ones that are default. If the values are modified, overwrite them in memory through the gamex wrapper (serverside). This is just an idea not sure if this is possible. I'm trying to do as much serverside as I can so that I can avoid clientside fixes from being bypassed or exploited.

Anti Wallhack:
The theory is identical to Baker's & Rook's, however our version seems to crash the server unexpectedly, and sometimes.
The other thing is accuracy. We're trying to work out a method of stopping wallhacks without having too many blindspots. How accurate does your fix do this? There always seems to be a split second of a rendering issue between when a player is seen and when he isn't. It may cause some issues. We also want to make sure that this works for both Windows & Linux, and maybe even Mac if possible.

Anti Aimbot:
As far as aimbots are concerned, there are 2 ways I can think of as well.
1. Spawn "fake" player entities all over the maps and make them move around a certain path that covers a big portion of the map. If an aimbotter is triggered & shoots the fake player, we kick the user or we screw with them by taking their weapon away or killing them.

2. Create a system that is basically a AI Admin. It's based on a point system similar to that of the serverside fix in CS called hack cam. Consider the following. Each client in a server has 5 trials. Each trial can max out at 20 points. At the end of the trial we have 100 total points (5 x 20 = 100).

The way this works is the AI rates the client kills based on things like accuracy, precision, how fast they interact with their surroundings, whether or not they can hear "stuff" etc etc. Just the basic things a regular admin looks for in a cheater. If a user is cheating, they typically score a higher amount of points on the point system. Depending on how we tweak it we can have a cut off for a cheater at say 80\100 points versus a clean player scoring usually between 0-79 points. Offcourse, it's not accurate, but I think with some testing we can make a system pretty accurate.

One of the big issues with MOHAA is that the game isn't open source. We DO have a basic cgame & gamex wrapper to work with where many modders already started using for some fixes, but unlike Q3, MOHAA has very limited source so it needs to mostly reversed manually. On a side note the MOHAA engine is similar to Q3 & the FAKK2 engine, but modified.

If anyone can help us out with trying to get atleast the anti wallhack working I would greatly appreciate it. Thanks in advance, and thanks Baker for pointing me to the forums.

Here is a video of our wallhack fix currently: http://www.youtube.com/watch?v=yf24EIij0j4

Baker · Post by **Baker** » Wed Dec 10, 2008 3:38 am

m0dhippY wrote:Hello everyone, I was told to come to these forums by Baker.

Before I continue, I need to congratulate Baker and Rook on their anti wallhack method for Quake.

My question is centralized on the same fix, however unlike Quake MOHAA (Medal of Honor Allied Assault) isn't open source.

The way that the anti-wallhack stuff in Quake works is documented in this thread:

http://forums.inside3d.com/viewtopic.php?t=1291

I would say not having the source open for MOHAA probably makes what you want to do nearly an insurmountable task.

Note:

All the credit for the anti-wallhack capability really goes to Krimzon as I understand it and then LordHavoc for adding it to DarkPlaces and then Spike for adding it to FTEQW.

All I did was examine the changes between the version of FTEQW that had the feature vs. a previous version that didn't have the feature to assess how to add it to any given Quake engine.

Then I guess that got Rook's interest to thin it down to a single function.

m0dhippY · Post by **m0dhippY** » Wed Dec 10, 2008 5:52 am

It's actually very doable, as you can see by the youtube video I posted. Actually the one there is a very beta stage of the anti wallhack fix, now it's much better and less glitchy, but there still exists the occasional crash that we need to figure out.

I think if we can discuss what needs to be done, I can be of help on answering any questions about the MOHAA Engine. I'm no expert, but I have been doing things for the game for quite some time. We are also working on another project that is similar to Icculus's version of IOQ3. The project name is Open MOHAA, and it is literally what the name suggests. ATM the project is on hold because everyone is busy, but the intention was to create an opensource version of MOHAA that would be compatible with the stock game however give more features & added functionality that MOHAA didn't offer.

you can find out more about the project here:
https://sourceforge.net/projects/openmohaa/

And from my earlier post here is a link to the gamex wrapper we have access to, that we are using for MOHAA & to add functionality to:
http://www.mohdev.mods-r-us.net/index.php?id=fgame

Here are some links to other mods that are based off the gamex wrapper. This is what we want to build off of:

http://www.modtheater.com/forum/showthr ... ht=mohfill
http://www.modtheater.com/forum/showthr ... ht=mohfill

I can tell you from looking at the source, your methods are VERY similar to ours. It seems our code has more syntax, but the idea with using tracers serverside is the same thing.

Here is a sample of the code we use just to give you an idea:

Code: Select all

//This is the viewer's eye.
	//orientation_t oFrom;
	//mEntityGetTag(gEntFrom->entity, (char *)"eyes bone", &oFrom);
	
	//Now trace the eye position to "well" defined points of the
	//we take the vViewPos instead of the eye bone pos, because the view pos is most likely not solid
	VectorCopy(((Player *)gEntFrom->entity)->vViewPos, playerOrigin);
	//fprintf(stderr, "tracing from eye: %f %f %f\n", playerOrigin[0], playerOrigin[1], playerOrigin[2]);
	
	//trace from the player to the target including movement prediction for both
	for (playerCurrent = 0; !seen && playerCurrent < count; playerCurrent++) {
		
		if (gameImport.pointcontents(playerOrigin, 0) != 0) {
			fprintf(stderr, "gameImport.pointcontents(playerOrigin, 0): %f\n", gameImport.pointcontents(playerOrigin, 0));
			goto newPos;
		}
		
		//backup the original value prior to modifying it for the eyes
		//VectorCopy(playerOrigin, playerOriginBak);
		
		VectorCopy(gEntFrom->client->ps.viewangles, vecView);
		//convert to forward vector
		vecView[2] = vecView[0] * M_PI * 2 / 360;
		vecView[1] = vecView[1] * M_PI * 2 / 360;
		vecView[0] = cos(vecView[2]) * cos(vecView[1]);
		vecView[1] = cos(vecView[2]) * sin(vecView[1]);
		vecView[2] = 0.0;
		
		//VectorScalarMult(vecView, 30.0, vecToEnemy);
		//VectorSub(playerOrigin, vecToEnemy, vecToEnemy);
		VectorSub(gEntTo->s.origin, playerOrigin, vecToEnemy);
		//VectorSub(gEntTo->s.origin, vecToEnemy, vecToEnemy);
		vecToEnemy[2] = 0.0;
		VectorNormalize(vecView, vecView);
		VectorNormalize(vecToEnemy, vecToEnemy);
		
		//fprintf(stderr, "VectorScalarProduct((%f, %f), (%f, %f)): %f\n", vecToEnemy[0], vecToEnemy[1], vecView[0], vecView[1], VectorScalarProduct(vecToEnemy, vecView));
		
		//behind us, save the trace
		if (VectorScalarProduct(vecToEnemy, vecView) < 0.4) {
			goto newPos;
		}

Also Baker, as I mentioned before, how accurate is your tracing? Do you suffer the same issue we do with the minor blindspots caused by the anti wallhack, or is it pretty much right on?

r00k · Post by **r00k** » Wed Dec 10, 2008 6:12 am

The trace is pretty accurate but takes a few tries to eliminate the chance of error. The error that you might get on our end is to NOT show the player when it should, like if just a corner of the player's bounding box is shown. Which would cause the player to flicker. This is resolved by randomly scanning 64 points within that player's bounding box until a hit returned TRUE. So, its not like the trace fails and the wallhack succeeds, but if the trace fails then the player isnt shown. It's the law of guilty until proven innocent

The blind spots i assume u mean that when the target is in plain view then you slide behind the wall and for maybe 1 second u can still see them (as i noticed in your video), seems to be just a timing issue.

Code: Select all

if (gameImport.pointcontents(playerOrigin, 0) != 0)

This worries me, as it doesnt look like a true trace. Seeing this is a war game im sure every weapon uses hit scan instead of collision detection for weapons. You could try to modify a basic bullet trace to target to better your chance at getting a valid hit.

EDIT: but if you are using ioquak3 then you will have better luck
as the quake3 engine has SV_ClipMoveToEntities which is close to what we use in quake1

Baker · Post by **Baker** » Wed Dec 10, 2008 6:59 am

m0dhippY wrote:We are also working on another project that is similar to Icculus's version of IOQ3. The project name is Open MOHAA, and it is literally what the name suggests.

I'd like to see the concept of recreating the characteristics of closed source games in open source engines done more often than it even is done now.

In fact, I think it would be better if there were no closed source games, but I think that's will take a couple of decades.

I mean, why invest time and effort even getting involved in a closed source game when it is going to rot on the vine and deteriorate or break on the next operating system upgrade.

I personally think closed source is naive, although the commerical reasons are obvious but a few years download the road it shouldn't matter. But I also know many of the game makers don't own the ip to a lot of what they are using.

ATM the project is on hold because everyone is busy

I can relate.

Also Baker, as I mentioned before, how accurate is your tracing?

It's dead on. Almost absolutely flawless. You'd never even know it existed when playing.

http://www.youtube.com/watch?v=hf94PbE-b9I

Needless to say, it really ticked off a lot of cheaters

But just remember, it isn't "my" tracing. I didn't develop it.

Spike · Post by **Spike** » Wed Dec 10, 2008 9:43 am

regarding shootthroughwalls, I'd hook the traceline function such that: if mins+max=0, and trace->start_solid was true, then trace_fraction becomes 0.

Chances are, this'll fix your shoot through walls bug in a generic way. The size test is so players can't get stuck more than they used to, but isn't actually likly to be important. Or you can check the solidity mask.

I've never played mohaa, but if it has a larger proportion of sniper rifles, then the wallhack prevention code will have more noticable failures than equivelent code will in q1-style games. Q2/Q3 bsp provides greater options with trace sizes, and could thus could be adapted to use a 'better' trace mechanism presumably (inverted boxes in a way). But that's a huuuge chunk of code if you don't already have the engine source.

The thing about aimbots is that they're remarkably acurate.
A QuakeWorld player typically hits about 40% lightning gun accuracy. An aimbot will get 60+% but no player will _consistantly_ get that high. The problem is that players can get that high in short bursts, but if they're that high after a long fight then its fairly blatent that its a bot.
Rate pitch accuracy greater than yaw accuracy, if possible.

Viewkick... not a clue. Disable it? Then its at least fair. On the plus side, if disabled then it'll trigger your aimbot detection code a little more often. :)
Is viewkick even visible serverside?
Is it implemented in the cgame or the game code? If its in the cgame you can ensure that their pitch has at least changed since the previous frame. If it happens 3 times in a row then kick them as its not too likly that a player can get 2^48 precision... But then I'm skewing the stats a little.

If your detection of things is not 100% accurate, then don't silently ignore it.
Make it 5 times worse than it otherwise would be if its a single event, or kick them if its a continuous one.
But if your detection routine is prone to false positives, then there's not much you can really do anyway.
If you get kicked 50% of the time you cheat, then you're not going to get very far where scores are concerned. Such players would then find other games, ones which are less annoying each time they cheat. Well, either that or they'll just update their cheats.
An honest, good, player will take it as a compliment. :)
Just beware the false positive.

m0dhippY · Post by **m0dhippY** » Wed Dec 10, 2008 10:49 pm

r00k,
I really appreciate your feedback. I will try to discuss your method with the group and see if we can try to work with that. I have a list of all the MOHAA functions that were pulled from the Linux Binary, so I'm assuming it should be fairly similar in Windows.
I just took a look at the functions, and I couldn't find SV_ClipMoveToEntities, but I was able to find this: SV_AddEntitiesVisibleFromPoint, not sure if this has any relevance.

Baker,
I agree with you, and the best example most of us are already very aware of is Linux. It's a Open Source Operating System that does everything Windows can do + more, and it's FAR more stable. Game dev's are afraid of the community to rip their code and such, but sometimes you need to take a risk. After all Quake turned out fine and even CS and it's series.

I also have to say I watched that video, and I am totally jealous. That is probably the most accurate anti wallhack I have ever come across and I'm just short of words. I can only hope that I can figure out such a stable fix for MOHAA sooner than later.

Spike,
The STWH, is already fixed, but I appreciate your input on the fix. Also since clipping seems to be a big issue in MOHAA, I was wondering if there is some kind of check to check the solidity of all the walls. It seems that if the clipping was fixed all together then it would counter all issues with 1 fix. (STWH, clipping through walls, falling through clips in the terrain, and going under the map, etc etc). Not sure if Q3 also fails this issue with being able to shoot through black windows or furniture, but it seems bullets travel through that. The fix for that was far simpler than I have imagined it, we simple rewrote a serverside shader and added a solid clip in all the furniture such as couches, black Windows, lightbulbs and anything else that can be shot through. That seemed to fix that exploit.

As far as sniper rifles, it only has 2 sniper rifled (1 per team), so I'm not sure wha you mean about the proportion of the sniper rifles.

Q2/Q3 bsp provides greater options with trace sizes, and could thus could be adapted to use a 'better' trace mechanism presumably (inverted boxes in a way). But that's a huuuge chunk of code if you don't already have the engine source.

Would you mind elaborating on what exactly you mean? This seems interesting. Like I said before, despite the fact that MOHAA is closed source, the engine is very similar to the FAKK2 & Q3 Engines which are both Open Source, so there may be some potential of doing what you're talking about, but I would have to understand what you mean. Are you saying that with the additional tracing code we can make maps more efficient against wallhackers? Would this require recompiling all the maps? If so, that's not a problem since the .map files have been released to the community for MOHAA.

As far as the no recoil is concerned, the viewkick seems to only be mentioned in the cgame. I couldn't really find anything in gamex. How can I check to see whether the pitch or the other variables have changed from the previous frame? And can it be done serverside?

I want to thank everyone that has participated in the discussion and helped me out. I hope we can continue the conversation and in the meantime I'll keep everyone posted with what we figure out.

If anyone here can be of assistance and has some time to help me out, please let me know if I'm not at work I'm usually on AIM or MSN. Please PM me your info if it's not of any inconvinience. Thanks again everyone.

InsideQC Forums

Discussion on MOHAA

Discussion on MOHAA

Re: Discussion on MOHAA