You can even think of the first primer mine as the theory, the symbian symphony tutorial I wrote too as a commented exercise book and this last one by argv as an advanced exercise book without much comments. Indeed is not old, because srd once unlocked is almost the same system as s60 then the tutorial applies there as well.
But also if you do not unlock the sd phone, the IDA approach is exactly the same no differences. The assembler is the same, the OS is afterall almost the same..
The entire process is clear to me, and now i think it just practice that i need. Programs that have strings built into the exe are fine, easy to get to the branch points, but programs that use resource files, i still am not clear how to map the resource to the code.
Can you please suggest some reading that will help me understand and the mapping of the resource Rxx files to the assembly in IDA? You need to be a member in order to leave a comment. Sign up for a new account in our community. It's easy! Already have an account? Sign in here. Followers 0. Recommended Posts. Shub-Nigurrath Posted July 3, Posted July 3, Hi all this time argv is releasing an interesting huge primer on reversing symbian s60 3rd edition applications. Link to comment.
Loki Posted July 3, Excellent work argv - this is a great package! Posted January 24, Very good Shub-Nigurrath Posted January 24, Posted February 1, I know expecting a detailed analysis on all the programs is impossible, but just one or two, to teach us how the loading of descriptors from resources gives us the info about the correct area of the code to study im guessing thats how argv found XXXX as the area to patch once we know which sub is the one that is called when things go bad, we can patch branches to that sub.
May 26, This report was released in partial secrecy on May 16th on the ARTeam download page. No blog article. No announcement. It was only stumbled upon by a German blogger who on condition on anonymity provided it to me after I asked nicely. All code included with this tutorial is free to use and modify; we only ask that you mention where you found it.
The report details exactly what measures developers can take and are taking to try and protect their apps from being cracked. And then it goes much further and gives detailed instructions on how the authors cracked several well-known apps:.
The examples are ordered in level of difficulty and show which week spots the crackers where able to exploit to crack the apps. You see several levels of complexity on checks on info.
The report shows that given enough time a resourceful cracker can circumvent most of the checks that developers can think of. So these are the learnings that we can draw from it:.
So far tools like Crackulous only remove the encryption and user-specific data like for example the purchase receipt.
The authors conclude in the final chapter of their work in a way that might give us small-time developers a glimmer of hope:.
However even those simple checks may need some time to bypass if the developer invests some time in making them harder to find and to analyze.
0コメント