Client patching for 4.x support

[XTZGZoReX]

Well, it's about time we start discussing it, and how MaNGOS will handle it both practically and legally. We won't get around patching in one way or another.

We generally have two approaches:

* Use a loader that injects a DLL into WoW which then patches the memory.

* Patch the executable on disk.

Personally, I prefer the latter. It's easier.

I wrote this tool a few months ago: https://github.com/Trinity-Encore/Encore/blob/master/Trinity.Encore.Patcher/ClientPatcher.cs

It uses pattern scanning to find offsets in the executable to patch, so it works for virtually any 4.x executable.

[VladimirMangos]

Without resolve this part we can have any progress with 4.x support

Specailly important question is we can include sources of tool to mangos repo if talk about patcher (that also more simple if allowed from legal point) or loader...

[Lynx3d]

Hm i can't really say that i know how this stuff works...

Would dll injection also work under wine (linux)?

What to do with the Mac client? Is it a universal binary (PPC + x86)?

[VladimirMangos]

Good questions. Binaries patching at least more easy port possible for another client platforms form code work part and pattern update part.

[TheLuda]

Since Wine emulates the Win32 API injection should work there, too. Try and see

From the legal side it does not really matter which route we chose, limitations are the same as with pre 4.0 clients anyway.

[VladimirMangos]

So practical question, can we include like tool sources in mangos repo, without creating problems for project?

[XTZGZoReX]

I vote for static binary patching. Less possible Win32 bugs to deal with for Wine users.

[VladimirMangos]

If this look acceptable do you will can have time/will rewrite it to C++?

Just from pratical point before none req. in mangos have C# compiler... Not all have C# installed, i am for example ^^

[Auntie Mangos]

If that is fine with everyone, I would suggest to a) place the tool into its own repository, and b) go for binary patching.

And if anyone has a funny name for the tool, have a go and tell us

[Neo2003]

Iif anyone has a funny name for the tool, have a go and tell us

TrustUs

DevilSide

SignSwap

BreakTrue :cool:

...

[Auntie Mangos]

hehe, I sort of like BreakTrue. Nice one

[VladimirMangos]

If that is fine with everyone, I would suggest to a) place the tool into its own repository, and b) go for binary patching.

You meaning repo under mangos account or totally independent repo?

[Auntie Mangos]

It can be inside the mangos account. After all it is merely a binary patcher, much like Blizzard uses themselves

https://github.com/mangos/BreakTrue is all yours.

[VladimirMangos]

nice.

Next question: currently it C# program, we can ofc use it as-is but if it will not include binary version then will create problems for ppl - req. additional VS component installed. So is it ok have binary form with project? if ok, then we can possible just use as-is, right?

[XTZGZoReX]

Pushed the source. Ready to push the binaries if that's OK.

[DasBlub]

hm, i just noticed that this project is under the MIT license. i assume this is no problem because it's in a diff. repo as the rest of mangos, right? (mangos is under GPL (was it GPLv2 ?)).

[XTZGZoReX]

hm, i just noticed that this project is under the MIT license. i assume this is no problem because it's in a diff. repo as the rest of mangos, right? (mangos is under GPL (was it GPLv2 ?)).

It could be in the same repo and still be licensed under the MIT License. It only matters if we linked this program directly into MaNGOS.

[Neo2003]

Hello,

I did port it to C++, was quite easy.

I can't access a sharing site from here and cannot find a way to attach a file, so you will have to wait for this evening

[VladimirMangos]

Nice, as i say better have similar programming language use for linked projects/tools for decrease problems for users.

License as i understand must be preserved. But if none objections core replaced by C++.

Then we not need binaries maybe and less legal points then.

[Neo2003]

Here is the files: http://trunk.dyndns.org/BreakTrue-C++.rar

[XTZGZoReX]

Hi,

I would recommend using std::vector instead of explicit arrays.

[Neo2003]

I don't really agree XTZ

Initializing a const std::vector is a pain in C++

I would have to do either:

const std::vector<byte> replace(5);
replace[0] = 
replace[1] = 
...

or I would have to overload some std::vector operator to fill it anyway with an array, so a time lost for me and the application

And all this just to remove the arrays length I have to pass arguments to the methods.

[Neo2003]

Btw, new version. I did prevent from searching after the end of the data and removed the size in arrays creation.

http://trunk.dyndns.org/BreakTrue-C++0429.rar

[VladimirMangos]

Crash if run not in wow dir. But more bad news. For me fail patch 4.1.0 exe ((

Addition info: C# version also fail patch. So tool required offset or more deep updates (

[Neo2003]

Crash if run not in wow dir.

The second link I posted fixed this.

But more bad news. For me fail patch 4.1.0 exe ((

Addition info: C# version also fail patch. So tool required offset or more deep updates (

I have same problem, unable to patch neither wow.exe 4.0.3, nor 4.1.0. Only wow.exe 4.0.6 patches properly.