[V] Dynamically adding carcols

Hello everyone,

today we’re going to have a look at how to add carcol settings in GTA V to vehicles at runtime. The file contains the siren patterns for emergency vehicles among others and people have been using it to create their own pattern with the most recent research being made here: http://www.lcpdfr.com/forums/topic/66806-researchwip-custom-light-patterns-through-carcolsymt/. When I stumbled across that post I decided to revisit my research on that topic as it was obvious that the current system was heavily limited, since it only allowed changes to be made before you start the game and only share patterns across a vehicle model.

MulleDK19 and I both had already made some interesting research on this topic and with the new information revealed in the topic, we felt it was time to complete it. Due to my ELS research I had large parts of the siren functions reversed already, so it wasn’t really a cold start. We also knew about the function retrieving the siren settings. At first I wanted to find out whether these settings could be altered in memory during runtime and would immediately reflect in-game.

First tests in memory

At first, I navigated to the siren settings instance in memory and played around with the values a little bit. It was immediately clear that no further work was needed to make those changes take effect in-game, as the pattern adjusted directly. So changing the pattern while in-game was no problem and exposing a function to do that seemed pretty easy. Now it was time to test how deeply wired the memory instance of the siren setting was, i.e. if it just contained the raw data and could be moved or whether there were various references we had to account for. Luckily, it just contains the data, so allocating memory, copying the instance and adjusting the pointer worked fine for any vehicles. At this point I was sure that adding custom patterns at runtime shouldn’t be too hard. But we still needed to solve the problem that it was limited to models instead of single vehicle instances.

Adding per vehicle support

To make it work on a per vehicle basis, we had to check where the siren settings were being used. Using a list to keep track of vehicles with a custom pattern seemed like a good idea. Thus, we intercepted the usage of the siren settings and checked whether the vehicle currently being processed had a custom pattern assigned. If that was the case, we would supply our own pattern, otherwise we would let the original call do its work and use the vanilla settings. This proved to be a really solid setup. You can see the result here:

We could now not only change a pattern at runtime, but also create new patterns and modify those. On top of that we are now also able to assign a specific pattern to a single vehicle instead of it being assigned to all vehicles of a certain model. This will be available for everyone to play around with soon in RAGE Plugin Hook!

OpenELEC on Raspberry with an XBOX 360 controller

13 Replies

I used some of my free time during Easter to install OpenELEC on my new Raspberry PI 3. While most things worked out of the box, e.g. my using my remote control to control OpenELEC, using my 360 Wireless controller did not. Searching the internet revealed it’s a common problem many people have issues with so I decided to give it a go. And after some time and messing around I got it working just fine. Since I’m very new to the Raspberry Pi world and you might as well, I will try to give as many details and steps as possible.

Installing the driver
1.) Enable SSH in OpenELEC so you can connect to your Pi from your computer
2.) Login to your Raspberry using SSH (as a client you can use Putty for instance). Name: root password: openelec
3.) Type “cd /storage/bin”
4.) Download the driver: curl -L -o xboxdrv.tar.gz https://dl.dropboxusercontent.com/u/735405/xboxdrv_pi.tar.gz” (from here http://openelec.tv/forum/124-raspberry-pi/74287-xbox360-wireless-gamepad-support?start=15)
5.) Untar the file: tar -zxvf xboxdrv.tar.gz
6.) Navigate to the new folder: cd xboxdrv
7.) Now it’s time to create your settings file. We’ll use this template: http://pastebin.com/DGz6cNDV (from here http://openelec.tv/forum/124-raspberry-pi/74287-xbox360-wireless-gamepad-support?start=15%20(#135768)
8.) Create a new file: nano settings.ini
9.) Copy the content in the file and save it (Control+X, then y)

Testing the driver
10.) Now we’re almost good to go. With your wireless receiver connected, type in rmmod xpad to disable the default xbox driver
11.) Register the dependencies: LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/storage/bin/xboxdrv/
11.) Test xboxdriver: ./xboxdrv –silent –config /storage/bin/xboxdrv/settings.ini
12.) The driver should start now and you should see it’s output. Turning on your controller and pressing buttons should result in new output in the terminal
13.) Shut down the driver using CTRL+C

Adding the driver to auto start
14.) Navigate to /storage/.config/.kodi
15.) nano autostart.sh
16.) Add the following:

(
sleep 10
rmmod xpad
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/storage/bin/xboxdrv/
/storage/bin/xboxdrv/xboxdrv --silent --config /storage/bin/xboxdrv/settings.ini
) &

