Jump to content

UseItem exploit fix (duplicate items) - ALL L2J VERSIONS


Tryskell

Recommended Posts

https://www.youtube.com/watch?v=wvwudQvQwIE

 

The video was produced using my pack (or so state the server owner/developer), but L2J got the same issue. All non-customized L2J versions using WeaponEquipTask got this issue. Even if you patched other places to avoid to get multiple similar items with same objectId, this is the initial problem and the only fix you should apply.

 

For the goodness of L2J, I decided to post this fix for free.

 

Short version : Upon UseItem use, and if you're currently attacking, WeaponEquipTask is called to delay the time your weapon is wear.

 

Issue : There is no check upon task call. The item is equipped, no matter what happened between the call time, and the wear time (if you deleted, crystallized, dropped, put item elsewhere,...).

 

Fix : check upon task call if the item is still existing on inventory.

 

For L2J (consider to edit the called method - remove item parameter).

 

   /** Weapon Equip Task */
    private static class WeaponEquipTask implements Runnable
    {
        private final L2PcInstance activeChar;
        
        protected WeaponEquipTask(L2PcInstance character)
        {
            activeChar = character;
        }
        
        @Override
        public void run()
        {
            // Check if the item is still on inventory.
            final ItemInstance item = activeChar.getInventory().getItemByObjectId(_objectId);
            if (item == null)
                return;
            
            // Equip or unEquip
            activeChar.useEquippableItem(item, false);
        }
    }

 

If you use aCis, here's the modified task found on UseItem (will be part of rev 380) :

 

			if (activeChar.isAttackingNow())
				ThreadPool.schedule(() -> {
					final ItemInstance itemToTest = activeChar.getInventory().getItemByObjectId(_objectId);
					if(itemToTest == null)
						return;
					
					activeChar.useEquippableItem(itemToTest, false);
				}, activeChar.getAttackEndTime() - System.currentTimeMillis());
			else
				activeChar.useEquippableItem(item, true);

 

Good luck everyone !  :clap:

Edited by Tryskell
  • Like 2
  • Thanks 3
  • Upvote 5
Link to comment
Share on other sites

2 hours ago, miscer7 said:

So this bug could be existing up to this day to a good portion of java servers? If that's the case I'm kinda buffled how it wasn't found/reported earlier..

 

All L2J servers with unedited WeaponEquipTask, since WeaponEquipTask exists (added at Gracia 1, previous chronicles haven't it). When it has been first added, there was a check regarding isAttackingNow(), which has been deleted since.

 

I tested adding it back to see if it was impacting things, the exploit is still working.

 

People probably made some workarounds, like unallowing non pet stuff, or disabling the pet inventory. My version handles all cases, it simply denies the problem from the root. There's probably more than pet inventory - if you're fast enough, you can drop an untargetable weapon at your feet.

  • Upvote 1
Link to comment
Share on other sites

Just now, Red-Hair-Shanks said:

 private final L2PcInstance activeChar;

i thought L2Pcinstance was renamed to Player :dat::happyforever:

nice job tryskell :D

The second code is for acis you dumbass xD 

Link to comment
Share on other sites

35 minutes ago, Red-Hair-Shanks said:

 private final L2PcInstance activeChar;

i thought L2Pcinstance was renamed to Player :dat::happyforever:

nice job tryskell :D

 

34 minutes ago, Designatix said:

The second code is for acis you dumbass xD 

Muhehehehe 

 

:kappa:

Link to comment
Share on other sites

2 hours ago, Red-Hair-Shanks said:

 private final L2PcInstance activeChar;

i thought L2Pcinstance was renamed to Player :dat::happyforever:

nice job tryskell :D

 

Genius. :goodsir:

  • Haha 1
Link to comment
Share on other sites

Thanks for sharing, bloody legacy code. Even if it's just visual on client for unity as item isn't dup server side, it requires fixing.

Edited by Sdw
Link to comment
Share on other sites

These fixes dont work, was still able to dupe the item (just took few more tries instead of doing it in first or second attempt)

 

Tryskell did you test your fix?

 

And can you put whole UseItem.java so we could see the manner your proposed fix is applied?

Edited by zemaitis
Link to comment
Share on other sites

7 hours ago, zemaitis said:

These fixes dont work, was still able to dupe the item (just took few more tries instead of doing it in first or second attempt)

 

Tryskell did you test your fix?

 

And can you put whole UseItem.java so we could see the manner your proposed fix is applied?

About the code is the correct one and it's working just read the lines and put some logic there. When the time will come to equip the weapon, it will first check if exists in the inventory. There are two reasons if it doesn't work for you.

1) you didn't add it properly 

