[DK22]

Hi guys I just looked on how game loads textures from txd. And I wanted to add some my textures there and get the RwTexture pointers of them. But the problem is:
The game loads texures when it loads, so it's impossible to write any asm-injectores in .scm. So I need to jump somewhere, but I dunno where...
Pics:



This post has been edited by DK22: Aug 5 2011, 10:34 AM

[Silent]

I think you jump from 0x706DA6 to your code to such code (something like this):

CODE

mov _textLampShad64, eax
push ebx
push [your texture name]
call _RwReadTexture
mov [your RwTexture pointer], eax
add esp, 30h
jmp 706DAE

And in destroy thingy jump from 0x706F5C:

CODE

mov eax, [your RwTexture pointer]
push eax
call _RwTextureDestroy
add esp, 34h
ret

You can not jump back to code, it's useless to jump to return opcode (plus, it wouldn't be possible, too less space).

[DK22]

I dunno where to create my code... Maybe there are some free space in .exe?

[Silent]

Why not write raw ASM in C++ code, then redirect EXE code to it?

[DK22]

Ahh can you pls tell me how to make it?
Like
0@ = label @__asm offset
in CLEO

[Silent]

Well, I hope Deji doesn't treat it as top secret and won't ban me for life

In functions defining part define both functions as voids. They'll carry our ASM.

Below it, you should do something like:

CODE

DWORD* _textLampShad64 = (DWORD*)0xXXXXXXX; <- real address of this

It will make _textLampShad64 usable like in IDA ASM view. * means it's a reference to memory address, not a new value by itself.

Below you should define your new (real) variables.

CODE

DWORD _yourTexture128;
const char aYourTextureName[] = "yourtexturename128";

'const' puts variable in .rdata, I think. Change names ofc.

Then, in patch()'ing part add:

CODE

patch(0x706DA6, 0xE9, 1);
patch(0x706DA7, (DWORD)&LoadCustomParticle - 0x706DAB, 4); // jmp LoadCustomParticle

patch(0x706F5C, 0xE9, 1);
patch(0x706F5D, (DWORD)&DestroyCustomParticle - 0x706F61, 4);

Note that your patch() define may not require typecasting address as a dword, my function does though.

The last thing is just making our ASMs.

Paste them as new functions:

CODE

void __declspec(naked) LoadCustomParticle()
{
    _asm
    {
        mov        _textLampShad64, eax
        push    ebx
        push    offset aYourTextureName
        mov        eax, _RwReadTextureAddress <-- REPLACE IT WITH FUNCTION ADDRESS!
        call    eax
        mov        _yourTexture128, eax
        add        esp, 30h
        mov        eax, 706DAEh
        jmp        eax
    }
}

void __declspec(naked) DestroyCustomParticle()
{
    _asm
    {
        mov        eax, _yourTexture128
        push    eax
        mov        ecx, _RwTextureDestroy <-- REPLACE IT WITH FUNCTION ADDRESS!
        call    ecx
        add        esp, 34h
        ret
    }
}

And it should works well

I became so 1337 recently

@Deji
Look, it damn can't handle tabulators well.

This post has been edited by Silent: Aug 9 2011, 11:12 AM

[DK22]

ahh
Thank you very much for writing this.
I tried to make it.
http://pastebin.com/RNw1we3d
But I donst see any changes. And when I close my game, it crashes.

So I loaded texture "shad_exp", and stored RwTexture to the 0xC403E8. (aHeliShadow)
Then I created this shadow, but it still has texture with heli's shadow.

Code which I used:

SANNY

Wanted this code? GTFO

UPD:
works now! Silent, thanks again

SANNY

Wanted this code? GTFO

But when I close game, it still crashes...

This post has been edited by DK22: Dec 23 2011, 12:52 AM

[Silent]

Any log from SA Limit Adjuster? I'm too lazy to test it by myself

Edit:

CODE

void LoadCustomParticle(void);
void DestroyCustomParticle(void);

You can leave brackets blank ().

CODE

mov     dword ptr ds:[0xC403E8], eax

Perhaps making it just

CODE

mov     C403E8h, eax

Will help? (0xXXX and XXXh makes the same result, btw).

Edit2:

I just noticed. Why not make your own variable to store RwTexture pointer instead of using this address?

Try this instead. Untested, written in pastebin text box

http://pastebin.com/6pMMyvew

Edit3:
Ah, I see. You REALLY need to call it via CLEO? I think you should pass a pointer to your variable and then read it to SCM thread. I don't trust using EXE free space

This post has been edited by Silent: Aug 10 2011, 11:36 AM

[DK22]

I think it will help, thanks.

0xXXX and XXXh makes the same result, btw

Yeah I know, but it dont compile if I write [123456h], only [0x123456]. I use C++ Builder 2002, maybe because of it...
And yeah, I need it for use in CLEO.

I think you should pass a pointer to your variable and then read it to SCM thread. I don't trust using EXE free space

You mean, write values (adresses) to SCM thread? But threads create only after loading, I think... Maybe I just need to make a loop with waiting until the thread will create, but its too complex, I think, so I gonna make another injector to .asi, from some space in .exe, looks like

CODE

.exe code, some function in .exe
jmp @_asi_asm_inj
00 00 00 00
00 00 00 00
00 00 00 00 // 3 RwTexture will be there
--> continue the function, jump here from .asi

ED
but yeah its impossible to rewrite functions' text without "patching"...

This post has been edited by DK22: Aug 10 2011, 12:05 PM