This will kill the old xboxdriver (you can also choose to blacklist it entirely) and start the xboxdrv on every reboot, so you can use your controller out of the box. Happy watching!

Recording audio of a single process: Part III

18 Replies

After having hooked IAudioClient::GetCurrentPadding, IAudioRenderClient::GetBuffer and IAudioRenderClient::ReleaseBuffer I implemented some logic for each hook.

IAudioClient::GetCurrentPadding

Here I just copy the pointer to IAudioClient to be able to use it later.

IAudioRenderClient::GetBuffer

In this hook, I copy the IAudioRenderClient pointer and the data pointer so I know where it’s stored.

IAudioRenderClient::ReleaseBuffer

This is where my main logic takes place. At this point our buffer is filled and we get the number of frames written. We know the buffer location from the previous call to IAudioRenderClient::GetBuffer and thus can copy its content.

Copying the buffer

My first attempt was very basic, yet it did work. I simply wrote the buffer to a file with a fixed size. I used Audacity’s ability to import raw audio and ended up with some trial and error approach until I got the correct audio format. Because using a hardcoded size and guessing the format was not an option, I had two new ~~problems~~ challenges to solve.

Since we know the number of frames written, I figured the actual buffer size had something to do with the number of channels and the bits per sample. So the format thing again. Sounded like killing two birds with one stone. I was sure I was very close to getting it working properly.

Figuring out the audio format

A quick look at the audio API documentation releaved there’s a function called AudioClient::GetMixFormat. Now call me crazy but I somehow thought this would return the audio format used.

So I checked the structure it returned and added a function to output the format. Since it matched with the format I used in Audacity (IEEE_FLOAT, 2 channels, 44k) I changed the code responsible for writing the buffer to calculate the size based on the format. A quick test run and Audacity check made me smile: It worked.

I didn’t figure out the audio format

When I tried it on a different process though (Chrome), audio was distorted. One could clearly hear the original audio, but I wasn’t able to get it playing properly, no matter what parameters I used in Audacity. To narrow down the problem I used audio that would only use one speaker and tried to make sense of the output in a hex editor. I saw weird sequences of zeros I didn’t understand and went to SO to ask for help (note: Don’t read my own solution posted there yet).

Unfortunately it appeared no one was able to help me, so I gave it another shot. By further researching AudioClient::GetMixFormat it appeared it could be wrong, i.e. not reporting the format passed to IAudioClient::Initialize. I don’t know for sure why there is no way to retrieve the actual audio format, but I figured I had to read it from some internal structure. Hooking IAudioClient::Initialize was not an option, because I wanted to be able to attach to processes playing audio already.

Figuring out the audio format. Again

To be able to read the audio format from a IAudioClient instance, I fired up IDA and looked through the varios interface functions. However, I couldn’t find anything useful. Debugging the various audio calls and looking for known values (I used Spotify again since I knew its format) finally led to a result in IAudioRenderClient::GetBuffer though.


.text:10019145 154                 mov     eax, [ebx-50h]
.text:10019148 154                 movzx   ecx, word ptr [eax+0ACh]
.text:1001914F 154                 mov     eax, [eax+0A8h]

The values in ecx and eax looked familiar (block align and bit rate). So modying my code to the following utilized the correct audio format now:

mov     eax, pAudioClient
mov     eax, [eax + 0x7C]
mov     eax, [eax + 0x3C]
mov     edi, eax
mov     eax, [edi - 50h]
add     eax, 0xA0
mov     waveFormatEx, eax

At this point I was able to attach to an arbitrary process and record its audio without any other audio interfering. It still crashed the process at sometimes and as noted in the SO post only worked on Win 8, but I was happy with the outcome.

Conclusion

I hope you learned a few things about the audio API and how long it can take to properly research such undocumented stuff. The whole process described above was done on a couple of days over a timespan of 3 months, because I often got frustrated and decided to give it a shot another day.

Later on I also added some nice features like MP3 support to reduce the file size and made the library support IPC (using pipes) so I could record audio from sandboxed processes as well. I also went to add Win 7 support and the ability to mute audio of a process (you just zero the buffer) but that’s not really related to the core research.

Thanks for reading.

Recording audio of a single process: Part II

2 Replies

Today we will focus on mapping the functions found. They all reside in the AudioSes.dll, so this will be our primary target.

Interfaces and IAT

