Post: [DISCONTINUED/TU11/1.12] EBOOT Builder (with AntiBan++)
12-19-2014, 06:25 AM #1
Prom1ses
Bounty hunter
(adsbygoogle = window.adsbygoogle || []).push({});
AntiBan/CFW Notice
It seems people with CFW are getting server-side bans issued (even people who are not cheating). These bans seem to be done every few days and are done in waves (ban queues). Please install the latest PSNPatch *Plugin* to prevent yourself from getting added to a ban queue. AntiBan++ seems to be going strong for those Smile

This is an EBOOT Builder for TU11.

Just browse for the ELF, apply desired options, replace EBOOT.BIN in /dev_hdd0/game/X/USRDIR.

EBOOT/SELF Crash Notice
So after playing AW for a few hours, I often came across error messages such as "Out of Memory", "Exceeded Image Assets", etc. The game tends to re-load the default_mp.self as a fail-safe rather than quit the game completely. This means you are loading the game all over without an anti-ban. I got banned after joining a game without mods. To ensure this does not happen to you, replace the default_mp.self with the generated EBOOT.BIN (expand spoiler below for tutorial).

1) Generate an EBOOT with the builder.
2) Delete EBOOT.BIN and default_mp.self over your FTP client.
3) Copy over EBOOT.BIN. Rename it to default_mp.self
4) Copy over EBOOT.BIN again.
5) Either CHMOD 666 both of those newly copied files or Fix permissions in something like Multiman.

Now you should have both EBOOT.BIN and default_mp.self being the same file on your PS3.

That's it.

Kudos to MegaMister, Eddie Mac, and RatchetBooty for the hack offsets.

Screenshot:
You must login or register to view this content.



Boot to Exo Zombies Technical Details (1.10): So when I first started looking into this, I looked into how it was done on Black Ops 2. It was so much easier, people just patched the branch instruction right next to the string that said "startZombies". Advanced Warfare seems to be a little different. Not many strings reference the functions, thus making reversing a bit harder. But let's get started...

I figured doing this with a DEX would be 1000x easier as you could set breakpoints and find out what is going on where. But this was done purely with static reversing. I started first by looking up "startZombies", the strings were not referenced in any functions within the elf, which made things annoying. So instead of doing that, I went looking for ANY references to zombies.

I came across "zombies", and "horde". But those aren't really what I was looking for... After going through more and more referenced strings "ui_zm_exo_slam_next_time", "fonts/zm*", "code_post_gfx_zm_mp"... I ended up noticing something... Right before referencing a string specific to a game type, it would call 0x3B9758 (I'll call this, "DETERMINE_GAME_TYPE"). It would then do a compare to R3 right after calling that function. Only if R3 was NOT 0, would it load "zombie" content. Okay cool. So lets look at that function more specifically...

Inside DETERMINE_GAME_TYPE, it would load an integer from 0x29F3CE0. Essentially doing "return *(int*)0x29F3CE0;". So where is this value exactly set? Looking at Xrefs of 0x29F3CE0, we can see its written in three different locations. At one point its written in the an init() function ( 0x3BC558 ). But that seems to be done after its loaded the game. Pretty sure the value needs to be set prior to that. But to what?

Let's just cheat a little here... Boot into Multiplayer, connect CCAPI, read the integer at 0x29F3CE0, result: 0x1. Okay cool. Let's boot into Exo Zombies from the Single Player executable and check that integer again... This time, when booted into Exo Zombies, it changes to 0x5. This makes sense as when looking at xrefs to DETERMINE_GAME_TYPE, one of the values functions commonly compare it to is 0x5.

Okay, so how do we make the value 0x5 ourselves? Easiest way? Overwrite the DETERMINE_GAME_TYPE. My initial release (v2.4) simply did a return 5. This made the Exo Zombies menu appear, but did not actually allow a game to be started (kept complaining about issues referencing save data). This was confusing...

