Packet 0x17 support

[RElesgoe]

No description provided.

[RElesgoe]

Type is actually VOID, I only tested 1 address and found that byte was the correct type, at least for the address that I tested

[HarpyWar]

Could you explain how to test this feature?

[RElesgoe]

t_packet    * rpacket;

if (!(rpacket = packet_create(packet_class_bnet)))
    return -1;

packet_set_size(rpacket, sizeof(t_server_readmemreq));
packet_set_type(rpacket, SERVER_READMEMREQ);

bn_int_set(&rpacket->u.server_readmemreq.request_id, 0);
bn_int_set(&rpacket->u.server_readmemreq.address, 0x00596904);
bn_int_set(&rpacket->u.server_readmemreq.length, 1);

conn_push_outqueue(c, rpacket);
packet_del_ref(rpacket);

Create a command with that code and use the command when you're in a chat channel and inside a game, the value will change.

[HarpyWar]

I add function conn_client_readmemory and make it call/handle from Lua 9bd578c

Usage example:
handle_command.lua

...
["/memory"] = command_memory,
...

command\memory.lua

function command_memory(account, text)

    api.client_readmemory(account.name, 1, 0x00596904, 1) -- game mode
    api.client_readmemory(account.name, 2, 0x0057F0F0, 32) -- get minerals of all players in the game
    api.client_readmemory(account.name, 3, 0x0057FE40, 64) -- get game map name

    return 1
end

handle_client.lua

function handle_client_readmemory(account, request_id, data)

    TRACE("Read memory request Id: " .. request_id)

    -- display memory bytes
    DEBUG(data)

    if request_id == 1 then
        DEBUG(account.name .. "'s in game flag: " .. data[0] )
    end
    if request_id == 2 then
        DEBUG("Player 1 minerals: " .. bytes_to_int(data, 0, 4) )
        DEBUG("Player 2 minerals: " .. bytes_to_int(data, 4, 4) )
        DEBUG("Player 3 minerals: " .. bytes_to_int(data, 8, 4) )
        DEBUG("Player 4 minerals: " .. bytes_to_int(data, 12, 4) )
        DEBUG("Player 5 minerals: " .. bytes_to_int(data, 16, 4) )
        DEBUG("Player 6 minerals: " .. bytes_to_int(data, 20, 4) )
        DEBUG("Player 7 minerals: " .. bytes_to_int(data, 24, 4) )
        DEBUG("Player 8 minerals: " .. bytes_to_int(data, 28, 4) )
    end
    if request_id == 3 then
        DEBUG("Game map name: " .. bytes_to_string(data) )
    end
end

Output log http://pastebin.com/Egqnn0RC

[HarpyWar]

@xboi209 if I'm not mistaken, we can get memory flag of "fog of war", so to detect map hack in current games in interval.
Do you know that offset address?

[RElesgoe]

I have many offsets but I don't wish to share them.

[Danteoriginal]

could you please add, Antihack mineral and multi command

thanks so much, regards

[HarpyWar]

@Danteoriginal, to create antihack we need:

1. Hack program for testing.
2. Position offset of the hack in memory.
3. Make sure that the offset value changes when the hack program is activated.
4. Remember original and hacked offset values.

This antihack polls the players once a minute with checking that offset value is changed or not. So it's important that hacked offset is stored in memory for a long time (like maphack). If offset changes for a moment (like autoclick, etc) and then restores the value, it can't be catched.
But if you are familiar with reverse-engeneering, you can find the unique offset that matched the specified maphack program. These offsets are not shared in public because hackers can bypass it in next version of the hack.

[cen1]

1. I have a whole archive of them (for W3) and most of them are accessible online
2. From my experience you need An Api Tracer/Monitor (ex: http://stackoverflow.com/questions/864839/monitoring-certain-system-calls-done-by-a-process-in-windows) to catch the calls to functions like WriteProcessMemory() and once you catch the offsets you need another program to read the before/after value. I did have some success this way except I couldn't see the number of bytes written and what they are from the tracer.
   I believe some hacks are also doing game.dll loading hacks like w3l does so these would need to be traced another way.
3. See 2.
4. See 2.

If we had a common process/tutorial to detect these it would be easy to build a small database of offsets for each game. And the good thing is that a non-coder could do it (moderators :))

@xboi209: Could you give some guidelines on this? It seems you have the most experience in this.

[RElesgoe]

You just need a program like Cheatengine and know how to filter out addresses until you get what you want which is very easy(could be done in minutes). Also specifically for StarCraft, I found a nice list of functions: https://vgce.googlecode.com/svn/trunk/data/Blizzard/Starcraft/1161_Functions_All.txt
I picked out functions with interesting names and tested them to see if hacks change them.
Note that this packet only supports StarCraft, Diablo 1, and WarCraft 2.

[cen1]

Ok, after some more research this is what I got:

1. By running a lot of w3 cheats against a debugger I located the most common offset writes, usually ranging from 0x6F300000 to 0x6F400000 from the base of Game.dll (base is 0x6F00000).
2. There are some outliers which are out of this range but usually just for non-standard hack features
3. Instead of checking every single write of few bytes on every single address (there are a few dozen different between hacks) I instead take a few tens of thousands of bytes from 0x6F30000 and hash them.
4. Hardcode the clean hash
5. Do regular hashes in intervals, If it changes it means something tampered with game.dll in memory.

This method could be implemented together with this packet.

Problems:

1. It is very likely that legal tools would also be detected by this
2. I have not yet extensively tested this with regular usage of W3 but if W3 itself modifies the module while running, this kills the above method completely. Does anyone know if W3 actually writes over the game.dll while running? If it does it could be avoidable by narrowing down the hash scope into smaller/more regions which are hack specific.

I am currently testing the problem 2. together with some other moderators.

Opinions and thoughts welcome.

[cen1]

Ok.. scrap that for now. If game.dll is relocated by the OS to another address, all the addresses in the module are rewritten off the new base address. So the hash gets broken and you'd have to have a clean hash of every possible address to compare against.

I'll have to find a way to take into the account the corrected addresses or target more specific regions in memory.