2) a kind of problem in your thread pool?

Link to comment
Share on other sites

16 hours ago, zemaitis said:

These fixes dont work, was still able to dupe the item (just took few more tries instead of doing it in first or second attempt)

 

Tryskell did you test your fix?

 

And can you put whole UseItem.java so we could see the manner your proposed fix is applied?

 

I put everything needed in first post, and even explained in detailed how and why it works. It's a 2 lines edit, come on. Imagine you remove isCastingNow() check upon casting skill, that's basically the same.

 

And no, I never test any of my shares. I just hit the keyboard blindfolded, hoping something cool happens. That's why aCis is so cool, for example. But you already know it, annoying orange.

 

:dat:

Link to comment
Share on other sites

1 hour ago, Tryskell said:

 

I put everything needed in first post, and even explained in detailed how and why it works. It's a 2 lines edit, come on. Imagine you remove isCastingNow() check upon casting skill, that's basically the same.

 

And no, I never test any of my shares. I just hit the keyboard blindfolded, hoping something cool happens. That's why aCis is so cool, for example. But you already know it, annoying orange.

 

:dat:

 

I am not sure how to apply the fix (tried multiple times) but the bug is still here. My friend tried to apply it on his server and faced the same issue.

 

I created a repository showing how I apply the fix: (I'm using older rev, so the way I call ThreadPool is different, maybe that's the issue?)

 

https://github.com/eurbon/acis_bugfix

 

 

 

 

Edited by zemaitis
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Posts

    • Trustworthy person; hope you find what you're looking for!
    • Customs being added to systextures/animation/texture influences the increase in virtual ram by a very small amount, which means you won't have a headache in the future with critical error issues, unless it's a dubious custom, there are 2 custom weapon packs available for H5 that are "compromised", they didn't make a very good adaptation, one of the packages is the weapons from the goddess of destruction for H5, another is the hero weapons from the goddess of destruction for H5, avoid these customs for your H5 server if you see it on any forum.   Now coming back to your question; one thing that the NCSoft developers never did was add files to their system, probably because they were aware of what could happen when doing that, now think about one thing: the game's system retail itself is no more than 70MB, every time there was an update made by NCSoft they always added the equipment/items/cloaks etc. in their folders intended for that, so why do we do this? I still have my client containing a system with almost 1GB, 1-2h online is the time I can stay online before the ram memory limit, but I have already redone my entire client with customs being destined for textures/systexture/animations, almost all the customs that I had on that client containing a 1GB system I have on my current server, with the difference that I removed everything from the system and critical error is now nothing more than legends, my current server has a total of 220MB in the system folder And theoretically speaking, based on what I've seen, especially on many forums, I believe that the heavier the system folder is, the faster we accelerate the consumption of the client's virtual ram memory, causing countless different types of critical error in one short period of time, in many forums that I've seen on topics involving critical, the solution that stands out the most is about downloading a new clean "system"
    • Do you think that everything on the system is loaded regardless if you use it or not ? or even worst, are they loaded even if they exist as textures/meshes but not defined on the DAT files ?
    • DISCORD : utchiha_market telegram : https://t.me/utchiha_market SELLIX STORE : https://utchihamkt.mysellix.io/ Join our server for more products : https://discord.gg/hoodservices https://campsite.bio/utchihaamkt
    • Yes, it is, it's not hard to do (if you know what you're doing); just time consuming.   To make some things clear: 1. You can not create .ukx files with animated skeletalmeshes inside, by using any of the freeshared L2Editors (basically, no support for .psa files) 2. You need a patched UT2003/UT2004. You can either get your own ut2004 and download Gildor's patch from his web, or use any of these: When you use these, you should be able to import both .psk and .psa animations > link the skeletalmesh to the psa > save as .ukx > use ut2down to convert the file to l2 format > encrypt the .ukx with standard l2 encryption (you can use mxc encdec, you can find it in the folder of the l2editor i shared). Your best bet is to use pawnviewer (aka dev mode) to test that. If you have troubles with that process then leave a reply here, otherwise, if it works correctly, you can move on to adding missing animnotify classes to you unrealed, then proper animnotifies, sounds, effects or w/e is missing from your .ukx files. Keep in mind that this is overall not difficult but a huge amount of work (unless you're good at scripting/macros) since you'd need to manually re-create every single animnotify, by hand. If you have doubts or i wasn't clear enough let me know here. (in case you don't know what an animnotify is: UDN - Two - AnimNotifies (unrealengine.com) )  
  • Topics

×
×
  • Create New...