Turns out the problem was because other functions reference 0x29F3CE0 too. That's not good as that integer is probably still set to Multiplayer mode (0x1) even though we have the Exo Zombies menu. Solution? Make the DETERMINE_GAME_TYPE function overwrite the integer value at 0x29F3CE0 in addition to returning it (since we know its being called quite a bit anyways). So essentially DETERMINE_GAME_TYPE is now doing this...

    int DETERMINE_GAME_TYPE {
*0x29F3CE0 = 5;
return 5;
}


Let's start it up and confirm it works. Yeup! That's it. It actually took longer than it should have... I was really counting on a simple branch instruction change. This method is a bit more dirty. Nonetheless, it works :P

I hope this helped you learn something?
AntiBan++ Technical Details: First, I wanted to talk a little bit about AntiBan. I'm not putting anyone down, but just NOP'ing all the calls within the ban functions is not the best thing to do... I want to fix that. To do that... I am releasing the offsets and technical details of my AntiBan that I named AntiBan++, below:

[S]1Austin112's AntiBan is pretty good[/S]. But the use of NOPs everywhere can have unexpected results (it is appropriate at some times)... Specifically relating to the stack. For example... If NOP'ing a ban function call, the proceeding opCodes that follow may require specific results from that call. Which is not the best thing in the world... It might result in a freezes as it'll have unexpected register values.

I also don't really like the steps recommended to apply the antiBan via RTM tools... Just like on Black Ops 2, antiBan via RTM timing is not a good thing to rely on... EBOOTS are a lot more reliable as they're patched before the game executable is even ran. Making it the most effective.

Here's what I did... (Subtract 0x10000 for file/eboot offset).

TLAwesome faceR (TU11 Offsets): 1: 0x3C653C --> NOP (0x60 0x00 0x00 0x00)
2: 0x5AD734 --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x5AFD68 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x659448 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x6599BC --> NOP (0x60 0x00 0x00 0x00)
6: 0x7D8F84 --> NULL (0x00)
7: 0x659A34 --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
TLAwesome faceR (1.10 Offsets): 1: 0x3BC10C --> NOP (0x60 0x00 0x00 0x00)
2: 0x5A2FEC --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x5A5620 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x64E920 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x64EE94 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7CD114 --> NULL (0x00)
7: 0x64EF0C --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
TLAwesome faceR (1.09 Offsets): 1: 0x3BBFAC --> NOP (0x60 0x00 0x00 0x00)
2: 0x5A2DEC --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x5A5420 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x64E720 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x64EC94 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7CCEF4 --> NULL (0x00)
7: 0x64ED0C --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
TLAwesome faceR (1.08 Offsets): 1: 0x3BBEBC --> NOP (0x60 0x00 0x00 0x00)
2: 0x5A2D24 --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x5A5358 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x64E660 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x64EBD4 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7CCE74 --> NULL (0x00)
7: 0x64EC4C --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
TLAwesome faceR (1.06 Offsets): 1: 0x3B35E8 --> NOP (0x60 0x00 0x00 0x00)
2: 0x5973C0 --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x5999E8 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x6429A0 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x642F14 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7BFD9C --> NULL (0x00)
7: 0x643F8C --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
TLAwesome faceR (1.05 Offsets): 1: 0x3B3518 --> NOP (0x60 0x00 0x00 0x00)
2: 0x597220 --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x599848 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x642800 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x642D74 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7BFBBC --> NULL (0x00)
7: 0x642DEC --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
Technical Details on AntiBan++ for 1.05:
First offset: 0x3B3518 --> Patch this to NOP (0x60 0x00 0x00 0x00)

Over here is a call to a function that performs nothing but a ban check. I've seen other AntiBans NOP stuff /within/ this function such as at 0x597914. Its much safer and cleaner to just prevent this entire function from being called in the first place. So NOP it at the branch to this function ( 0x3B3518 ).

Second offset: 0x597220 --> Patch this to LI R3, 0 (0x38 0x60 0x00 0x00)

