PreEmptive Protection for iOS - Rename, or PPiOS-Rename for short, is a tool for obfuscating Objective-C class, protocol, property, and methods names, in iOS apps. It is a fork of iOS-Class-Guard from Polidea, with extensive improvements and modifications.
PPiOS-Rename works by generating a special set of #define statements (e.g. #define createArray y09FzL7T) that automatically rename symbols during compilation. It includes a number of features:
- Analyze a Mach-O binary to identify symbols to be renamed
- Apply the renaming rules to the project source code
- Translate an obfuscated crash dump back to unobfuscated names
PPiOS-Rename works with more than just your project's code. It also automatically finds symbols to exclude from renaming by looking at all external/dependent frameworks and in Core Data (xcdatamodel) files. The renamed symbols will also be applied to your XIB/Storyboard files, and to any open-source CocoaPods libraries in your project.
PPiOS-Rename is licensed under the GNU GPL v2, but commercial support is also available from PreEmptive Solutions via a commercial support agreement. Please see LICENSE.txt for details.
DEVELOPER NOTE: This fork includes a substantial rewrite of the git history, to fix a corrupted commit in the original repo. More details are in the changelog.
PPiOS-Rename is designed to be used in two phases of your build and release process. In the first phase, PPiOS-Rename analyzes an unobfuscated compiled build of your app, to determine which symbols should be renamed and which should be excluded from renaming. In the second phase, PPiOS-Rename applies those renaming rules to the source code of your app, so that the next build made from that source will be obfuscated. These two phases can be integrated into your build and release processes in a number of ways, including back-to-back.
ppios-rename --analyze [--symbols-map symbols.map] <Mach-O binary>
In this phase, PPiOS-Rename analyzes the unobfuscated compiled build of your app to determine which symbols should be renamed. It parses all classes, properties, methods and i-vars defined in that file adding all symbols to a "rename list". Then it builds up an "excludes list" with standard reserved words, symbols from dependent frameworks, symbols in Core Data (xcdatamodel) files, and any symbols that have been explicitly excluded via command line arguments. It them combines those lists to generate a final list of symbols that will be renamed.
For each such symbol, it generates a random identifier, and writes a "map file" (symbols.map, by default) with the original names mapped to the new random names. That map file is the final output of the Analyze phase, and is a required input for the next phase, Obfuscate Sources.
Note: Usually at this point, you should archive the
symbols.mapfile. You will need it to be able to de-obfuscate any stack traces generated by builds that were obfuscated based on it.
ppios-rename --obfuscate-sources [--symbols-map symbols.map]
In this phase, PPiOS-Rename reads in the map file and generates a header file (symbols.h, by default) that has #defines for each symbol to be renamed. It then finds the appropriate Precompiled Header (.pch) files in your source code and adds a #include with the path to the header file. Finally, it finds all XIBs/Storyboards in your source tree and directly updates the names inside those files.
Now, with the source modifications in place, you can build your app as usual. It will be compiled with the obfuscated symbols. (And any open-source CocoaPods will also have their symbols obfuscated.)
Note: The Obfuscate Sources phase modifies the source code of your app, but you should not check in the changes it makes. If you do so, it will cause errors the next time you need to perform the Analyze phase, and will cause issues with Storyboards in the IDE. We recommend only using the Obfuscate Sources phase in your release (or automated) build process, and you should always clean/reset your source tree after the build, before doing any further development.
PPiOS-Rename supports apps developed for:
- iOS 10, iOS 11, iOS 12
- iPhone, iPod touch, and iPad
- ARM 32-bit, ARM 64-bit, and x86 Simulator
Using:
- Xcode 9, Xcode 10
- Objective-C
Note: Swift is not supported by PPiOS-Rename. PPiOS-Rename does not work on projects with any Swift code.
We suggest downloading one of the binary releases from the Releases page. The archive contains a standalone binary that you can copy to an appropriate place on your system, e.g. /usr/local/bin. We suggest ensuring that the location is on your PATH. The release archive also includes other files such as this README, a changelog, and our license.
The basic process is:
- Ensure all local source code changes have been committed
- Build the program
- Analyze the program
- Apply renaming to the sources
- Build the program again
For your first time using PPiOS-Rename, the following command (adjusted for your project) will perform the Analyze step:
ppios-rename --analyze /path/to/program.app/program
The analyze process generates symbols.map, the file containing a symbol mapping that can be used to decode stack traces in the event of a crash. The symbols file created during a build that is released should always be archived for subsequent use.
Then the Apply Renaming step can be accomplished with the following:
ppios-rename --obfuscate-sources
Note: The Obfuscate Sources phase (invoked in the Apply Renaming step) modifies the source code of your app, but you should not check in the changes it makes. If you do so, it will cause errors the next time you need to perform the Analyze phase, and will cause issues with Storyboards in the IDE. We recommend only using the Obfuscate Sources phase in your release (or automated) build process, and you should always clean/reset your source tree after the build, before doing any further development.
Once you are comfortable using PPiOS-Rename, it can be easier to use if you integrate it into your Xcode project as part of the build process. This can be set up with the following process:
-
Open the project in Xcode.
-
Go to the Project Navigator, and select the project.
-
Select the icon to open the "Show project and targets list" (near the upper left corner of the main pane).
-
Select the target to obfuscate, right-click, and select Duplicate (Command-D).
Note: Signing details for the target may need to be set in order for the build to complete successfully. These can be configured on the General tab.
Note: If applying these changes to a framework project, you may need to use underscores instead of spaces in the new target names.
-
(Optional) Duplicating the target duplicates the associated
.plistfile with a default name. Rename the.plistfile:- Select Build Settings, select All settings, select Combined view, and search for
plist. - Update the value for
Info.plist Fileto be consistent with that of the original target (something like<project-name>/Build and Analyze <original-target-name>-Info.plist). - Move/rename the duplicated
.plistfile to the new name and path (e.g. using Finder). - Delete the now stale reference to the default
.plistfile from the Project Navigator.
- Select Build Settings, select All settings, select Combined view, and search for
-
Select Build Phases.
-
Add a script phase by selecting the
+(just above Target Dependencies), and then selecting New Run Script Phase (it should run as the last phase, and will by default). -
Rename the phase from
Run ScripttoAnalyze Binary. -
Expand the phase, and replace the shell script comment that says
# Type a script or ..., pasting the following script (adjusting for the correct path):PATH="$PATH:$HOME/Downloads/PPiOS-Rename-v1.3.0" [[ "$SDKROOT" == *iPhoneSimulator*.sdk* ]] && sdk="$SDKROOT" test -z "$sdk" && sdk="$CORRESPONDING_SIMULATOR_SDK_DIR" test -z "$sdk" && sdk="$CORRESPONDING_SIMULATOR_PLATFORM_DIR/Developer/SDKs/iPhoneSimulator${SDK_VERSION}.sdk" ppios-rename --analyze --sdk-root "$sdk" "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH" -
From the menu, select Product | Scheme | Manage Schemes.
-
If Autocreate Schemes is enabled, a new scheme for the duplicated target will have already been created. Rename it to
Build and Analyze <original-scheme-name>, and close the dialog. Otherwise, create a new scheme for the Build and Analyze target. -
Duplicate the original target again, and rename it to
Apply Renaming to <original-target-name>. Again, optionally renaming theInfo.plistfile as described in step 6.
Notes: Signing details for the target may need to be set in order for the build to complete successfully. These can be configured on the General tab.
If applying these changes to a framework project, you may need to use underscores instead of spaces in the new target names.
-
Delete all of the build phases in this target.
-
If there are any target dependencies, delete them as well.
-
Add a script phase, and rename it to
Apply Renaming to Sources(this should be the only real action for this target). -
Paste the following script (adjusting for the correct path):
PATH="$PATH:$HOME/Downloads/PPiOS-Rename-v1.3.0" ppios-rename --obfuscate-sources -
Edit the scheme (or add one) for this new target, renaming the scheme to
Apply Renaming to <original-scheme-name>. -
These changes should be committed to source control at this point, since building the target to Apply Renaming will change the sources in ways that shouldn't generally be committed.
When ready to start testing an obfuscated build:
-
Ensure all local source code changes have been committed.
-
Build using the Build and Analyze scheme, producing the symbols file,
symbols.map. -
Commit or otherwise preserve the
symbols.mapfile. -
Build using the Apply Renaming scheme, which applies the renaming to the sources.
-
Build using the original scheme.
-
Revert changes to the sources before continuing development.
Once renaming has been applied to the sources, the process of building and testing for different destinations can be repeated using the original scheme (step #5), as long as you haven't reverted the sources yet (step #6).
If you modify the original build target or scheme, be sure to delete and recreate the Build and Analyze target as above. Under certain conditions, the Apply Renaming target and scheme will need to be recreated as well.
During the Obfuscate Sources phase, you may get an error:
Error: could not find any *-Prefix.pch files under .
This is because PPiOS-Rename is attempting to add an #include to a Precompiled Header file, and it can't find a suitable file to add it to. This is typically because projects created in Xcode 6 and above don't contain a .pch file by default.
To fix this, add a .pch file as follows:
-
In Xcode go to File -> New -> File -> iOS -> Other -> PCH File.
-
Name the file e.g.
MyProject-Prefix.pch. PPiOS-Rename looks for a file matching*-Prefix.pch. -
At the target's Build Settings, in Apple LLVM - Language section, set Prefix Header to your PCH file name.
-
At the target's Build Settings, in Apple LLVM - Language section, set Precompile Prefix Header to YES.
Error: Fat file does not contain a valid Mach-O binary for the specified architecture (...). If you are trying to obfuscate a static library, please review the 'Obfuscating Static Libraries' section of the documentation.
You have tried to run analysis on a static library or framework.
If you are trying to analyze a static library, please follow the instructions in the Obfuscating Static Libraries section below.
If you are trying to analyze a framework, sometimes it will work if you --analyze the AppName.framework directory created by Xcode when archiving. Try archiving the framework from Xcode and use the AppName.framework folder created inside the project's derived data folder (~Library/Developer/Xcode/DerivedData/ProjectName-.../...).
During the build, after the Obfuscate Source phase, you may see errors like this:
Undefined symbols for architecture i386:
"_OBJC_CLASS_$_n9z", referenced from:
objc-class-ref in GRAppDelegate.o
You might also see unresolved external linker errors, e.g. if you used a C function and named an Objective-C method using the same name.
These errors usually mean that PPiOS-Rename obfuscated a symbol that needs to be excluded for some reason. You can find the symbol by searching symbols.map or symbols.h for the referenced symbol (n9z, in this example) to see what the original name was. Then you can exclude the symbol via command line arguments to the Analyze phase, via -F or -x, described below.
In this example, if n9z had mapped to PSSomeClass, you would add -F '!PSSomeClass' to your arguments when running --analyze.
The -F option defines a filter against which class, protocol, and category names will be matched. The argument to -F is a glob pattern supporting * (any number of any character) and ? (any single character). If the first character of the pattern is a ! then the filter will exclude any matching classes, protocols, and categories. If the first character is not a !, then the filter will include any matching classes, protocols, and categories.
The default filter is equivalent to -F '*' and the system behaves as if it is always the first filter specified. Additional filters can be specified on the command line, and each one overrides the rules from the ones that came before. For example:
-F '!A?H*' -F 'ATH*'
This will filter out all classes, protocols, and categories that start with an "A", have any next character, then have an "H", except for classes, protocols, and categories that specifically start with "ATH". All other classes will be "filtered in" by the default rule.
Filter patterns are case sensitive, so -F ABC will match differently than -F abc. There is basic support for character classes, so you can match either with e.g. -F '[Aa][Bb][Cc]'.
When excluding items via -F, if the excluded item matches a class, protocol, or category name, then additional exclusions may be applied based on that name.
For example, if a class name is excluded, then the following will also be excluded (assuming "ClassName" is the class name):
- ClassNameProtocol
- ClassNameDelegate
- All of the methods and properties defined within the class
Also see the section below about property name exclusions.
You can exclude specific symbols by using the -x argument in the Analyze phase. For example:
-x 'deflate' -x 'curl_*'
This will exclude symbols named deflate and symbols that start with curl_.
? matches any single character, while * matches any number of characters.
Note: Symbols excluded with
-xwill be excluded regardless of positive-Ffilters (-x"wins"). However,-xexclusions do not propagate like-Finclusions/exclusions do. For example, specifying-F '!*' -F MyClass -x MyClasswill not rename theMyClassclass itself, but will rename the properties and methods contained therein.
When excluding properties (either via -x or via propagation from -F), the following names are also excluded (assuming the propery name is propertyName):
- _propertyName
- setPropertyName
- isPropertyName
- _isPropertyName
- setIsPropertyName
Ensure you have excluded all the classes, properties, etc specified in the distributed header files as users of the framework may encounter linking and/or runtime issues if some were renamed.
Undefined symbols for architecture ...: "OBJC_CLASS$_SomeClass", referenced from: objc-class-ref in ObjectFile.o
This linking issue occurred because SomeClass was not excluded when analyzing the framework. Add -F '!ClassName' to the command line when analyzing. You will then need to obfuscate, build, and redistribute the framework.
'NSInvalidArgumentException', reason: '-[_ClassName setPropertyName:]: unrecognized selector sent to instance 0x145a7c90'
This end user application runtime failure occurred because PropertyName was not excluded when analyzing the framework. Add -x PropertyName to the the command line when analyzing. You will then need to obfuscate, build, and redistribute the framework.
If you're using external libraries which provide Interface Builder files, be sure to ignore those symbols as they won't work when you launch the app and try to use them. You can do that using the -F option to the Analyze phase.
It is possible that during obfuscation KVO will stop working. Most developers use hardcoded strings to specify KeyPath.
- (void)registerObserver {
[self.otherObject addObserver:self
forKeyPath:@"isFinished"
options:NSKeyValueObservingOptionNew
context:nil];
}
- (void)unregisterObserver {
[otherObject removeObserver:self
forKeyPath:@"isFinished"
context:nil];
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
{
if ([keyPath isEqualToString:@"isFinished"]) {
// ...
}
}This will not work. The property isFinished will get a new name and the hardcoded string will not reflect the change.
Remove any keyPath and change it to NSStringFromSelector(@selector(keyPath)).
The fixed code should look like this:
- (void)registerObserver {
[self.otherObject addObserver:self
forKeyPath:NSStringFromSelector(@selector(isFinished))
options:NSKeyValueObservingOptionNew
context:nil];
}
- (void)unregisterObserver {
[otherObject removeObserver:self
forKeyPath:NSStringFromSelector(@selector(isFinished))
context:nil];
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
{
if ([keyPath isEqualToString:NSStringFromSelector(@selector(isFinished))]) {
// ...
}
}If you use serialization (e.g. NSCoding or NSUserDefaults), affected classes will have to be excluded from obfuscation. If you don't, then you won't be able to generate new symbols (i.e. the Analyze phase) without breaking deserialization of existing data.
This error happens when --obfuscate-sources is used on the same source tree twice. This can result in your application not being obfuscated. Make sure that the source tree is always reset to an unmodified state before using --obfuscate-sources.
This error happens when --analyze is used on an already obfuscated binary. This can result in your application not being obfuscated. Make sure that your program is always rebuilt from clean and non-obfuscated source code before attempting to run the analysis process.
When looking to verify obfuscation, you must first locate the obfuscated binary.
If you created an archive, Xcode would have placed it in the archives directory, ~/Library/Developer/Xcode/Archives/{Date}/{AppName} {Date}, {Time}.xcarchive. Inside there, you should find:
- Binary:
Products/Applications/{AppName}.app/{AppName}
If you have an {AppName}.ipa file, you will need to extract it by running unzip {AppName}.ipa. Inside the Payload directory, you should find:
- Binary:
{AppName}.app/{AppName}
If you build from the command line (e.g. xcodebuild), this will typically create a build directory. Inside the build directory, you should find:
- Binary:
Release-[iphoneos|iphonesimulator]/{AppName}.app/{AppName}
To verify that your app has been obfuscated, use the nm utility, which is included in the Xcode Developer Tools. Run:
nm path/to/your/binary | less
This will show the symbols from your app. If you do this with an unobfuscated build, you will see the original symbols. If you do this with an obfuscated build, you will see obfuscated symbols.
Note:
nmwill not work properly after stripping symbols from your binary. You can use theotoolutility if you need to check for the Objective-C symbols after stripping.
otool will show unneeded information, but it can be filtered using grep and awk to only show symbols:
otool -o /path/to/your/binary | grep 'name 0x' | awk '{print $3}' | sort | uniq
Note: The
X__PPIOS_DOUBLE_OBFUSCATION_GUARD__symbol is used to help ensure renaming is applied properly.
PPiOS-Rename lets you reverse the process of obfuscation for crash dump files. This is important so you can find the original classes and methods involved in a crash. It does this by using the information from a map file (e.g. symbols.map) to modify the crash dump text, replacing the obfuscated symbols with the original names. For example:
ppios-rename --translate-crashdump --symbols-map path/to/symbols_x.y.z.map path/to/crashdump path/to/output
Analyzing a dynamic framework is similar to analyzing an application, but will probably require many more filters. To start, use:
ppios-rename --analyze /path/to/ProjectName.framework/ProjectName
Instead of seeing Processing external symbols from ProjectName..., which you will see for other frameworks, you should see Processing internal symbols from ProjectName...
If the --analyze is not properly finding your framework, then add the --framework argument:
ppios-rename --analyze --framework ProjectName /path/to/framework/executable
You then need to determine and use the proper filters. You will need to choose one of two ways depending on how many public APIs you include in your framework:
- Exclude everything which is mentioned in the
.hfiles you distribute with the framework. - Start with a
-F '!*'(exclude everything) and then include things not mentioned in those headers.
Once you have run ppios-rename --analyze with the proper filters, continue with the standard ppios-rename --obfuscate-sources step and follow the rest of the instructions.
Static libraries cannot be directly processed by PPiOS-Rename, but it is possible to work around the technical issue preventing direct processing. Although the initial setup is somewhat involved, once this is complete the build process is no more complicated than with other PPiOS-Rename projects. The basic idea is:
- Create a workspace to simplify interactions with the library.
- Create an app that uses the static library.
- Use the app for the analysis portion of PPiOS-Rename.
- Use the analysis to apply renaming to the static library's sources.
- Build the static library.
Importing the static library into the wrapping app pulls all of these classes and all of the classes that they reference into the app. Using this as the basis for analysis would rename all of the symbols in the static library. The resulting library would be unusable because all of the identifiers in the API would be renamed. In order for the static library to be usable externally, all of the public symbols need to be excluded from renaming. Excluding these classes must be done manually. ppios-rename will exclude all of the members of these classes, automatically, once the classes are excluded.
The procedure is as follows:
-
If your static library project (referred to here as
StaticLib) does not already have a containing workspace, create one:- In Xcode, go to
File>New>Workspace .... - Choose an appropriate name for the workspace (referred to here as
LibWorkspace), and save it in the directory containing theStaticLibproject directory. See the source tree layout shown below. - Go to
File>Add Files to "LibWorkspace".... - Add the project file
StaticLib/StaticLib.xcodeproj.
- In Xcode, go to
-
From within the workspace, create a new project:
-
In Xcode, go to
File>New>Project .... -
Select
iOS, then under theApplicationsection selectSingle View App, and then selectNext. -
For the options: specify the
Product NameasWrappingAppand be sure to select Objective-C as the language, then selectNext. -
Create the project:
-
Specify the directory to store the
WrappingAppproject as a sibling of the static library's project directory. These instructions expect a source tree layout like the following, with everything undersomeParentDirunder source control:someParentDir/StaticLib/StaticLib.xcodeproj someParentDir/LibWorkspace.xcworkspace someParentDir/WrappingApp/WrappingApp.xcodeproj -
At the bottom of the dialog, specify
Add to:theLibWorkspaceworkspace. -
Select
Create.
-
-
Select the WrappingApp target, then
Product>Buildto verify that the project builds. -
Go to the Project Navigator, select the
WrappingAppproject, and select theWrappingApptarget. -
Select
General, scroll to the bottom, and select the+to add to the list ofLinked Frameworks and Libraries. -
Add
libStaticLib.a. -
Select
Build Settings, search forother linker, and setOther Linker Flagsto include-ObjC. -
Select
Product>Clean Build Folderand build again to verify that the workspace builds correctly. It should build the static library first and then the app.
-
-
Setup PPiOS-Rename to analyze the app:
- Follow instructions 5-12 in
Project Setupabove, but apply them toWrappingApp, rather than the static library, and modify the originalWrappingApptarget. Duplication of the target is unnecessary. - Clean and build the
Build and Analyze WrappingApptarget. - Review the build log in the report navigator and look for the number of
Generated unique symbols. This number should include all of the public and all of the non-public symbols fromStaticLib. This will also include a small number of symbols from classes in the app itself. Symbols from the app should be benign, but can be excluded manually if necessary. - Create a list of public types for the static library named
public-types.list. Either create the list using the following procedure, or create the list manually. The procedure requires that the names of the public header files match the names of the types, or follow theAffectedType+CategoryName.hconvention.-
Go to the Report Navigator, review the log for a build of
StaticLib, select a copy file task for one of the header files, right-click andCopy. -
Paste the result in a text editor.
-
Select and copy the build output path. This should have the form:
<products-directory>/include/StaticLib, and contain the string/DerivedData/. -
At a command line, run the following commands, from
someParentDir:# Replace ".../include/StaticLib" with the build output path # Replace "StaticLib" with the name of the umbrella header ls ".../include/StaticLib" | sed 's/.*+//' | sed 's/[.]h$//' | grep -v StaticLib > public-types.list # Or omit the grep -v part if you have no umbrella header ls ".../include/StaticLib" | sed 's/.*+//' | sed 's/[.]h$//' > public-types.list # verify the contents less public-types.list # SLAPublicClass # SLProtocolForSomething # SLSomeCategory # ...
-
Note: This is an additional point of maintenance: as types are added to or removed from the public API of the library, the
public-types.listwill need to be updated accordingly.-
Replace the analyze script (
Analyze Binaryrun script phase) with the following to exclude the public types from renaming:PATH="$PATH:$HOME/Downloads/PPiOS-Rename-v1.3.0" [[ "$SDKROOT" == *iPhoneSimulator*.sdk* ]] && sdk="$SDKROOT" test -z "$sdk" && sdk="$CORRESPONDING_SIMULATOR_SDK_DIR" test -z "$sdk" && sdk="$CORRESPONDING_SIMULATOR_PLATFORM_DIR/Developer/SDKs/iPhoneSimulator${SDK_VERSION}.sdk" ppios-rename --analyze --sdk-root "$sdk" \ $(for each in $(cat ../public-types.list) ; do printf -- '-F !%s ' "$each" ; done) \ "$BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH" -
Repeat steps 3.ii - 3.iii. The number of unique symbols should decrease, but still be significant. This should be the count of all of the non-public symbols (non-public symbols for which there are not public symbols with the same name).
-
Review the list of types that will be renamed by executing the following at a command line, from
someParentDir(assumes all of the type names are prefixed with the two lettersSL):cat WrappingApp/symbols.map | awk '{print $3}' | sed 's/[",]//g' | grep '^SL' > renamed-types.txt less renamed-types.txt -
Adjust
public-types.listas necessary to ensure that all public types are not renamed.
- Follow instructions 5-12 in
-
Modify the static library project to apply the renaming:
-
Follow instructions 13-16 in
Project Setupabove, applying them to theStaticLibtarget (duplicating the target this time). -
The call to
ppios-renameneeds to reference thesymbols.mapfile from the WrappingApp project, using the--symbols-mapoption. Use this script for the new Run Script phase (adjusting the path as necessary):PATH="$PATH:$HOME/Downloads/PPiOS-Rename-v1.3.0" ppios-rename --obfuscate-sources --symbols-map ../WrappingApp/symbols.map -
Follow instruction 18 in
Project Setupabove.
-
-
All of these changes (to the static library, WrappingApp, and
public-types.list) should be committed to source control at this point, since building the target to Apply Renaming will change the sources in ways that shouldn't generally be committed.
The process to build the static library with renaming becomes:
- Ensure that build environment is clean (e.g. all stale symbols files have been removed, and modifications to .xib files have been reverted).
- Clean and build the
Build and Analyze WrappingApptarget, which should also clean and build the static library. - Build the
Apply Renaming to StaticLibtarget. - Clean and build the the
StaticLibtarget.
ppios-rename --analyze [options] <mach-o-file>
Analyze a Mach-O binary and generate a symbol map
Options:
--symbols-map <symbols.map> Path to symbol map file
-F '[!]<pattern>' Filter classes/protocols/categories
-x '<pattern>' Exclude arbitrary symbols
--arch <arch> Specify architecture from universal binary
--sdk-root <path> Specify full SDK root path
--sdk-ios <version> Specify iOS SDK by version
--framework <name> Override the detected framework name
ppios-rename --obfuscate-sources [options]
Alter source code (relative to current working directory), renaming based on the symbol map
Options:
--symbols-map <symbols.map> Path to symbol map file
--storyboards <path> Alternate path for XIBs and storyboards
--symbols-header <symbols.h> Path to obfuscated symbol header file
ppios-rename --translate-crashdump [options] <input crash dump file> <output crash dump file>
Translate symbolicated crash dump
Options:
--symbols-map <symbols.map> Path to symbol map file
ppios-rename --list-arches <mach-o-file>
List architectures available in a fat binary
ppios-rename --version
Print out version information
ppios-rename --help
Print out usage information
Copyright 2016-2018 PreEmptive Solutions, LLC