Some applications tend to perform poorly once they are protected with costly templates or transformations. However, switching to lower-cost alternatives may excessively reduce the quality of the protections. A compromise can be reached by using performance-sensitive templates on the small portions of the application that take the longest time to execute, while still using security-sensitive templates on the vast majority of the code that executes too quickly or infrequently to be a performance hazard.
There are two ways to achieve this: the first is to manually add Code Annotations to the source code, but to do so requires having a good understanding of the performance of the application. Instead, Application Profiling can be used. By using Profiling, you can run your application while Jscrambler automatically determines the best templates to apply to each function. You can still fine-tune the results to suit your purposes.
The option to use profiling is positioned to the right of the "Protect App" Button. If you don't have yet profiled your app, for example on newly created apps, a "Profile App" link will be displayed. Click on it to switch to the Application Profiling menu and start profiling your application.
Disclaimer: Protect your application and verify that performance is an issue (if it isn't, then there is no reason to profile the application).
Go into the App Builder and select the "Application Profiling" option from the dropdown menu. This will open up the Application Profiling menu.
Instrumentation is the process of adapting your application to include measurement tools that report to Jscrambler how often and for how long each function of your program runs.
Click "Instrument application" and wait for the process to finish.
WARNING: These files are not protected, so do not distribute them to anyone you would not entrust the original code with.
Once the instrumentation is finished, download the instrumented application by clicking the "Download Instrumented App" button.
Unzip the instrumented application and run it as you would normally run your application.
Don't forget to click "Start Profiling" in the Profiling menu to signal the Profiling service to start collecting statistics.
Simulate typical use cases of the application, make sure to cover the areas where the performance after obfuscation has been an issue. You can also run your automated unit tests with the instrumented code so that all program flows are tested.
As you run the instrumented application, the profiler will collect performance statistics and periodically upload it to our servers. Make sure the application has access to the internet, so the data can be sent.
During this process, a status box will appear, displaying the profiling progress in realtime.
While running, you can check the Preliminary Report to have a realtime detailed overview of the statistics we collect, more on that in the "Profile Report section".
It's common and expected that the instrumented application is slower than the original version. Do not worry: this slowdown is due to the overhead of measuring the properties of the application, and will not be present in the final protected version.
If for some reason, you believe that the collected data is not representative, you can stop and restart the profiling from the beginning at any time.
Once you consider that you have tested most of the application, you can click "Stop Current Profiling".
After issuing the "Stop Profiling" action, the service will aggregate all the collected data, processing it afterwards.
Note: The profiling service will automatically be stopped if it does not receive any profiling data for more than 30 minutes.
After stopping the current profiling, a summary of the profiling will be displayed, providing granularity over the profiling code coverage.
As you can see in the image, the profiling summary has two main components. The first one with the pie-chart can be seen as a high-level summary of the profiling service results. The second one introduces a ranking with emphasis on functions with the most impact throughout the process.
The pie-chart presents an overview on metadata collected and decisions made during profiling, for instance:
Note that functions not covered while profiling will still be protected using the general settings chosen by the user for the entire application.
Keep in mind that it is not expected for your application to reach 100% of profiled functions coverage, especially when profiling big or complex applications. Nonetheless, if you are observing a significant count on functions that were not profiled, you should try to understand what might be causing this.
A possible cause could be that when running the application profiling you didn't use all your application features and therefore some of the logic was not executed because of it, thus impacting the coverage.
An alternative explanation would be that your application is not using some of the functionalities included in first or third-party libraries. In this case - although it's not mandatory - you could consider removing the logic that your application doesn't need. To do that you can use an optimization tool that apply techniques such as Tree shaking in your application code. This will not reduce the number of remaining functions to zero but will reduce significantly the size of the resulting code.
If you want to have a more detailed view on the impact of each profiled function of your application, you can click the "See Report" button to access the Profiling Report page.
The Profiling Report page shows which templates is applied to each function based on profiling data, so you can validate and customize those decisions.
For instance, if you know that a function is security-critical, you can use the profiling report to verify that the appropriate security settings are applied to it, changing the template if necessary (note: you can also use code annotations to force certain transformations to be applied).
You can also use the Profiling Report to learn more about the performance of your applications.
Below is a description of each column in the report page.
When you are done analyzing the Profiling Report, click "Create Protection" to move on to the Protection Builder.
You are all set to protect your application using the profiling settings. To do that, go to the "Protection Builder" menu (if you are not there yet) by selecting "Protection Builder" option in the dropdown menu. Then select the "Use Profiling" option and click "Protect App".
During the protection, Jscrambler will automatically use the best template for each function.
When finished, try to run the protected version and you should see significant performance improvements over the protected version that did not use profiling data.
If you wish to, you can still obtain a protected version that does not use profiling information, by unchecking the "Use Profiling" option and protecting the application again.
The profiling settings used in each protection can be consulted in the "Protection History" page.
Not at this point, for now, any change in the source code of the application requires the instrumentation and profiling to be restarted.
Code Annotations take precedence over all profiling operations.
As long as it takes to execute all the representative use-cases of your application.
No. If you stop profiling, you will need to restart profiling from the beginning to collect any additional data. If the instrumented application is closed but the profiling wasn't stopped, then it can be reopened for additional profiling, but if it is closed for too long (so it does not send any further data), profiling will be automatically stopped after some time.
It is also not recommended to leave the application open and idle for long periods unless that is something your end-users are also likely to do, since doing so have the profiler believe that being idle is a typical use-case of the application.
Yes. To do that go to "Protection History", select the desired protection and click the link in the "Profiling Report" section. As a side note, in the "Protection History", there is a column named "Profiling" which marks if a protection was made with the "Use Profiling" option enabled, helping users to easily identify these kind of protections.
Not at this point, for now, you have to do it via the Jscrambler Web App.
Note: if you have profiled your application and you want to protect it via CLI using the profiling settings, it is possible to do so passing the use-profiling-data option when issuing the protection request. Do not specify any source files in this request, otherwise, the use-profiling option won't have any effect as the existing source files will be overwritten therefore resulting in the remotion of the existing application's profiling settings. Read more about the use-profiling-data option in the CLI documentation.
Not at this point, protecting a React Native application is currently a process only made available via CLI. Profiling an application is a feature only accessible via the Jscrambler Web App at the moment.
When the profiling service detects functions as being protection-sensitive (e.g. performance-critical) it automatically recommends specific protection settings to them.
You should be cautious in cases where a high percentage of the functions are recommended to be protected with a Light Obfuscation template, as this can reduce the level of protection on those functions. Please review each function individually to make sure that there isn't any case of a function that requires a high level of protection.
Not at this point, profiling service does not analyze code outside functions.