The problem with the IAudioClient and IAudioRenderClient interfaces is, like with all other interfaces, they don’t have their functions exported in the DLL, but are called using their VTables. So you don’t get their functions mapped nicely into your IAT, but have to dig a little deeper. If you are unfamilar with VTables and/or IAT, I suggest you to at least look up the Virtual function tables concept before contiuning to read. I will briefly explain it though.

Virtual functions tables in MSVC

In MSVC classes with virtual functions have their VTable pointer placed at +0x0 in memory. So the very first field contains the pointer to a table where all virtual functions are stored. You can imagine the table being an array of function pointers, each 4 bytes (on x86) in size. During compilation, the compiler replaces a call to object->SomeInterfaceMethod with its index in the virtual function table which could look like this: object->VFT[index].

Mapping addresses from VFT to DLL

In order to find the implementation of the interface functions in our audio DLL, one can simply check the implementation of the interfaces in Audioclient.h. You could also simply call the functions and check the asm output, which will call the function like this:

mov    eax, pAudioClient
mov    eax, [eax+index*4]
call   eax

You can then retrieve the actual location using something like this:

DWORD vTable = *(DWORD*)pAudioClient;
DWORD getCurrentPaddingOffset = *(DWORD*)(vTable + 0x18);

Then calculating the offset is easy: getCurrentPaddingOffset – Audioses base. For Windows 8 (32) bit, GetCurrentPadding would be at 10018D7D (VTable index is 0x18).

So now we know where the interfaces functions are stored in the DLL.

Hooking the functions

Hooking the functions is no different than normal hooking. We could either use the static offsets we gathered or dynamically resolve the addresses from the VTable and use them. The latter is version independent so it’s preferable.

Recording audio of a single process: Part I

Watch Dogs Script Hook goes GitHub

4 Replies

I’ve decided to put my Watch Dogs Script Hook on GitHub because I still receive questions regarding the game, although I haven’t touched neither the game nor the code for ages. So here it is for you to play around:

https://github.com/LMSDev/W_D-Hook

Please note that it does not work with the latest version of the game and should be considered an educational resource for game reversing/hacking. Also note that the code is very hacky and ugly and has major design flaws. But it works! 😛

Adding ALT+Enter (windowed <--> fullscreen) switch to IV

1 Reply

I haven’t posted much the past months due to my work commitment and the fact that the stuff I’m working on currently requires a lot of explanation and thus time to create the posts. I hope I can get some posts out during my winter vacation though!

Anyway, last weekend when I was recording some IV footage I found it unbelievable inconvenient I had to remove the “-windowed” switch and restart the game when I wanted to go fullscreen. Also I couldn’t simply go back to windowed mode then, which was annoying as well, since the fullscreen mode of IV is not known to be very ALT-TAB friendly…

So I thought it would be nice to have a simple fullscreen <–> windowed mode switch. Judging from my recent DX 11 experience I was sure it would be really simple, as it doesn’t involve more than a single call to SetFullscreenState. It turned out it’s more difficult on DX 9 though. Here’s how I finally realized it (research based on EFLC 1.1.2.0 as always):

Finding the windowed code

Okay so we know there is code to make the game windowed at startup due ot the “-windowed” commandline switch. So that’s a good way to start. A simple string search for “windowed” yielded good results: [GRAPHICS] Force windowed mode

Following that led us to the commandline switch we were seeking. Doing an xref in IDA eventually led to this piece of code (without the names usually of course):


.text:007D77DE 048                 mov     g_cmdarg_fullscreenMode.m_pszValue, offset aFullscreen ; "fullscreen"
.text:007D77E8 048                 mov     g_cmdarg_windowedMode.m_pszValue, esi
.text:007D77EE 048                 mov     g_bSettingsIsFullscreenMode, eax

Followed by API calls to SetWindowLongA and SetWindowPos this seemed like the right place. Especially the call below is very interesting:

.text:007D77FF 058                 call    GetScreenSettings

After some analysis it turns out it writes width, height and whether the game should run in fullscreen mode to the variables pushed. We also find bSettingsIsFullscreenMode
being used in that function again. At that time I went in-game to the graphics menu, changed the value of bSettingsIsFullscreenMode in memory and hit Space to apply changes. And it worked: So simple, yet effective!

Manually resetting the d3d device

However it still required us to go in the menu and choose to save changes, which is not as convenient as a simple ALT+Enter anytime during gameplay. Now we had to manually call the code resetting our d3d device and applying the changes. I decided to set a breakpoint on GetScreenSettings and went into the graphics menu again (and saved) just to find it being called from

 .text:00480B4D 034                 call    GetScreenSettings

