4/20/2015 UPDATE Au3 Bots not working!!!

matx61971 · 04/21/2015, 19:29

As of 4/20/15 many au3 bots have stopped working not all but some including kurz luxon faction donation they no longer track faction earned ie they think there at zero and never donate REQUEST A FIX!!

WE NEED A FIX!!! Lets Beat ANET AT THERE OWN GAME!!!

.Cdog · 04/21/2015, 19:50

lol

phat34 · 04/25/2015, 06:15

----continuing GR Thread here for time being.....

There seems to be many more changes then first thought.... since GR has issues I am continuing here for now...

Thanks to iTecka for his assistance with getting a better working model and digging up new working Patterns.... This is what we have so far:

Code:

420 changelog...
________________

Crazy Model ID Changes Mostly +6

Crazy Title and Faction Point Changes Mostly +64 to Offset[3]

Function Changes
________________
* Func MemoryReadPtr()
See Below - You are welcome to hard code the changes but I would wait till after the event
 because we are still verifying some of them.. ie.. 0xAC was removed
 because it was not necessary.


Pattern Changes
________________
;UseHeroSkill Pattern -2 Line Change -
_("ScanUseHeroSkillFunction:")
		ADDPATTERN("8D0C765F5E8B048A5BC35F5E83C8FF5B")
SETVALUE("UseHeroSkillFunction", "0x" & Hex(GETSCANNEDADDRESS("ScanUseHeroSkillFunction", -159), 8))
		
;DecreaseAttribute Pattern - 2 Lines Changed -
_("ScanDecreaseAttributeFunction:")
		ADDPATTERN("0F95C04833C923C35B85C00F95C18BC1")
SETVALUE("DecreaseAttributeFunction", "0x" & Hex(GETSCANNEDADDRESS("ScanDecreaseAttributeFunction", 72), 8))

We have removed the 0xAC from the Offset Global String.. since I determined it was not necessary and causing issues...

here is the new string and updated FUNC MEMORYREADPTR()

Code:

Global $420update[] = [ 0x4A4, 0x4AC, 0x4C4, 0x4C8, 0x4D0, 0x5C8, 0x5D4, 0x62C, 0x658, 0x68C, _
	0x6DC, 0x6E4, 0x6F4, 0x708, 0x734, 0x754, 0x758, 0x75C, 0x760, 0x7A8, 0x7B8, 0x7E8, 0x7EC ]

Func MemoryReadPtr($aAddress, $aOffset, $aType = 'dword')
	Local $lPointerCount = UBound($aOffset) - 2
	Local $lBuffer = DllStructCreate('dword')
	Local $A64 = False
		If $aOffset[1] = 0x18 and $aOffset[2] = 0x2c then
			For $j = 0 To UBound($420update) -1
			   If $aOffset[3] = $420update[$j] then $A64 = True
			Next
			If $A64 then $aOffset[3] += 0x64
		EndIf

	For $i = 0 To $lPointerCount
		$aAddress += $aOffset[$i]
		DllCall($mKernelHandle, 'int', 'ReadProcessMemory', 'int', $mGWProcHandle, 'int', $aAddress, 'ptr', DllStructGetPtr($lBuffer), 'int', DllStructGetSize($lBuffer), 'int', '')
		$aAddress = DllStructGetData($lBuffer, 1)
		If $aAddress == 0 Then
			Local $lData[2] = [0, 0]
			Return $lData
		EndIf
	Next

	$aAddress += $aOffset[$lPointerCount + 1]
	$lBuffer = DllStructCreate($aType)
	DllCall($mKernelHandle, 'int', 'ReadProcessMemory', 'int', $mGWProcHandle, 'int', $aAddress, 'ptr', DllStructGetPtr($lBuffer), 'int', DllStructGetSize($lBuffer), 'int', '')
	Local $lData[2] = [$aAddress, DllStructGetData($lBuffer, 1)]
	Return $lData
EndFunc   ;==>MemoryReadPtr

Put the Global String up towards the top of your code...(so it only runs once)

Replace the MemoryReadPtr Function in your code...

Find and Replace the lines to fix the patterns!

...more fixes will be made available if found...
Many Model ID's also have been changed - trying adding six to the ones you have as that is the offset we have found effective so far... a complete list will be made available.

tetesty · 04/25/2015, 13:45

If you are changing scanpatterns, change them right and stop putting variables in them -.-

Also... 0x18 = 24... learn your number conversions -.-

And what you added there to memoryreadptr is a f... disgrace. Just change offsets manually and stop being lazy. Using Ubound on fix array size ... I mean, wtf. Using array to begin with... just stupid.

Oh and btw, a string is a datatype, thats nowhere near your global array.

phat34 · 04/25/2015, 16:33

I know hexadecimal very well actually, wat happen was I left off the 0x when i was up late working on it and corrected it thinking it was a mistake... -1 phat34

* HEROID function was correct as it was... sorry .bout that...

Itecka · 04/25/2015, 16:42

This method for fixing the multilevel pointers I don't condone nor employ myself but do tell me again how I used variables in the patterns I gave him.

Code:

8B78 2C         mov     edi, dword[eax+2Ch]
8B33            mov     esi, dword[ebx]
3BB7 6C050000   cmp     esi, dword[edi+56Ch] // this instruction changed: the offset 56Ch increased 64h from 508h
73 33           jae     007C3BCA             // short jump + 33h bytes
8D46 01         lea     eax, [esi+01h]

// This pattern is identical to the old one other than the single changed byte.

Code:

8B40 2C         mov     eax, dword[eax+2Ch]
8BCE            mov     ecx, esi
05 9C000000     add     eax, 9Ch
8B10            mov     edx, dword[eax]
8911            mov     dword[ecx], edx
8B50 04         mov     edx, dword[eax+04h]