This is the major function that performs bans (its obvious by the strings ;P). Other AntiBans also NOP all the calls following the strings (e.g "EXE_COD_ONLINE_PERM_BAN_PLAYER"). If you look around the beginning of the function: 0x597228, there is a (IF R3 == 0) { GOTO 0x597490; }. If you look at 0x597490, you will see it gracefully exits the function. Just apply the bytes above and the code will look like this:

R3 = 0;
if(R3 == 0) {
GOTO GRACEFUL_EXIT();
} else {
performBanChecks();
}

Thus ALWAYS gracefully exiting the ban function and not requiring all the numerous NOPs that follow if R3 is NOT 0.

Third offset: 0x599848 --> PATCH THIS TO BLR (0x4E 0x80 0x00 0x20)

This function performs bans as well (e.g "EXE_COD_ONLINE_PERM_BAN_CONSOLE"). It is called way too many times (you can check with IDA by pressing x on the function). There are 16 xrefs. Don't apply 16 NOPs. Just make the function return immediately if its called. 4 Bytes versus 16 * 4 Bytes always sounds much cleaner to me Smile

Fourth offset: 0x642800 --> Patch this to NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)

This is the one I did not see anyone patch... Every time you join a lobby, a task called "anticheat" is spawned. I don't know about you... But I don't want anything with that running ;P

By applying the NOP you are overwriting the call to start the task. The proceeding bytes (0x3B 0xE0) are to make R31 = 0. There is a compare condition right after the call. If start_task made R31 = 0, it assumes the task started successfully. So in addition to NOP'ing the call, we make R31 = 0 to ensure the BEQ condition at 0x64280C is called and not the nasty "Failed to start task" error getting printed to console and possibly refuse online game play. Moving on... Smile

Fifth offset: 0x642D74 --> Patch this to NOP (0x60 0x00 0x00 0x00)

This one I felt like patching just because it also had anticheat and a check to make sure the console ID is NOT full of zeros. This just NOPs the if(R31 == 0) { err("Failed to read Console ID"); }. This is an optional patch, but is useful.

Sixth offset: 0x7BFBBC --> Patch this to 0x00

This is the "anticheat" string. It is used to specify which task to start. Since this is a null-terminated string, if we apply a null (0x00) to the beginning of the string, the string is effectively empty when referenced. I patched this because at 0x642D88, when the if(R3 == 0) condition runs... it also starts the task 'anticheat'. I couldn't NOP out the call at 0x642DE8 like how I did in the fourth offset because this seems to get called for other tasks that are essential for the game to run. So killing the string effectively stops the task from being spawned at that point. However... NULL is not a valid task, so the condition at 0x642DF0 will fail and say "Failed to start task".

if(R30 == 0) {
weGood();
} else {
somethingWentWrong();
}

Which brings me to my final offset...

Seventh offset: 0x642DEC --> Patch this to LI R30, 0 (0x3B 0xC0 0x00 0x00)

This will effectively assume all tasks successfully started (by making R30 = 0; right before the if condition). and not log the failure to spawn the inexistent task that we NULL'd. :P
And that is an effective proper antiban. Been using this along with a few friends for the past few days. Dozens of games. Even idling in lobbies for hours at a time (which commonly results in bans, since 'anticheat' task is spawned in the lobby. Refer to technical notes above for more info).


Anyone is free to use my AntiBan++ implementation as long as credit is given.
I also did not encrypt or attempt to hide any of the source of this... So it can easily be reflected with .NET disassemblers. Tiphat

You must login or register to view this content. (You must login or register to view this content.)
You must login or register to view this content.

You must login or register to view this content. (You must login or register to view this content.)

You must login or register to view this content.


MD5 Hashes:

ZIP = eb1e3eb9d1934482a13a19021d450555
ELF = bbf43ed231c06c32b7dad6002652cecc

Getting Error 0x80010017?
I've been told that people experiencing this issue have been able to resolve this by using 'Iris Man'.

Change Log:
    
