原来还存在有不需要抓包，直接修改本地内存数据就能弄出超强存档的网络游戏啊……

把最有趣的一段放在这里给码农参悟一下

SagaWalt said: ↑
Well that is only partly true cuz some can still be recovered if u want. Some, only some though...

Dont ask me where to find them cuz i dont remember either. But i havent find anything important from them yet. if u do please share...

++++++++++++++++++++++

expanded manatama's GG guide to work with SP and hero level, along with +lvl and * rarity that manatama had. Most of the steps are just going to be copy/paste'd though.


Start with this no matter what you're changing:

1. Go to equip skills.

2. Choose character, press next.

3. On the char portrait there's [+], select that.

4. On the char page, click heart / favorite.

5. GG, search for 100 (byte).

6. Back to char, deselect fav.

7. GG, search for 101.

8. Keep on going until you found one.

9. If you have 2, then the one ending with 0 is the correct address. (Fav address)

10. Save that address (floppy disk) icon.

11. Go to saved list, tick the address, press the hamburger menu on toolbar (last on the right).

12. Select move address (can also say change address).


Here's where it splits off depending on what you're doing


+10 level:

13. enter -60, tick copy.

14. repeat 12 on (fav address), -64, tick copy.

15. on the -64 address, edit byte to "Ah", use hex.

16. on the -60 address, edit byte to "00", use hex or not doesn't matter.

17. press back to go to the equip skill screen.

18. click the home button to return to your castle.

19. go back to the equip skills screen and equip/unequip something and the effect will take place.


Transform to 5 stars:

13. enter -70, tick copy.

14. repeat 12 on (fav address), -74, tick copy.

15. on the -74 address, edit byte to "05" (or 04 for 4 stars, 03 for 3 stars etc)

16. on the -70 address, edit byte to "00"

17. press back to go to the equip skill screen.

18. click the home button to return to your castle.

19. go back to the equip skills screen and equip/unequip something and the effect will take place.


Edit your hero's level:

13. enter -58, tick copy.

14. repeat 12 on (fav address), -5C, tick copy.

15. on the -5C address, edit byte to "40" (or 39 for lvl 39, 38 for lvl 38 etc)

16. on the -58 address, edit byte to "00"

17. press back to go to the equip skill screen.

18. click the home button to return to your castle.

19. go back to the equip skills screen and equip/unequip something and the effect will take place.


Edit your hero's SP (max up to 383):

13. enter -4, tick copy.

14. repeat 12 on (fav address), -8, tick copy.

15. on the -8 address, edit byte to "255" (max)

16. on the -4 address, edit byte to "-128" (min)

17. press back to go to the equip skill screen.

18. click the home button to return to your castle.

19. go back to the equip skills screen and equip/unequip something and the effect will take place.


NOTE FOR SP: It's better to just delevel your character and relevel them back to max so they can gain more than 383 SP going from 1-->40, especially if you have a Lyn or similar where a skill costs 500 SP (more than the 383 max you can get.)


Also, I’m not sure if you can do all this at once, so I would just do it individually (the value you save will still be the same so you don't need to res search if you're doing it for the same character)


Basically just parsing this: instead of the data being stored in a DWORD (32-bit), it's essentially stored in a QWORD (64-bi). Changing the difference immediately reverts back to the true value, you need to use XOR between the two 32 bit values (DWORD) to get the true 64-bit value (QWORD). If you search QWORD using game guardian, you can get the difference, but you can’t directly edit it- you have to change the actual DWORD values, and I'm not sure how to do that.


Summoning prices

Dword (memory range for my device is C++ Alloc)

1;5;33;17::13

Where 5 is the price.

Should have 2 sets of results.


This is purely visual and price won't actually change.



Edit:

If it is inapp/orb store.

Goto the inapp for orbs.

Dword

110;30::5

Should only have 1 result.

Goto address

4bytes below 30 is 74 (like a price identifier for those orbs)

4bytes above the 110 is the string marked to the inapp 74.99


Using offset calc, go negative 600 from 110.

Should bring you to the inapp 40+8 bonus.

Go negative 600 from that.


You are now at the 1.99 inapp 3 orbs + 0 bonus

The string 4bytes above the 3,if you copied and replaced the 74.99 string with it and click the 74.99 inapp purchase, it will bring up the 1.99 purchase...

I couldn't get the inapp system tricked, but maybe someone can see something else I missed.


I figure the more I share, more progress that can be made.





Also. Keep this in mind. ANY screen change, values change location.

So if you left the inapp screen and went back, all values relocate. This applies to every screen. If your transition from one screen to another, values relocate. Some reason, the summons prices don’t...



While trying out some stuff I found the address for the orbs needed to keep summoning. So I changed it to 0. Visually, it works... but not really.

