Targeting Exploit

[Kraz]

There are players using EUO scripts to flood target requests, the flood itself isnt the problem, the problem is, RunUO is not validating the target ID, meaning they can flood and as soon as the target is created server-side that target request will be processed, they can gain a great amount of time, basically it is possible to target without really receiving a target on client.

Core/Network/PacketHandlers.cs

public static void TargetResponse( NetState state, PacketReader pvSrc )
{
    ...
    try {
        if ( x == -1 && y == -1 && !serial.IsValid )
        {
            // User pressed escape
            t.Cancel( from, TargetCancelType.Canceled );
        }
        else if ( t.TargetID != targetID )
        {
            // Prevent fake target, sanity!
            return;
        }
  ...
}

Decided to post it here so shard admins can update their server and fix it.

AssistUO and official Razor won't allow that kind of flood because they check for an existing target before sending that packet, EUO and Modded Razor users can bypass that, reason why a fix is needed.

PS: this fix has been tested on a live brazilian server and the impact on PvP spamming is notorious.

 

[fwiffo]

Nice one, thank you for this really useful fix

 

[Blacula]

I can verify that this EUO bug is 100% valid, and even works through lag spikes if the same spell is spammed. There's a particular Razor macro that floods target requests in the same way, and it has already been sent to Kraz for testing.

 

[Kraz]

I can verify that this EUO bug is 100% valid, and even works through lag spikes if the same spell is spammed. There's a particular Razor macro that floods target requests in the same way, and it has already been sent to Kraz for testing.

There may be a way to do that using official Razor release as you pointed, I don't even have Razor here for testing , anyways this fix will solve the problem.

People always thought it was just a matter of spamming/flooding the server, turns out RunUO was not verifying the target ID, allowing fake requests.
I reported to Mark a few days ago but he is busy or away so I decided to post in here, even if it teachs people how to exploit, the fix is there to be used

Play fair. Cast fast. Do not exploit. Use AUO.

 

[Xavier]

Yeah. I came up with exactly the same thing in the past. Ive ranted about this targeting issue in Demise staff repeatedly over the last couple years. In fact I'm pretty sure I told you guys we needed to implement this. I know Ive mentioned it to Ryan. But, when we went and tested on OSI, they don't seem to check this either. The macros for current razor versions I tested this with on RunUO code worked fine on OSI as well, so we never did it.

 

[Kraz]

Yeah. I came up with exactly the same thing in the past. Ive ranted about this targeting issue in Demise staff repeatedly over the last couple years. In fact I'm pretty sure I told you guys we needed to implement this. I know Ive mentioned it to Ryan. But, when we went and tested on OSI, they don't seem to check this either. The macros for current razor versions I tested this with on RunUO code worked fine on OSI as well, so we never did it.

It may be the macro or method you used because I tried on OSI and they block every fake request I sent.

Tbh it is kinda hard to test without a modded assistant or proper EUO script, Blacula PMed me with a way to do that using Razor, it may work, not sure, anyways this is a flaw exploitable by EUO scripts.

 

[Xavier]

It may be the macro or method you used because I tried on OSI and they block every fake request I sent.

Tbh it is kinda hard to test without a modded assistant or proper EUO script, Blacula PMed me with a way to do that using Razor, it may work, not sure, anyways this is a flaw exploitable by EUO scripts.

Ill try it again tomorrow, and get you more specifics. The macros I tested with were 100% target spamming.

 

[Kraz]

Ill try it again tomorrow, and get you more specifics. The macros I tested with were 100% target spamming.

The macro/script will "work" but there will be no exploit "effect", the problem is not the spam.

Thing is, your "fake" requests, sending invalid target ids, wont be processed on OSI, however, as soon as you receive the id on client the next target request will contain that id and it will be sent and validated; thats why it is kinda hard to detect and test on OSI without having a modded assistant sending always a fake target, on RunUO fake targets are processed, you can easily put outputs messages all over TargetResponse method and see what I mean.

 

[Xavier]

Actually. There is a simpler way to do it. On OSI (to my surprise), that targetid is not a serial. Its an ID. If you cast a magic arrow, then a fireball, you will have a different value for each. I really expected it to be a serial on OSI, but its not.

If you cast two fireballs back to back, they will have the same IDs.
If two players cast fireballs, each of their own fireballs will match each persons' own fireballs, but they will not match each other.

Simply. This is just an ID defining what target was from ( spells, etc ), and what mobile its associated with and the target ID remains the same for each of the targeted actions, and to be honest, it looks like its only used to check things like stacked spells.

 

[Kraz]

OSI is not the subject but thats interesting, they may use that for checking stackable spells indeed, but it does not change the fact RunUO allow this exploit to happen easily.

I also think that by using this to check for spells, etc; they are opening a leak to that exploit, even if it would require time to setup every target id and changing for every mobile (or a recording system, that grabs it for the first time the spell is used by that char) but thats their problem , by fixing that RunUO it will prevent the exploit entirely, because the target id is not persistant, stacking can be controlled server side.

 

[Xavier]

OSI is not the subject but thats interesting, they may use that for checking stackable spells indeed, but it does not change the fact RunUO allow this exploit to happen easily.

I also think that by using this to check for spells, etc; they are opening a leak to that exploit, even if it would require time to setup every target id and changing for every mobile (or a recording system, that grabs it for the first time the spell is used by that char) but thats their problem , by fixing that RunUO it will prevent the exploit entirely, because the target id is not persistant, stacking can be controlled server side.

Yes, thats why the modifications section is a perfect place for this. Youre right it will help smooth some of this out, but the behavior is nothing like OSI - and yes, OSI is a point in code.

And I think you missed what Im trying to tell you... the character has a very short list of these IDs. It would take one script to test each one of the spells they want to use, and thats the end of that. its not going to do anything but give certain apps like injection and CE an even bigger advantage.

 

[Kraz]

I also mentioned that testing/recording on my post, I did not missed it, thing is you are talking about the way OSI handle target ids, I'm talking about RunUO, this is not a fix for OSI but for RunUO.

 

[Xavier]

I can verify that this EUO bug is 100% valid, and even works through lag spikes if the same spell is spammed. There's a particular Razor macro that floods target requests in the same way, and it has already been sent to Kraz for testing.

If you have anything you would like considered in adressing a problem or inaccuracy in RunUO. Bring it to the RunUO developers, please.

 

[Kraz]

If you have anything you would like considered in adressing a problem or inaccuracy in RunUO. Bring it to the RunUO developers, please.

You can also address AssistUO Developers, just in case AUO may allow stuff like that to happen somehow or to improve the way assistants handle things.
Thanks.

 

[Blacula]

If you have anything you would like considered in adressing a problem or inaccuracy in RunUO. Bring it to the RunUO developers, please.

I came to you myself with this same exploit two years ago, and even sent you the script. How easily we forget.

 

[Xavier]

I came to you myself with this same exploit two years ago, and even sent you the script. How easily we forget.

A lot of stuff was lost from 2 years ago, including every scrap of code that was on the forums in that section.

https://runuo.googlecode.com/ <-- bug reports there, if you have a problem posting let me know

But, in the case of this, its not exactly a "bug". Its working the way OSI have it. But, in all reality, its pretty much a moot point now, seeing as AUO can cast at those speeds by other means. itll be there now, forever, unless we come up with some other approach to actually limit the targeting speed .. OR .. fix our casting timings to match OSI. FCR should not go to 0, ever. Thats the thing, people pick and choose what they think should be fixed and what shouldn't. At the end of the day here, unless we do fix the FCR times, AUO will always cast the same speed as the modifications you guys want to make to the server are hoping to prevent. The only difference is, it will be only AUO that does it.

 

[Blacula]

I seriously doubt AUO will be able to make people anywhere in the world cast at the server base speed. Then again, what do I know?

 

[Lucifall]

AUO will always cast the same speed as the modifications you guys want to make to the server are hoping to prevent. The only difference is, it will be only AUO that does it.

Sorry but you are incorrect Xavier. AUO can not cast at the same speed as this exploit. It WILL cast the fastest without it, but never at the same speed. AUO has to wait for the target to appear, while this doesn't. You can target before your cast is even finished. Now, you could argue this is a queue of sorts, but it's still faster than AUO.

I will try to use my knowledge and replicate what you posted about OSI, but I really think it won't work similar to this exploit being reported here.

This exploit allows ANY spell to be instantly targetted with ANY target icon before it's finished casting. This behaviour doesn't works on OSI. It's a RunUO exploit.

 

[Bile]

Targeting exploit via AssistUO

1 miniheal

You can gain a great amount of skill by holding this down; can be built into every spell combination

 

[Lucifall]

Target closest murderer, target closest innocent or target closest grey isn't the same as target nearest mobile. Does that makes it a cheat?