These patterns are fine. Phat does his own thing, I just told him what was wrong.

tetesty · 04/25/2015, 19:42

6C050000

4D1 · 04/25/2015, 20:44

Quote:
Originally Posted by Itecka
This method for fixing the multilevel pointers I don't condone nor employ myself but do tell me again how I used variables in the patterns I gave him.
Code:
8B78 2C         mov     edi, dword[eax+2Ch]
8B33            mov     esi, dword[ebx]
3BB7 6C050000   cmp     esi, dword[edi+56Ch] // this instruction changed: the offset 56Ch increased 64h from 508h
73 33           jae     007C3BCA             // short jump + 33h bytes
8D46 01         lea     eax, [esi+01h]

// This pattern is identical to the old one other than the single changed byte.
Code:
8B40 2C         mov     eax, dword[eax+2Ch]
8BCE            mov     ecx, esi
05 9C000000     add     eax, 9Ch
8B10            mov     edx, dword[eax]
8911            mov     dword[ecx], edx
8B50 04         mov     edx, dword[eax+04h]
These patterns are fine. Phat does his own thing, I just told him what was wrong.

Those patterns are fine but they have the same weakness they had previously. You are keeping unsafe data in the signature which will change if they ever push another major update.

phat34 · 04/25/2015, 20:50

Wait... won't we have to change it again with another major update anyhow...? Or are you saying those two patterns were weak and thats why they broke?

There is no guarantee that any of the patterns will stick for that matter... but I see your point, kinda... but are you being sarcastic? or are you serious... LOL

...and I know I am not perfect...Testy Test! I am just not as much of a stickler as u are and I see why it would be important dealing with the intricacies, performance and speed...

4D1 · 04/25/2015, 21:49

Quote:

Originally Posted by phat34

Wait... won't we have to change it again with another major update anyhow...? Or are you saying those two patterns were weak and thats why they broke?

There is no guarantee that any of the patterns will stick for that matter... but I see your point, kinda... but are you being sarcastic? or are you serious... LOL

Answering respectively...

No you wont.

Yes.

They will stick perfectly fine if they dont have unsafe data in them. Hence why the rest of the patterns that DIDNT have unsafe data in them are fine.

Would I ever bullshit you <3

Quote:

Originally Posted by phat34

...and I know I am not perfect...Testy Test! I am just not as much of a stickler as u are and I see why it would be important dealing with the intricacies, performance and speed...

Anyone can **** out code, good performance and formatting is what sets you from the rest.

Itecka · 04/25/2015, 22:09

Code:

// ScanUseHeroSkillFunction
// 8D0C765F5E8B048A5BC35F5E83C8FF5B
// -159

Code:

// ScanDecreaseAttributeFunction
// 0F95C04833C923C35B85C00F95C18BC1
// +72

var != offset

Better?

phat34 · 04/25/2015, 22:12

Quote:

Anyone can **** out code, good performance and formatting is what sets you from the rest.

Hey ! I am on the learning curve still! I can now understand the patterns and thats great!.... I stated my reason for the array fix and if and when the new working gwa2 is released I will use it with the hard code changes..... iTecka updated the patterns per you fellas' request and I am editing them in my post.
Still testing functions and I may find some more issues....

...nothing wrong with using Ubound here... The GWA2 author used Ubound two lines above my use of it... granted the Array is a set number of values, but my intention was to be able to remove and add Offsets where needed without changing any other lines and it works perfect! I was sure to make sure I wasn't breaking any other code by making sure each offset set was unique... other than the title ones which all receive the plus 0x64 hex... this allows people to update there old gwa2 bots without changing too much in each bot (check1) ... I was also well to explain my reasoning for not hardcoding at the current time... Not that I have to explain what or why I am doing things --- and I agree the correct way is to hardcode and use the same GWA2 with every bot... but this really is not feasible for the majority of the bots out there because everyone that writes them makes the mistake of changing their GWA2s for one reason or another... SO IN SUMMARY - maybe I will just add a disclaimer that says - for PUBLIC CONSUMPTION ONLY!

[END OF RANT!]

4D1 · 04/26/2015, 03:16

Quote:

Originally Posted by phat34

SO IN SUMMARY - maybe I will just add a disclaimer that says - for PEOPLE THAT ARE TOO STUPID TO POINT OUT MY FLAWS ONLY!

[END OF RANT!]

ok

bigpuffy · 04/26/2015, 04:23

Well I'm to dumb to get any bots working with any of the work you fine folks have done. I think It's awesome that there are still people that have the ability to obtain, use, and improve this type of unique knowledge.

Back to the ole keyboard and mouse clicking for this old guy

Quote:

Originally Posted by phat34

Originally Posted by phat34 View Post

SO IN SUMMARY - maybe I will just add a disclaimer that says - for PEOPLE THAT ARE TOO STUPID TO POINT OUT MY FLAWS ONLY!

[END OF RANT!]

tetesty · 04/26/2015, 10:33

So, instead of just being not lazy and doing a little counting, adding and substracting, you use UBound. Made my point there.

Your explanation as to why you dont want to "hardcode" those changes is just as flawed as your use of UBound, and an array to begin with. Anet will not revert those changes back exactly to how the game was compiled before update.

If you want to script a solution to update all gwa2 files, take a look at 4D1's gwbible updater. Or simply write a macro that will search for those offsets and adds 0x64, theres several macro tools out there that can do it.

Quote:

makes the mistake of changing their GWA2s for one reason or another

a) those are highlevel functions that can just be copied and pasted and
b) you are changing a core function of gwa2, which is just so much worse than just changing highlevel functions like moveto.