let's say you have 15 orbs. It says "want to use 0 orbs to summon?" and tells you that your 15 orbs will become 15 orbs (aka stay the same). However, it ends up lowering your orbs anyway... and if you try to summon with 0 orbs when you don't have enough orbs, this error appears.


Anyway, the value for the required orbs is just below the two identical addresses I mentioned before.

I mentioned how before.

1;5;33::9

That’s the search to perform.



libcocos2d.so was compiled with the GNU C Compiler.


The company that made the game made a big mistake leaving all the RTTI info in the binary.


So to help you with your IDA reversing there's an idapython script called gcc_rtti.py by Igor Skochinsky that will open the gate of the kingdom for you ;-)


Just google it, I can't post links on this forum yet.


It's slow as hell. Took some hours in my computer. But what this scripts gives you is well worth the time.



Some pointers now that you're using the right tools for this work:


srpg::unit::Data stores all the info related to each individual unit (character_id, hp, xp, attack, ...)


srpg::unit::Manager stores a list of all your units. There's a global variable that points to this.


srpg::unit::troop::List contains all your teams


sakasho_analytics::cheat::Reporter you’ll have to bypass this "maddafacka" if you do something serious ;-)



Honestly, a lot of you just don't understand XOR.


First, I'd I suggest reading up what the XOR (exclusive or) operator does.


================================================================

For this example I'm going to be using the two values which are stored to represent the star rating. (These are found by using offsets from the "favourite/heart" address.


0x8afc9379

0x8ffc9379


Google a XOR calculator.

And XOR these two hex numbers together


What do you get?

0x05000000


Why is it 0x05000000 and not 0x00000005?

Look up little endianess. The computer is storing the least significant value first.


===============================================================


Endianess Explanation:


Let's take a look at decimal numbers.

The value 123 is 100 + 20 + 3.

The digit 1 (100) is the most significant digit and we write it first.

The digit 2 (20) is the second most significant digit and we write it second.

The digit 3 (3) is the least significant digit and we write it last.


If we write 100 + 20 + 3 in little endianess it'd be 321

The digit 3 (3) is the least significant digit and we write it first.

The digit 2 (20) is the second least significant digit and we write it second.

The digit 1 (100) is the most significant digit and we write it last.


================================================================


Ok, back to the original.

Why are there two numbers?

Well one is the XOR key and the other is the XOR'd value

They're using a XOR cipher (wikipedia XOR_cipher)


0x8afc9379 <= XOR'd value (0x05000000 XOR'd with the key)

0x8ffc9379 <= XOR key


A lot of people have figured out that you can easily get around having to calculate the XOR'd value by making the XOR key 0x00000000.

Anything XOR'd with 0x00000000 will be unchanged.

========================================================================================================


Why are the stat values stored as two numbers and calculated using a XOR?

I think it's probably to prevent people from scanning the memory to find the values (but they messed up with the favourite stat).


How is the XOR key generated?

From what I can see, it appears to be random.


I think their code (in pseudo code) is basically


u32 star_rating = 5;

u32 xor_key = random_u32();

u32 xor_value = star_rating ^ xor_key; // ^ is the bitwise XOR operator.

store(xor_key);

store(xor_value);


===============================================================================


TL;DR Find the xor_key address and make it 0x00000000 and then you can make the xor_value address the actual value without having to calculate anything.


Some tips for those who can use them:


What you're editing in memory are instances of the srpg::unit::Data class. So go to IDA and take a look at:


libcocos2dcpp.so+0x4A2EEC -> is the srpg::unit::Data constructor. It sets most of the fields to 0. You can learn how the data is structured and how the XORing works.


In version 1.0.2 most of the fields where stored in two contiguous memory addresses. One of them being a random number and the other being the result of XORing the previous random number with the actual value. For example, what you call "character id" was stored at offsets 0x28 & 0x2C of srpg::unit::Data.


In 1.1.0 they moved the variables a little bit and added some padding in some of them. "Character id" in 1.1.0 is now at offsets 0x30 & 0x38 (non contiguous addresses).


What you call "character id" is in fact a pointer (just XOR them to know where they point to). This reversing trip will take you to srpg::data::person::List lands.


If you're interested in the summon hack just put a breakpoint on the srpg::unit::Data constructor, summon something, "execute till return" and then just find what writes to the "character id" field. Backtrace said function to know where it gets this “character id" and rarity and patch it to whatever you like.

the python script you Referenced, i ran this a few times on x86 and the arm version 1.02 and 1.10 but it never finishes, it always ends with a search box popping up asking me to locate the class.

I don't know if it's any help (or if you guys already know), but you can find the memory region of an enemy unit by searching E5/ED. E5 = normal, ED = long-pressed show attack region (red).