v2.7 - Adjusted to "TU11". Adjustment for DEX.
v2.6 - Updated to support 1.12/TU11 and [S]adds improvement to DEXs getting Out of Memory errors (especially when Force Hosting)[/S] (did not work well for CEXs converted to DEX).
v2.5 - Fixed "Boot to Exo Zombies".
v2.4 - Bug Fixes (Steady Aim/Random Freezes) & Added "Boot to Exo Zombies" option as prom1sed. Smile
v2.3 - Updated to support 1.10 (Boot to Exo Zombies option coming soon).
v2.2 - Updated to support 1.09 (sorry I took awhile. Had to make a new icon xP).
v2.1 - Adds ability to Enable [URL="https://i.imgur.com/HGOO8MN.jpg"]Exo Zombies[/URL] menu (requires Season Pass to play/Is PSN even issuing the maps for this?).
v2.0 - Updated to support 1.08 and added BLJM & FTP under build options (noob-proof automatic installation!).
v1.9 - Added Force Host.
v1.8 - Added [URL="https://www.nextgenupdate.com/forums/call-duty-advanced-warfare-modding/775320-addresses-offsets-scrips-tutorials-1-06-updating-post6253722.html#post6253722"]'Awesome faceisable Perk Protection'[/URL]. Allows Red Boxes to appear on all enemies regardless of Perks.
v1.7 - Updated to fix NPUB/NPES issues. Also added build support for NPUB31553, NPEB02087, NPEB02088, NPEB02092, NPJB00664, NPJB00665.
v1.6 - Updated to support 1.06 update.
v1.5 - Fixed BLES build issues and added alert for working around 0x80010017 if experienced.
v1.4 - Advanced UAV tab in previous versions was just UAV, corrected the offset and added normal UAV functionality. Added NPUB/NPES support as well. Also adjusted the way the EBOOT is built to help prevent error 0x80010017. Let me know you had that error and if this resolves it.
v1.3 - Added Attach Freeze Fix - Credits to Tustin!
v1.2 - Turns out err 8001007 was for DEX/DEBUG EBOOTs. Was spitting out 3kb EBOOTS, lol. Fixed.
v1.1 - Adjusted some vars for building the EBOOT. Might fix err 8001007.
v1.0 - Initial Release


