The new function is going to be used in a later commit.
readAll() is moved to mumble_plugin_utils.h and is renamed to readFile(), to make its purpose clearer.
This commit also moves the <math.h> include to mumble_plugin_utils.h, because that's where it's required.
Also, it's now included as <cmath>, as recommended for C++.
Installation paths can now be fine-tuned by setting the respective
MUMBLE_INSTALLATION_* variables when invoking cmake.
Additionally some components that only had install rules for a certain
OS are now installed on all OSes as these components should be needed
there as well.
Installation paths can now be fine-tuned by setting the respective
MUMBLE_INSTALLATION_* variables when invoking cmake.
Additionally some components that only had install rules for a certain
OS are now installed on all OSes as these components should be needed
there as well.
5df2bb2c0b explains how we gain access to the game's interfaces.
Once we have access to the interfaces, we retrieve the address of the variables' we're interested in by reading the assembly of one or more functions accessing them.
The process for each function is documented in the code.
This function is of critical importance for the Source Engine plugin, let me elaborate on why.
Most games consist in an executable and maybe one or more libraries, but they don't have particular exported symbols we can use to easily access (existing) resources inside the process, which means we have to rely on hardcoded offsets and hex pattern scanning.
Source Engine games are special: the executable is nothing more than a manager that takes care of loading the core libraries, which are engine(.dll|.so) and client(.dll|.so) (or server(.dll|.so) in the case of a dedicated server).
Those libraries have a common exported symbol, which is CreateInterface(). The function takes the interface's name as argument (char *), creates the interface object if it doesn't exist yet and returns a pointer (void *) to it. The interfaces objects are stored in a list called s_pInterfaceList, which is usually an exported symbol on Linux.
getExportedSymbol() allows us to get the address to CreateInterface() (different for each loaded library) inside the process and read the function's assembly code in order to reach s_pInterfaceList.
If s_pInterfaceList is exported we can get its address with getExportedSymbol(), without the need of CreateInterface().
- peekProcString(): reads the specified amount of data at the specified address and returns it as std::string. An empty std::string is returned in case of error.
If length is 0, the function reads one byte at a time and stops when either '\0' is found or 3 seconds have passed.
The successfully read data is returned, also in case of error.
- peekProcVector(): can be used to read a dynamic array (size known at runtime) from the process' memory.
Dynamic arrays are part of C99, which should be supported by most compilers nowadays, but std::vector provides many advantages (e.g. easy resize) over a raw array.
- getVirtualFunction(): gets the address of a virtual function given its index and the class object's base address.
A macro called GET_POINTER_SIZE is added because "is64Bit ? 8 : 4" is used in two places now. Also, it's useful and intuitive for plugin(s) programmers.
- sinCos(): calculates sine and cosine of the specified value. On Linux the calculation is guaranteed to be simultaneous.
- degreesToRadians(): converts degrees to radians.
- isBigEndian(): returns whether the architecture is big-endian, by checking how a 4-byte value is stored in memory.
- networkToHost() converts from network byte order to host byte order.
I decided to create our own function because ntohs() is part of winsock(2).h on Windows, which means we would have to link to "ws2_32".
This commit also adds and makes use of the new "OS_WINDOWS" and "OS_LINUX" definitions.
The reason behind their existence is the "_WIN32" and "__linux__" definitions not being intuitive, mainly because they don't follow the same naming convention.
As these plugins typically don't do anything anymore it doesn't make all
that much sense to include them by default.
If you still want to include retracted plugins, use
-Dretracted-plugins=ON when invoking cmake.
Mumble usually ships with all its plugins in /usr/lib/mumble/* but the
new make install target installs them directly into /usr/lib/*.
This however can lead to certain files being overwritten.
Therefore these paths are changed in order to install these libraries
into /usr/lib/mumble/* again.
Fixes#4477
This commit removes all qmake-related build-files from the system. We
have now migrated to cmake and are no longer maintaining qmake anyways
and therefore there is no reason to keep it.
Removing it also clearly states to any potential user/programmer that
this project is no longer intended to be compiled with qmake.
Given that the .pri files no longer exist, the mumble-version.py script
had to be adapted to read the version from the CMakeLists.txt file
instead.
Furthermore a few of the submodules support cmake natively and therefore
we no longer need the src/buid-directory approach in order to build
them. The respective build dirs have been removed and the src-dirs have
been renamed.
Fixes the following warning:
../mumble_plugin_utils.h:33:13: error: 'void escape(char*, size_t)' defined but not used [-Werror=unused-function]
static void escape(char *str, size_t size) {
^
It appeared after bb248cc, due to "ut99.cpp" not using escape().
This commit also:
- Changes the "size" argument so that it is passed as reference.
- Indents the function using tabs.
Supports the 1.0 version of Grand Theft Auto: San Andreas, the only one supported by multiplayer modifications.
The camera's vectors are synced with the avatar's ones; in future we should locate the camera's CMatrix in the game's memory and retrieve the proper values.
No context/identity support; in future we should at least add the context (e.g. server IP address + port) for Multi Theft Auto and San Andreas: MultiPlayer.
The MinGW builds failed with:
In file included from gtasa.cpp:6:0:
../mumble_plugin_main.h: In instantiation of 'T peekProc(const procptr_t&) [with T = unsigned char; procptr_t = long long unsigned int]':
gtasa.cpp:25:59: required from here
../mumble_plugin_main.h:47:9: error: 'memset' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
memset(&ret, 0, sizeof(ret));
^
In file included from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/guiddef.h:154:0,
from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/winnt.h:635,
from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/minwindef.h:163,
from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/windef.h:8,
from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/windows.h:69,
from ./../mumble_plugin_win32.h:21,
from ../mumble_plugin_main.h:95,
from gtasa.cpp:6:
/usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/string.h:53:18: note: 'void* memset(void*, int, size_t)' declared here, later in the translation unit
void * __cdecl memset(void *_Dst,int _Val,size_t _Size);
^
Aside from being faster, it also requires less code.
This commit also changes the way architecture is detected for Win32 processes.
Previously, we relied on the Wine's preloader binary's architecture because we read its ELF header; now we read the NT header(s) by calling isWin32Process64Bit() (implemented in 86154c8234).
This is better than our current method because:
1. We don't need an extra handle (IsWow64Process() requires PROCESS_QUERY_INFORMATION or PROCESS_QUERY_LIMITED_INFORMATION).
2. It's more reliable: our current method consists in checking the result of IsWow64Process() (true if the process is 32 bit on 64 bit Windows) and the size of void * (4 bytes if 32 bit, 8 bytes if 64 bit).
It works correctly with a 32 bit plugin on 32 bit Windows and with a 64 bit plugin on 64 bit Windows; it doesn't work correctly when the plugin is 32 bit on 64 bit Windows: 64 bit processes are detected as 32 bit.
3. We can use the same method on Linux (the NT image is loaded in memory by Wine).
These structures represent the header(s) of an NT image.
There are two ways to read the image:
- Loading the executable/library in memory and then reading the content at the beginning.
- Reading the process' memory at the beginning (base address).
In the case of a loaded library, its header(s) can be found at its load (base) address.
By reading the header(s) we can gather useful info regarding the process, such as the architecture and, in the case of a library, the address of an exported symbol.
This is in preparation for the new Source Engine plugin which will add a few common functions.
This commit also improves the functions arguments so that they are passed by reference and marked as const (when possible).
A new data type called procid_t is created, intended to be a replacement for pid_t (Linux) and DWORD (Windows).
This commit removes the architecture-specific headers, by keeping only the OS-specific ones.
The different headers were needed to keep the legacy Windows header, after we created the "procptr32_t" (4 bytes) and "procptr64_t" (8 bytes) variables.
We created these variables because the "peekProc" functions read as many bytes as the variable can hold. A pointer is 4 bytes on 32 bit platforms and 8 bytes on 64 bit ones.
Now there's a new variable, called "procptr_t" and with a size of 8 bytes (unsigned long long).
We had a "peekProc" template function which returned the value stored at the specified memory address, but it has been used only to read pointers so far.
Since we needed a new function that checks the process architecture and sets the correct size of the memory to read, I decided to "recycle" it.
We used to use DIST for referencing extra files that should be included
in our tarballs created by 'make dist'.
However, we've since migrated away relying on 'make dist' in release.pl.
Instead, we include everything, and have a list of items to exclude, such
as IETF RFC drafts distributed in 3rdparty/speex-src that do not adhere to
the Debian Free Software Guidelines.