A more in-depth analysis of this function turned out it is responsible for the graphics menu and only called when you select the Graphics tab in the game menu. Furthermore, once you hit Space, the code at 00480AB3 is called. So by utilizing this code part I was able to reset the d3d device and reflect the change I made to bSettingsIsFullscreenMode. Simple as that!

The next LCPDFR release will contain this function, I hope you find it as useful as I do.

GTA V native invocation

14 Replies

I’ve spent some time recently to have a look at the script VM in V as a preparation for its upcoming release. Since IV is pretty old chances are the scripting engine got some updates, as it was the case for Max Payne 3. One example of a change in MP3 is the native context, which is used to send parameters of a native function from a script to the engine and to pass back return values. Every native function basically has a wrapper function whose only argument is the native context.

Native context in GTA IV

In IV it looked like this (excerpt from C++ ScriptHook by aru)

    class scrNativeCallContext
    {
    public:
        ptr m_pReturn;
        u32 m_nArgCount;
        ptr m_pArgs;
    };

So we have two pointers here that point at memory containing the (possible) return values and the arguments. We also have an argument specifying the argument’s count. This is really simple to understand and to implement in your own code. Note that to return values, R* makes heavy use of arguments passed by reference instead of using the return section of the native context.

Native context in Max Payne 3

Things became a little different in Max Payne 3. One of the changes involved the passing by reference. R* now almost always used the return section instead of pointers. So void GetMaxAmmo(Ped ped, int weapon, u32 *pMaxAmmo) became int GetMaxAmmo(Ped ped, int weapon). While this is definitely a nice change, it doesn’t really affect the implementation and thus can be neglected when creating a script hook. One other change however, may definitely not. The native context‘s structure has changed:

    class scrNativeCallContext
    {
    public:
        GtaThread* m_pCurrentThread;
        ptr m_pReturn;
        u32 m_nArgCount;
        ptr m_pArgs;
    };

Right, it now also has a pointer to a GtaThread. This alone however wouldn’t be something to worry about, if this didn’t introduce some other major change: Pointers in arguments are now passed via the thread’s stack. Say one wants to pass a char* to a native function, it will no longer just push the string. However it will generate an offset, which is a 32-bit value whose first 3 bit indicate the type of the offset/pointer and the other 29-bit specify the offset from the beginning of the stack in bytes. Yes, in bytes, so the stack is definitely not a 4 bytes type array or anything, but looks more like a plain byte array. Maybe even used to pass smaller types/data or prevent alignment to save space. For a string at offset zero (because it’s the first pointer pushed this way this call), the value would look like this: 0xA0000000 The first three bits have the value of five, which is the type for strings. The remaining 29 bits have the value of zero, since it should point at the beginning of the stack.

In the wrapper of a native function, this value is then retrieved like this (before calling the real native):

INT32* stack = thread->Stack;

switch (type)
{
    case STACK_TYPE_STRING:
        // Return the actual value
        return stack[byteOffset / 4];
        break;
}

This will return the char* pointer stored at stack[offset]. So this is a rather major change one has to take into account when trying to invoke native functions in Max Payne 3.

Native context in V

During my research (note that I’m far away from being a PowerPC expert, so please bear with me in case I got something wrong) on V, I found out that this seems not to be used by V. While the wrapper of a native in Max Payne would call a function similar to the code shown above, this is not the case in V. Take a look at the wrapper of GET_MAX_AMMO in V:


.text:82DFC948 n_GET_MAX_AMMO:                         # DATA XREF: sub_82E0A3E0+2F0o
.text:82DFC948
.text:82DFC948 .set var_10, -0x10
.text:82DFC948 .set var_8, -8
.text:82DFC948
.text:82DFC948                 mflr      r12           # set up stack
.text:82DFC94C                 stw       r12, var_8(r1)
.text:82DFC950                 std       r31, var_10(r1)
.text:82DFC954                 stwu      r1, -0x60(r1) # end stack setup
.text:82DFC958                 lwz       r11, NativeContext.m_pArguments(r3) # load native arguments pointer (load [arg_0+8] into r11. this is the native arguments pointer, used to be +0xC in MP3)
.text:82DFC95C                 mr        r31, r3       # move native context into r31
.text:82DFC960                 lwz       r3, NativeArguments(r11) # move first native argument into r3
.text:82DFC964                 lwz       r4, NativeArguments.argument_2(r11) # move second native argument into r4
.text:82DFC968                 lwz       r5, NativeArguments.argument_3(r11) # move third native argument into r5
.text:82DFC96C                 bl        GET_MAX_AMMO
.text:82DFC970                 lwz       r10, 0(r31)   # move native context back into r10
.text:82DFC974                 clrlwi    r9, r3, 24    #  Store result in r9
.text:82DFC978                 stw       r9, NativeContext(r10) # move return value to pReturnValue in native context
.text:82DFC97C                 addi      r1, r1, 0x60  # destroy stack frame
.text:82DFC980                 lwz       r12, var_8(r1)
.text:82DFC984                 mtlr      r12
.text:82DFC988                 ld        r31, var_10(r1)
.text:82DFC98C                 blr                     # return

