TOM_RUS

This line was removed: - recv_data.read_skip(16); // unknown 16 bytes: 00 07 01 00 00 01 05 00 06 00 09 01 08 00 03 00 You both either using some custom patch or have merge error.

Actually you can, but this can't be enabled from server side for normal client. Only GM client has such functionality and it was never leaked. But you can use different memory hacks available on the net that provide such functionality.

Why you even need that? It's not useful anyway and different for each client build.

Modulus size is 256 bytes (2048 bit), exponent size is 4 bytes.

Are you sure your windows binaries compiled as x86? Because it looks like they aren't. I guess it's better to look for similar errors on unix/wine forums.

You can try run it in Wine, may be it work. It will never work on unix natively.

Probably not if you first start mangos and then wardend. But I haven't checked in code how reconnection work in this case.

Actually warden packets can't be bigger then 512 or 1024 bytes length (warden module has two fixed size internal buffers 512 bytes length both where it stores strings and warden data).

This is because data stream encryption is desynchronized. You have to do both encryption and checks in either wardend or mangosd to fix this. Also will eliminate desync problem.

The easiest way to fix this problem will be move all cheat checking code from wardend to mangosd, and use wardend only to get encryption keys... It will also reduce useless network traffic between wardend<>mangosd and make it faster overall.

Will never happen.

No. Client won't run random crap. All modules are RSA signed and validated by client.

May be it's time to move it to public section? I've done limited testing and it seems to work if (memContent[i]!=checkList[i].mem->Result[pos]) valid = false; // It returns false because I need to have proper result stored for 3.3.5 I changed it to "false" and haven't got kicked, I guess you already have proper data in DB. Also your MEM_CHECK and FILE_CHECK client structs probably wrong for cases where "memory can't be read" or "file doesn't exist".

Cheaters can change whole game world, not just textures. It's not that hard to put SHA1 of the files in DB in addition to file names. This can be useful for someone.

You seems to be missing MPQ file check validation (client returns result + SHA1 of the requested file). Also I saw few grammar typos.

Client returns n bytes from memory address specified in cheat check packet. So you can just query your client with all mem checks and store results. If you receive some different result, something is wrong, as it's mostly used for checking read only code segment. Ofc there's some checks for data segment as well (like wall climb angle, gravity etc...) Client returns it's tickcount in CMSG_TIME_SYNC_RESP packet.

Correct. First one is Grunt login and second is Battle.net login. Battle.net login can't be used in mangos due to RSA server signature check in client.

Actually, I think it's possible to send Holidays data using SMSG_CALENDAR_SEND_CALENDAR. This opcode has uint32[26] array and two uint32[10] arrays similar to Holidays.dbc. I think we can take data from 4.x Holidays.dbc and send them in SMSG_CALENDAR_SEND_CALENDAR. Ofc that's only theory, I haven't tried to do that...

You can use lua APIs: ReportBug("description") ReportSuggestion("description") CMSG_BUG struct (same as in master branch): uint32 type; // 0, 1 - bug or suggestion uint32 data_len; string data; // some additional data, like map, character, system info, coords, zone, auras etc... uint32 desc_len; string desc; // description given by user

There's no ETA.

Player positions are sent for out of range group members in void Group::UpdatePlayerOutOfRange(Player* pPlayer) and unless your fork heavily modified it should work fine.

No one said it's not possible. Closed.

Yeah, very annoying.

Nice. But why do you store values as uint64+uint32 instead of array uint32[3] like it supposed to be?

It has nothing to do with "Max allowed socket connections 1024". Read next two lines.