Leave Feedback Below (along with the CFW you're running, Backup Manager, BLUS/BLES/NPUB/NPES) Smile
Last edited by Prom1ses ; 04-17-2015 at 03:39 AM. Reason: Pushed v2.7 (Changed to TU11, DEX adjustments)

The following 202 users say thank you to Prom1ses for this useful post:

_HURT_, /SneakerStreet/, ✮ Preditah ✮, دختور خصيان 911, One, |_Lion_|, 0zersub, 3ric_M0535, 6775, A Friend, A_Gen_Fiasco, A6shRkm, ALI ALHILFI, Gambler, Antonio96C, aplon, Ariel R., AtlanticModz, AustinMods-, AutoModder, B3nsung, b3tl1ng, bandimo, bhoot-iq, Bigmoneyhustlin, BISOON, blabla122222, Blaze Modding, Bluntyy, Boliberrys, Bradosty, Calyx, carnage29, CBauer, ccgmod, charlesrwoods, chris1976, Cien, CODHoster1337_, Country Boy, Crazy_Ace3214, Creepzoid 0___0, darkknight787, DecoyOcToPuS, dolby1, doneo, Drughi, dsm-tech, Eddie Mac, Egoford, ElCaptainsVs, emotionzmodz, endoemodz, EternalHabit, Fizzy Joon, FlareFlames, Full-Evil, Funzaur, gaming_nation, garpbaldo, Gay For Satan, Geo, GermanSmokezZ, H4x0R LeGiTz, HBRXIII, hdtv_duke, HiddenHour, HighModzz, HUGOLARA25, Hunter926, ICookNades, iDon, iHaxel, illusion_time, imax_pro, ImSpeedOG, iridium7890, ishangiri2014, Welsh, JAKE_1496, Jimmy, JimmysModz-, jlyon11, JoAan2, joni_djESP, jpzoou, JulienDev, KaozHG, KaraTaylar, KINGMANI, koekiemonstarr2, KUMANECO, LBP1906, Dzre-, Legended, LetThereBeMods and 102 other users.
12-19-2014, 06:38 AM #2
BISOON
Maggbot timeout!
Nice this is really hard work Smile

Gud job
12-19-2014, 06:41 AM #3
smashedya
I’m too L33T
nice work brah Enzo
12-19-2014, 06:44 AM #4
EternalHabit
Former Staff
holy f%$k

Originally posted by Prom1ses View Post
This is an EBOOT Builder for 1.05.

Just browse for the ELF, apply desired options, replace EBOOT.BIN in /dev_hdd0/game/X/USRDIR.

Kudos to MegaMister, Eddie Mac, 1Austin112, and RatchetBooty for the hack offsets.

Screenshot:
You must login or register to view this content.


First, I wanted to talk a little bit about AntiBan. I'm not putting anyone down, but just NOP'ing all the calls within the ban functions is not the best thing to do... I want to fix that. To do that... I am releasing the offsets and technical details of my AntiBan that I named AntiBan++, below:

1Austin112's AntiBan is pretty good. But the use of NOPs everywhere can have unexpected results (it is appropriate at some times)... Specifically relating to the stack. For example... If NOP'ing a ban function call, the proceeding opCodes that follow may require specific results from that call. Which is not the best thing in the world... It might result in a freezes as it'll have unexpected register values.

I also don't really like the steps recommended to apply the antiBan via RTM tools... Just like on Black Ops 2, antiBan via RTM timing is not a good thing to rely on... EBOOTS are a lot more reliable as they're patched before the game executable is even ran. Making it the most effective.

Here's what I did... (Subtract 0x10000 for file/eboot offset).

TLAwesome faceR (Offsets): 1: 0x3B3518 --> NOP (0x60 0x00 0x00 0x00)
2: 0x597220 --> LI R3, 0 (0x38 0x60 0x00 0x00)
3: 0x599848 --> BLR (0x4E 0x80 0x00 0x20)
4: 0x642800 --> NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)
5: 0x642D74 --> NOP (0x60 0x00 0x00 0x00)
6: 0x7BFBBC --> NULL (0x00)
7: 0x642DEC --> LI R30, 0 (0x3B 0xC0 0x00 0x00)
Technical Details on AntiBan++:
First offset: 0x3B3518 --> Patch this to NOP (0x60 0x00 0x00 0x00)

Over here is a call to a function that performs nothing but a ban check. I've seen other AntiBans NOP stuff /within/ this function such as at 0x597914. Its much safer and cleaner to just prevent this entire function from calling in the first place. So NOP it at the branch to this function ( 0x3B3518 ).

Second offset: 0x597220 --> Patch this to LI R3, 0 (0x38 0x60 0x00 0x00)

This is the major function that performs bans (its obvious by the strings ;P). Other AntiBans also NOP all the calls following the strings (e.g "EXE_COD_ONLINE_PERM_BAN_PLAYER"). If you look around the beginning of the function: 0x597228, there is a (IF R3 == 0) { GOTO 0x597490; }. If you look at 0x597490, you will see it gracefully exits the function. Just apply the bytes above and the code will look like this:

R3 = 0;
if(R3 == 0) {
GOTO GRACEFUL_EXIT();
} else {
performBanChecks();
}

Thus ALWAYS gracefully exiting the ban function and not requiring all the numerous NOPs that follow if R3 is NOT 0.

Third offset: 0x599848 --> PATCH THIS TO BLR (0x4E 0x80 0x00 0x20)

This function performs bans as well (e.g "EXE_COD_ONLINE_PERM_BAN_CONSOLE"). It is called way too many times (you can check with IDA by pressing x on the function). There are 16 xrefs. Don't apply 16 NOPs. Just make the function return immediately if its called. 4 Bytes versus 16 * 4 Bytes always sounds much cleaner to me Smile

Fourth offset: 0x642800 --> Patch this to NOP; LI R31, 0 (0x60 0x00 0x00 0x00 0x3B 0xE0)