There is no call prior to calling the native and the arguments are just retrieved from the native context and pushed to the real native. So for some reason, R* didn’t implement this into GTA V, this might be due to different teams working on Max Payne 3 and GTA V, but it might also have proven not to be of any use, I don’t really know.

Script VM native invocation

The script VM now features a whole of 127 instructions, up from 77 in Max Payne 3. Invoking natives however (opcode 45) hasn’t really changed and seems to work the same way it did before. So if this is to remain the same for V’s PC release, there probably isn’t much work needed to adjust our current tool’s (ScriptHook) to work with V.

Watch Dogs Lua Engine Hook #2

29 Replies

I’ve continued working on my script hook for Watch Dogs and now also added support for GetAsyncKeyState in lua. Also, as it can be very handy, I allow lua scripts to run in a loop now, since each is spawned in a new thread. This allows code like this:


while true do
-- Change time when C is down
local result = wdHook.GetAsyncKeyState(67);
if (result == 1) then
test:SetScriptedTimeOfDay(18, 00);
end

wdHook.Wait(50)
end

Quite useful, right?

D3D11 hook

In addition, I got a basic D3D11 hook working, so I’m now able to draw on the rendered image (upper left corner):

I need to move this into a lua callback to add drawing support for lua too, but that shouldn’t be too hard to implement. Once I got that working I’ll do some final tests and then hope to release my hook for all the scripters out there! 🙂

For those of you trying to get ad3d11 hook to work, keep in mind you need to save the jmp Steam places in the function, for instance at D3D11Present. I do this by reading the target address of the Steam call, adding the current location (RIP) to get the full address and then executing something like this:


mov rax, addr
jmp rax

This will keep the Steam overlay working and you can still use your own hooked function by executing it right before.

Furthermore, if you have trouble detouring D3D11DrawIndexed, this might help you (reversed to C++ from original WD implementation):


DWORD64 dwContext = (DWORD64)pContext + 0x0009C08;
D3D11DrawIndexedHook dwCallTarget = (D3D11DrawIndexedHook)*(DWORD64*)(pContext + 0x8D);
return dwCallTarget((ID3D11DeviceContext*)dwContext, IndexCount, StartIndexLocation, BaseVertexLocation);

Happy coding!

Watch Dogs Lua Engine Hook

10 Replies

Today I finished my work on a hook for the Watch Dogs lua engine. It can now load lua script files into the game and execute them and also gives access to all lua scripting functions available ingame, so spawning vehicles, changing time of day etc. is now possible. A short scripting example:


local test = CDynamicEnvironmentManager_GetInstance();
test:SetScriptedTimeOfDay(09, 23);

This simple script changes the time to 9:23. It can be saved as anything.lua and put into /scripts/ folder and will then be loaded by my hook at startup. You can also reload it at any time during gameplay so testing new stuff is pretty easy. I might release the hook to the public soon, depending on how testing goes.

Hook internas

I created a proxy of dinput8.dll to get loaded into the process and then load up my custom C++ dll. The injection works by using the functions loadbuffer and pcall from lua which reside inside Disrupt_b64.dll. Once you found them, you can manually call them and load your own scripts into the game and have them processed like normal game scripts. Protoypes:

int luaL_loadbuffer (lua_State *L, const char *buff, size_t sz, const char *name);
int lua_pcall (lua_State *L, int nargs, int nresults, int errfunc);

All you gotta do is find the lua state in the game and that’s it! You can then call those two functions to load your own script data and execute it while playing.

Expect more soon.

An example screen:

LMS Development blog

My blog about computers, programming and reverse engineering.