Now..
let it be known that I am interested in the code behind this and how it works.. and not using it in-game. Like I said, I've noticed a lot of irregularities as opposed to Odyssey, making me not like the game more and more. I do play it sometimes, but it bores me fast. I've started map-teleporting to get rid of the collectibles and just check that Layla story out. I think that's the only thing that keeps me going into the game every now and then..
The "+Inventory: Get Item" script creates a thread. In the thread, the author is making use of the game's internal TLS to avoid dead-locks. Long story short, he's executing a function called "GetItem" which is determined via scanning for an array of bytes. That function is here:
The names you see in the above are labels I've personally marked in x64dbg, understanding what they refer to.
The function has 2 references in code, out of which one looks like this:
Code: Select all
00007FF742ECDF50 | 48:83EC 38 | SUB RSP,38 |
00007FF742ECDF54 | 8B52 10 | MOV EDX,DWORD PTR DS:[RDX+10] |
00007FF742ECDF57 | 85D2 | TEST EDX,EDX |
00007FF742ECDF59 | 74 1F | JE acvalhalla.7FF742ECDF7A |
00007FF742ECDF5B | 48:8B0D 9EB5C002 | MOV RCX,QWORD PTR DS:[7FF745AD9500] |
00007FF742ECDF62 | 45:33C9 | XOR R9D,R9D |
00007FF742ECDF65 | C74424 28 0D000000 | MOV DWORD PTR SS:[RSP+28],D |
00007FF742ECDF6D | 45:33C0 | XOR R8D,R8D |
00007FF742ECDF70 | C64424 20 01 | MOV BYTE PTR SS:[RSP+20],1 |
00007FF742ECDF75 | E8 16B6FDFF | CALL <acvalhalla._GetItem> |
00007FF742ECDF7A | 48:83C4 38 | ADD RSP,38 |
00007FF742ECDF7E | C3 | RET |
Now if you cross-reference the above with the script, you'll get where some of the stuff originates from:
Code: Select all
get_loop:
mov dword ptr [rsp+28], 0D
mov dword ptr [rsp+20], 1
xor r9d, r9d
xor r8d, r8d
VS.
Code: Select all
00007FF742ECDF62 | 45:33C9 | XOR R9D,R9D |
..
00007FF742ECDF6D | 45:33C0 | XOR R8D,R8D |
..
00007FF742ECDF65 | C74424 28 0D000000 | MOV DWORD PTR SS:[RSP+28],D |
..
00007FF742ECDF70 | C64424 20 01 | MOV BYTE PTR SS:[RSP+20],1 |
The order in which these are executed before the CALL doesn't matter.
Now that function above what it's doing is to give you
OPAL. How do I know this?
Look-up that hash for me, will ya?
EDX contains the quantity. You can see there's a check if 0 or not. So the function, C++-heuristically, looks like this:
GiveItem( p->Hash, qty, 0, 0, 1, 0xD )
If I check other references for this latter function, I get only 1. Which leads into a big function checking for
online stuff:
00007FF745D31C70:&"class scimitar::ULCContentHelper"
00007FF745D31CA0:&"class scimitar::AvengeQuestHelper"
00007FF745D31CD8:&"class scimitar::Pawnhelper"
00007FF745D31D08:&"class scimitar::DailyQuestHelper"
00007FF745D31D38:&"class scimitar::OnlineMenuHelper"
Now.. the other reference leads to this:
You can clearly see this wrapper is a bit more dynamic, not using constants:
Code: Select all
00007FF742EAC02D | 8B4424 68 | MOV EAX,DWORD PTR SS:[RSP+68] |
00007FF742EAC031 | 44:8BCE | MOV R9D,ESI |
00007FF742EAC034 | 894424 28 | MOV DWORD PTR SS:[RSP+28],EAX |
00007FF742EAC038 | 44:8BC5 | MOV R8D,EBP |
00007FF742EAC03B | 0FB64424 60 | MOVZX EAX,BYTE PTR SS:[RSP+60] |
00007FF742EAC040 | BA 01000000 | MOV EDX,1 |
00007FF742EAC045 | 48:8BCF | MOV RCX,RDI |
00007FF742EAC048 | 884424 20 | MOV BYTE PTR SS:[RSP+20],AL |
00007FF742EAC04C | E8 3FD5FFFF | CALL <acvalhalla._GetItem> |
The function above has to do with
scimitar::OnlineGameService::ItemLock. Guess what for?
The reason there's dead-lock handling: when you try to execute GetItem from a spawned thread, game locks here:
So you have to handle the interlocks yourself to get it going.
And now this post is gonna get buried in the countless "how do I?" and "pliz help, crash" replies. I'm kinda glad it will, honestly, as a lot of you give a shit on what you can do with the above, caring only to get your eye-candy custom crap and looking cool n shit.. Bleah..