This is the one I did not see anyone patch... Every time you join a lobby, a task called "anticheat" is spawned. I don't know about you... But I don't want anything with that running ;P

By apply the NOP you are overwriting the call to start the task. The proceeding bytes (0x3B 0xE0) are to make R31 = 0. There is a compare condition right after the call. If start_task made R31 = 0, it assumes the task started successfully. So in addition to NOP'ing the call, we make R31 = 0 to ensure the BEQ condition at 0x64280C is called and not the nasty "Failed to start task" error getting printed to console and possibly refuse to join online. Moving on... Smile

Fifth offset: 0x642D74 --> Patch this to NOP (0x60 0x00 0x00 0x00)

This one I felt like patching just because it also had anticheat and a check to make sure the console ID is NOT full of zeros. This just NOPs the if(R31 == 0) { err("Failed to read Console ID"); }. This is an optional patch, but is useful.

Sixth offset: 0x7BFBBC --> Patch this to 0x00

This is the "anticheat" string. It is used to specify which task to start. Since this is a null-terminated string, if we apply a null (0x00) to the beginning of the string, the string is effectively empty when referenced. I patched this because at 0x642D88, when the if(R3 == 0) condition runs... it also starts the task 'anticheat'. I couldn't NOP out the call at 0x642DE8 like how I did in the fourth offset because this seems to get called for other tasks that are essential for the game to run. So killing the string effectively stops the task from being spawned at that point. However... NULL is not a valid task, so the condition at 0x642DF0 will fail and say "Failed to start task".

if(R30 == 0) {
weGood();
} else {
somethingWentWrong();
}

Which brings me to my final offset...

Seventh offset: 0x642DEC --> Patch this to LI R30, 0 (0x3B 0xC0 0x00 0x00)

This will effectively assume all tasks successfully started (by making R30 = 0; right before the if condition). and not log the failure to spawn the inexistent task that we NULL'd. :P
And that an effective proper antiban. Been using this along with a few friends for the past few days. Dozens of games. Even idling in lobbies for hours at a time (which commonly results in bans, since 'anticheat' task is spawned in the lobby. Refer to technical notes above for more info).

Anyone is free to use my AntiBan++ implementation as long as credit is given.
I also did not encrypt or attempt to hide any of the source of this... So it can easily be reflected with .NET disassemblers. Tiphat

You must login or register to view this content. (You must login or register to view this content.)
You must login or register to view this content.

You must login or register to view this content. (You must login or register to view this content.)


MD5 Hashes:

ZIP = f290b717fdaf81a50f673c3f02eb4866
ELF = c4a19d6555dc52fbb39d9f8c5f78b3b4

Leave Feedback Below Smile


so how fast do you think they will patch this?

The following user thanked EternalHabit for this useful post:

Pwnaggge
12-19-2014, 06:55 AM #5
One
At least I can fight
nice job, it will get patched pretty quick though :p
12-19-2014, 06:58 AM #6
Kratez301
Do a barrel roll!
This is probably going to get patched pretty quick :(
12-19-2014, 07:13 AM #7
Hybridmodz
Save Point
8001007 error was up with that

The following user thanked Hybridmodz for this useful post:

supgirl123
12-19-2014, 07:17 AM #8
Kratez301
Do a barrel roll!
I get an error when I try to start up the game even though I re-set the game permissions on Multiman.
12-19-2014, 07:20 AM #9
Hybridmodz
Save Point
is it 8001007
12-19-2014, 07:22 AM #10
OverLimit
Save Point
Game starts but asks for update 1.05. I'm using the elf that you posted. Will try mine.

Edit: Solved the update, it seems I forgot to update before hand, silly me. Games runs on MM with internal and BD Patch, will test and will leave feedback on antiban. Thanks!!

Edit: Doesn't seems to be working. Tried online but none of the hacks(steady aim, no recoil and red boxes) works. Will try v1.1.
Last edited by OverLimit ; 12-19-2014 at 07:47 AM.

Copyright © 2024, NextGenUpdate.
All Rights Reserved.

Gray NextGenUpdate Logo