Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

The Bad Ape 5.0.1 - Cracker's Guide Naming convention of crack ﬁles First of al

The Bad Ape 5.0.1 - Cracker's Guide Naming convention of crack ﬁles First of all a valid crack ﬁle must be named as the bundle identiﬁer (+ .plist extension ) of the application to crack. How to ﬁnd the bundle identiﬁer? If you right- click on an app and choose Show Package Content. In Contents youll ﬁnd an Info.plist ﬁle, open it with a Plist viewer (Property List Editor) and ﬁnd the key CFBundleIdentiﬁer, its value is the bundle identiﬁer, also the preference ﬁle of the app (in ~/Library/Preferences/) has that name. Structure and format of the crack ﬁles The crack ﬁle has to be a valid XML property list (use Property List Editor included with DevTools!). The root of this plist must be an Array (default is Dictionary, change it to Array) and must contains as many dictionaries as many functions you need to patch. Each dictionary can contain these keys: The next keys are used to identify the function to patch: - Function : its value must be the name of the function or of the method to patch (if is a method dont forget to put the ":" at the end of the name if it takes arguments). The function can be either a plain C/C++ function (pay attention to the underscores!), a class instance function or a class function (those with the + sign to be clear, you dont have to write that +). - Class : its value must be the class containing the above declared method. If no class is speciﬁed its assumed we are talking of a C function, not an objc method. - Offset : A dictionary containing items of class Number named either ppc or i386 (you can put either one, or both). At runtime, the Offset for the host architecture will be loaded. The offset is expressed in hex, so put 0x<offset>, the resulting conversion will be ok. This method of identifying function is strongly discouraged, use this as the very last resort. For compatibility, the old format is still supported on PPC only. The next keys are used to determine how to modify the function: - ReturnValue : It must be a number (so put Number or Boolean as class, not string). It is the value that will be returned by the function. Omitting will result in a 0 returning function. It must be set to 1 or 0 or any custom value. If you want to represent an hexadecimal put 0x preﬁx and it will convert to decimal. - ReturnObject: It can be any object serializable in a Property List, such Data, String, Date, Array, Dictionary etc. This will make it return an object so don't use it for normal numbers. Use this in case the target function doesn't return a number. - Patches: A dictionary containing arrays named "ppc" and/or "i386". You can write either one or both. At runtime, the right array of patches will be loaded. The array will contain dictionaries with the actual patches. Each dictionary will represent a patch to apply to a function (useful if the instructions to patch aren't in a contiguos area). Each dictionary contains the key Offset, a Number containing the relative function offset where the instruction to patch is located (you can get this number from the otool output, no conversion needed) and the key Changes of kind Data containing the instructions to put at the offset (your crack). This feature is very powerful, but try using ReturnValue or ReturnObject if possible as those cracks usually last longer and are natively universal. For compatibility, the old format is still supported on PPC only. If a dictionary doesnt contain ANY of these keys, but contains others, they will be treated as Program Preferences and they will be loaded as if they were in the .plist of the program itself. Some cracks needs this. Universal TAPFs: Every TAPF can be universal, working on both PPC and Intel. If you don't use Offset to identify the function and Patches to patch it, you do not have to take any additional step to make it work on both architectures. As the majority of TAPFs are done this way, the majority of TAPFs is already Intel-compatible. Using Offset and Patches requires you to port this value to both architectures if you want them to be universal (for obvious reasons PPC patch won't work on intel, and viceversa), but the TAPF format is ﬂexible enough to contain patches for both architectures in the same ﬁle. Deprecated keys for patching: - ReturnString : Deprecated, now alias for ReturnObject - CustomFunction: Deprecated. Use Patches instead. Old TAPF using this will continue working on PPCs. Modus Operandi - for who isn't a cracker (yet) With The Bad APE making your own crack is easier. Do you guys know class-dump? search about it, install it. Then class-dump the application you need to crack. You might ﬁnd some BOOL functions and one may be like "isRegistered" (Yeah, it really exists). If you ﬁnd something like that you are done: write in a plist ﬁle the Class, Function and ReturnValue (as Number, remember) . Save it and put it in the right dir (~/Library/Application Support/The APE/ is default). If you didnt understand well, i should write something more accurate but i hope someone else can do it as my english is not that good...good luck! uploads/Litterature/ tapf-making-guide.pdf