SolarStrike Software

elverion wrote:

You could try to isolate the Xtrap lowdriver, I doub't its still working but it did a few months ago.

Can you explain further?

Well, the way Fiesta is coded is pretty bad. They are not checking the return values on their function calls, so if you outright block XTrapVa.dll from loading, it crashes because it will try to access memory from an HMODULE that has not been opened. Likewise, if you use an empty DLL, the values returned from GetProcAddress() will also be invalid, resulting in crashing.

Therefor, my proposal is to wait till after Fiesta has done what it needs with XTrap, then unload and block it from reloading XTrapVa.dll. It is an experimental idea, and I do not expect it to work, honestly.

I've tried several other methods, and everything has resulted in a crash. At one point, I was able to log into Fiesta without XTrap and get to play...but I honestly have no idea what I did to accomplish this. I am thus far unable to reproduce it.

I weren't thinking of making XTrap useless, but taking away its Rootkit-like abilities and to protect the memory. Eg. Overwriting DeviceIOControl, GetPixel etc with your own Kerneldriver. Maybe it's not possible that way anymore, or atleast without that less work.

What version of Xtrap is it? I'm maybe going to investigate tomorrow into Orka which has Xtrap 2261 or something and going to retry my fishy method lol, although I think 3100 is already out.. Hmm. Can you give me the lowdriver name and base-offset of Fiesta's Xtrap if you'Re already into it?

It's version 2332.

Your route might just work. Killing it after it's loaded isn't going to; so scratch my plan. I decided to see what would happen if I opened the physical memory while XTrap was running, and write NOOPs from XTrap.xt's begin to XTrap.xt's end. I expected Fiesta to crash instantly...but surprisingly Fiesta continued to run for awhile, and then closed. If only there was an easy way to NOOP most of XTrap, except for the part responsible for constantly sending keep-alive packets to the server.

let me know how has me for that resolution!
what do you need?
you are the man Fox!!!
i know that!!

elverion wrote:It's version 2332.

Your route might just work. Killing it after it's loaded isn't going to; so scratch my plan. I decided to see what would happen if I opened the physical memory while XTrap was running, and write NOOPs from XTrap.xt's begin to XTrap.xt's end. I expected Fiesta to crash instantly...but surprisingly Fiesta continued to run for awhile, and then closed. If only there was an easy way to NOOP most of XTrap, except for the part responsible for constantly sending keep-alive packets to the server.

I noticed that the xtrap of Orka is poorly implented, basically only what prevents hacking is the blacklisting. For poking around in the memory I just autohook it while its loading, and reading memory is possible whenever I want. It wouldnt even matter if theres xtrap or not if you would use a bot, although I hate having "anticheat" services D:

Hmm, if you can hook it, you can write a plugin for it. I can give you the source code for the injector plugin, and you can just add in a few functions, then we'll be able to overhook XTrap. Or if you want, you can send me any code you have and I can write the plugin.

Those hooks XTrap has are low level, too. I tried re-enabling the pure syscalls to invoke functionality, but it didn't work because XTrap was blocking at the kernel level it seems.

elverion wrote:Hmm, if you can hook it, you can write a plugin for it. I can give you the source code for the injector plugin, and you can just add in a few functions, then we'll be able to overhook XTrap. Or if you want, you can send me any code you have and I can write the plugin.

Those hooks XTrap has are low level, too. I tried re-enabling the pure syscalls to invoke functionality, but it didn't work because XTrap was blocking at the kernel level it seems.

It actually remembers me on old GunZ and Hero Online (Xtrap enabled after logging in lol) times, I thought Xtrap had improved atleast a bit. But it's still worse like this, it's basically like a club - Everyone who wants can get inside if the time is right. Ah atleast its not so annoying like GameGuard, which is enabled all the time even if you don't have the game anymore. In Orka you got like 0.5 sec's time to hook anything you want, Xtrap doesn't even bother if it's CE poking around - I really wish the autohook of CE would work. Since about 3 years I'm using the same tool to make games windowed - along with some other settings - who use xtrap, and it never got blacklisted and nor it bothered about if there were things hooked to it.

But yes, XTrap is lowlevel. It should block necessary kernel functions and check flags after it hooked. But that's just about it.
Totally wish I could get in touch with an acquaintance of mine, he was really good at hooks and reverse engineering.

elverion wrote:

You could try to isolate the Xtrap lowdriver, I doub't its still working but it did a few months ago.

Can you explain further?

Well, the way Fiesta is coded is pretty bad. They are not checking the return values on their function calls, so if you outright block XTrapVa.dll from loading, it crashes because it will try to access memory from an HMODULE that has not been opened. Likewise, if you use an empty DLL, the values returned from GetProcAddress() will also be invalid, resulting in crashing.

Therefor, my proposal is to wait till after Fiesta has done what it needs with XTrap, then unload and block it from reloading XTrapVa.dll. It is an experimental idea, and I do not expect it to work, honestly.

I've tried several other methods, and everything has resulted in a crash. At one point, I was able to log into Fiesta without XTrap and get to play...but I honestly have no idea what I did to accomplish this. I am thus far unable to reproduce it.

Fiesta has a new update today and now it uses crypt32 to check integrity of the files and any changes will prevent u from selecting your char.

I did some changes on the files, so i tried something using the previous client (fiesta.bin) instead /w xtrap and it allows me to login. And able to play but crash within 10/20 sec.

So i was suspecting, the crash was caused by checking the client verison instead of Xtrap disabled.

I hope this info can help you in reproduce the bypass

Ooh, this could be useful to know. But they just implemented it today? Well, the random crashing has been happening for awhile, so I'm not sure. Any other information you might have would be greatly appreciated.

any comments?

Nope no comments!

SOO no problem man...

so when is the fiesta bot gonna get some lovin'?

its hard to grind without it xD.