Newbie Spellweaver
- Joined
- Mar 27, 2014
- Messages
- 5
- Reaction score
- 0
Hello, fellow mortals. I'm trying to make an auction scanner that would save history of goods posted on the AH. Well, the problem is I can't make it reliably read further than 2 pages. First of all, I used ArtMoney to determine pointers to some variables. Unfortunately the only ones I could detect with 100% certainty were the numbers of items per each opened page in the search. Pointer to total number of pages found by search sometimes works (variable is equal to number of pages), sometimes doesn't (variable is not equal or not even readable). Well, I don't need this variable really, I can just list pages till I stop getting new lot IDs. Now, the real mystery is getting the actual lot information. Artmoney was unable to find a pointer to at least first page (by the way page X is only recorded to memory when the page X is actually clicked to). So in my C# program I have to determine pages using patterns. For example I know that first page with 30 items (maximum number of items per page) in memory is always preceded with 1448 (this is 30*48+8, most likely the amount of memory required per page with 48 bytes per lot). And I know that if I search AH for a specific item, say Ragefire I, I can detect it by itemtype ID. So, if I see 1448, and then 30 Ragefire IDs divided by exactly 48 bytes, this is certainly a page with AH lots I've searched for in the game client. Well, this approach is slow, ugly and unreliable. But it works... for first 2 pages. Sometimes 3. Then magic happens. Well formed page lists stop appearing. Not only that, but the only data I manage to find which correlates with AH page I'm looking at is recorded backwards (for example, in first pages data goes like amount, bid value, buyout value, but in such page it will be buyout, bid, amount) with some data missing (no itemtype IDs) and no signs of typically formed pages at all (but maybe I just was unable to find them). So I'm asking for collective mind's assistance if someone have already researched pem.exe or is interested to do it - via PM or posts in this thread. Suggestions for good ArtMoney alternatives to search for variable pointers are also appreciated.
Current goal: detect all lot data locations for an AH search. Hopefully by just determining memory addresses for pages, without search by patterns.
I've attached ArtMoney file with some pointers (you will easily see the address offset pattern for number of lots on each page). Ignore data which is not named in English - it was temporary. But this may be outdated for recent client versions. In that case you can just detect pointers yourself with ArtMoney. itemtype IDs will help you in that, for example gems:
Each gem's url contains it's ID.
48 byte lot structure (first page only):
lot ID - 4 bytes
Current bid value - 4 bytes
Buyout - 4 bytes
Auction expiration unixtime - 4 bytes
itemtypeID - 4 bytes
Amount - 4 bytes
8 zero bytes, probably used for non generic items - 8 bytes
Seller's ID - 4 bytes (15186888 aka C8 BB E7 00 seems to mean Anonymous)
Proably current bidder - 4 bytes
Item quality - 4 bytes (4 - purple, 3 - blue, 2 - green, etc)
Unknown - 4 bytes , usually FFFFFF00 (-256) or FFFFFFEF (-17)
Fun trivia: lot information passed to the client contains an actual lot's expiration timestamp (so it's more precise that just "< 1hr", can be helpful in bidding wars). Also it seems to pass the ID of current bidder, although the client's interface never reveals this info.
Current goal: detect all lot data locations for an AH search. Hopefully by just determining memory addresses for pages, without search by patterns.
I've attached ArtMoney file with some pointers (you will easily see the address offset pattern for number of lots on each page). Ignore data which is not named in English - it was temporary. But this may be outdated for recent client versions. In that case you can just detect pointers yourself with ArtMoney. itemtype IDs will help you in that, for example gems:
You must be registered to see links
Each gem's url contains it's ID.
48 byte lot structure (first page only):
lot ID - 4 bytes
Current bid value - 4 bytes
Buyout - 4 bytes
Auction expiration unixtime - 4 bytes
itemtypeID - 4 bytes
Amount - 4 bytes
8 zero bytes, probably used for non generic items - 8 bytes
Seller's ID - 4 bytes (15186888 aka C8 BB E7 00 seems to mean Anonymous)
Proably current bidder - 4 bytes
Item quality - 4 bytes (4 - purple, 3 - blue, 2 - green, etc)
Unknown - 4 bytes , usually FFFFFF00 (-256) or FFFFFFEF (-17)
Fun trivia: lot information passed to the client contains an actual lot's expiration timestamp (so it's more precise that just "< 1hr", can be helpful in bidding wars). Also it seems to pass the ID of current bidder, although the client's interface never reveals this info.
Attachments
You must be registered for see attachments list