If you want something done the best way is to do it yourself.


Got to say, this thread is a lot more entertaining to read now that I can control the summon. Possible on both 1.0.2 and on 1.1.0, but a bit more difficult on 1.1.0 depending on the method.


Word to the wise - don't morph units you haven't summoned legit and don't merge beyond the number of a unit you've summoned legit. They know. If they want to, once exploits are patched the ban hammer will come down. Not sure why some are arguing XYZ is stored client-side - the whole of the account data is stored server-side. But this thread has been silly for a long time now.



A helpful tip - you can morph units on the summon screen but it won't change whether an exclamation mark is unlocked or not, and you'll still have to sync after the summon. You'll know if you've controlled the summon because no additional syncing will be needed.



I am not planning to post a tutorial for the time being - but it is still possible to perform on 1.1.0 - so good luck hunters.

Here's some hints for those trying to control the summon process.


IDA was fun to look through and I'm sure that if you're a wizard and can edit packets then that opens up more possibilities, but my method of summon control can be done solely with GG/CE and done using the information provided throughout this thread (along with a little creativity and deductive reasoning). I have no idea how others control the summon but again, I developed a method that works 100% of the time and used only GG/CE and MATLAB (MATLAB not necessary but I used it to automate finding certain values).


Lots of half-correct assumptions floating around here. Many are on the right track but just a tad off with their assumptions. Again though - if you have read this entire thread and are creative/deductive (perhaps lucky too), you're equipped to pull it off.


I've been advising caution about morphing units (due to the summon records they might run against the account database) but here's another fun fact: most of the morphing strategies produce illegal units. These units look/behave normally, but I know of at least two separate flags within their unit data that are a dead giveaway as to whether they were morphed from story/arena vs. acquired legit via summoning/events. Props to anyone who can pinpoint them - one is quite easy to find and the other is much more subtle.


I have no idea whether everyone here will receive the ban hammer or not - all I know is that if they want to ban accounts that have morphed than they can do so in an automated fashion so long as the morphed units are on it (it doesn't matter whether your account looks "sketchy" or not). They might not ban against these things - but they have the ability to, no question about it now. Typical procedure for that is to wait until the exploit is fixed for good though before swinging the hammer down, barring arena/unobtainable nonsense.


Good luck to those racing against the update clock. If it gets patched for good I'll be happy to provide a full tutorial here for the curious.

I've been advising caution about morphing units (due to the summon records they might run against the account database) but here's another fun fact: most of the morphing strategies produce illegal units. These units look/behave normally, but I know of at least two separate flags within their unit data that are a dead giveaway as to whether they were morphed from story/arena vs. acquired legit via summoning/events. Props to anyone who can pinpoint them - one is quite easy to find and the other is much more subtle.



Are you even aware of what a database is?


Everyone's account is stored on a server. All Nintendo has to do is write a "check all accounts for XYZ, flag these accounts to be banned on this date" piece of code and run it through the database. It would take 5-10 minutes to code and could be run the same day.


This isn't a game like LoL (where player interaction can be toxic) that warrants manual bans or an account inspection team. I don't understand why people here assume that someone at HQ is going to be looking at a selection of sketchy accounts and going "hurr de durr this account look good, this account look bad, etc." There's no issue with a +10 Roy if you've summoned Roy 11 times - but there is an issue if you have a +10 Roy but have only summoned Roy 3 times. Very easy to check this stuff across all accounts by just running some code, but it's typically not done until the exploits are patched so that they only have to scan the database once for that exploit. Arena shenanigans are likely being banned now in occasional waves to assuage the influx of people complaining about the hacking.


They're going to write a script, run all accounts against it, and the accounts that fail the integrity check will be flagged to be banned. This typically occurs in waves and bans occur at a time well after detection so as to not allow hackers to easily know exactly what got them banned. If we want the best chance of surviving, we absolutely need to know how to influence the summon process before it registers the character with the server for the first time.


PSA


If no-one publicly releases a method to control the summoning procedure, it's likely everyone here will get banned.


The game can clearly tell if you've summoned a unit legit or not (exclamation point vs. no exclamation on summoning screen).


If you morph a unit and then summon the same unit legit, the legit one WILL have the exclamation point still. They can detect your morphs that way - easy - and they very likely know how many of each unit you've summoned.


They are probably banning for heavy/arena abuse now and will wait to dish out most bans until after they've patched all exploits.


TLDR: Someone had better find a way to control unit generation from the summoning screen or we're all banned and the work here will have been pointless.

卧槽这个1v1的战斗演示跟我在做的一模一样
从曹操传「单挑」出来的想法....

模拟城市那个手游刚出的时候，我直接拿修改器改内存把各种资源都改了。