Can your Application Analytics APIs do this?

October 2nd, 2015 by Sebastian Holst

Writing data to disk is easy – developing a database is not.

Posting data to a URL is easy – developing an application analytics ingestion pipeline is not.

If you’ve written even a single line of code (in any language), I probably don’t have to explain why writing data to disk is easy – but developing a database is not (for those that have never written any code – it’s the extra database “machinery” required to handle scale, concurrency, resilience, security, etc. that demands a horde of PhD’s and rock-star developers).

…and so it is with application analytics…

Posting data to a URL is easy – developing an application analytics ingestion pipeline is not.

Unlike the well-understood database scenario described above (which, ironically, includes analytics repositories - really little more than a specialized database use case), I still find development organizations that don’t have the same respect for application analytics instrumentation and ingestion stacks.

…just yesterday I was speaking with a senior developer from a large, extremely successful ISV (who shall remain anonymous); he confessed that their homegrown application analytics solution (built off of an analytics ISV acquisition of theirs) was generating WAY too much data, wreaking havoc on their infrastructure, alarming their clients, and yielding very few actionable insights.

Coincidentally, while I was hobnobbing away at this conference, our development team released updates to our Linux and Win32 (C++, etc) application analytics APIs – reminding me once again how deep you need to go if you want to have commercial grade application analytics.

As with database development – unless it is actually your core business – you should not get into the business of developing this kind of “machinery.” Here’s a sampling of new features included in these latest API releases – with references to the existing “machinery” already in place:

1. New app analytics API capability: Cached message envelopes are automatically deleted if they are deemed “too old” – the aging threshold is configurable by development at build or runtime.

Does your API

  • Provide automatic offline caching?

If yes…

  • How is the size of that cache managed and how will it behave should the cache hit capacity?
  • Can your application “prune” a growing cache based upon the aging of its data to avoid the cache growing too large because of prolonged isolation?
    • 2. New app analytics API capability: Application analytics message envelopes are split if/when they exceed a configurable size.

      Does your API

      • Bundle telemetry packets into larger envelopes and queue them for asynchronous transmission away from your production app?

      If yes…

      • Can the frequency of transmission be optimized to minimize bandwidth requirements (important for mobile connections)?
      • Can the timing of transmission to optimized to minimize network and CPU contention (important for real time systems like simulators, games, transaction processing, etc.)
      • Can developers further control the size of envelopes – and specifically the size of custom data payloads)?
      • …can your API accommodate custom payloads at all?

      3. New app analytics API capability: Development can set user-defined HTTP headers to better support more intelligent routing and distribution of incoming telemetry PRIOR to unpacking the larger envelopes.

      Does your application analytics ingestion pipeline

      • Support dynamic routing of incoming production telemetry without having to re-instrument or redeploy your application?

      If yes…

      • Under what conditions can you re-direct incoming to new analytics endpoints?
      • Can incoming telemetry be distributed to multiple analytics endpoints in parallel?

      These “deep” capabilities are required to safely and effectively scale application analytics implementations inside applications that may run on-premises and/or in 3rd party environments and/or be isolated from networks and/or subject to regulatory or compliance obligations, etc.

      And I have not even scratched the surface on this topic – does your API:

      • Enforce opt-in policies? - dynamically?
      • Consistently capture data across devices, OS’s, and application tiers?
      • Capture runtime stack, application session, all manner of exception, feature and workflow, and custom data dimensions?
      • Integrate into your SDLC and DevOps tooling and processes?

      The bottom line – no matter how awesome your developers are – and even if they can literally build anything – nobody can do everything; respect the stack.

      Want more information on PreEmptive Analytics APIs (for Linux, Win32, iOS, Android, Windows Phone, WinRT, Java, and/or JavaScript)?


Xamarin Applications and Dotfuscator

August 14th, 2015 by Michael Letterle

We are often asked if Dotfuscator supports protecting Xamarin applications. Given that Xamarin applications are based on Mono, a .NET compatible runtime, the answer is yes! However, applying obfuscation transformations to Mono assemblies is only one half of an effective obfuscation solution; the other half is making sure that the configuration and automation of the obfuscation process itself is straightforward and stable. We’ve been working hard to make Dotfuscator more Mono friendly lately, specifically with an eye towards improving Xamarin compatibility.

There are many different methods you could use to get your Xamarin assemblies processed by Dotfuscator and then packaged for deployment to devices. The steps outlined below should be the easiest to implement, while giving you a reasonable expectation of protection. Note that the below instructions are specifically for Android and iOS projects. For Windows Phone projects, we recommend building the store-ready XAP first and then running it through Dotfuscator as normal.

Obfuscating Xamarin Applications

The most consistent and secure method of obfuscating your Xamarin apps is to integrate Dotfuscator into the MSBuild pipeline. This allows you to obfuscate your project using standard build tools, and lets you test your obfuscation using Xamarin’s built-in debugger workflow. In order for the obfuscated outputs to be processed properly by Xamarin, Dotfuscator’s "Mono Compatible" global setting should be set to "Yes" and a project property of "controlflow.disabled_manglers" with a value of "ILSpyBreaker" should be added.

Xamarin’s platform specific utilities use reflection heavily, so as a starting point it is recommended to simply exclude the input assemblies from renaming (while still allowing control-flow obfuscation). Once that is working, you can then enable renaming if desired, and take the time to determine the minimum amount of exclusions needed for your application.

In each Android or iOS csproj file you should then add a reference to the Dotfuscate task and a target for AfterBuild, like so:

<UsingTask TaskName="PreEmptive.Tasks.Dotfuscate" AssemblyFile="$(MSBuildExtensionsPath)\PreEmptive\Dotfuscator\4\PreEmptive.Dotfuscator.Tasks.dll" />


<Target Name="AfterBuild">
    <Dotfuscate ConfigPath="Obfuscate.Android.xml" Properties="$(DotfuscatorProperties)"/>

Notice that we are passing in certain properties from the build process to the Dotfuscator process. Specifically OutDir and OutPath. By using project properties with default values we can specify paths in the Dotfuscator project file to allow us to configure the project using the stand-alone Dotfuscator UI, while having the build process handle where they actually are at build time.

Screenshot of project-properties

In order for the Xamarin platform specific build process to properly find the obfuscated assemblies, they have to be copied back into the original assembly locations after obfuscation. Android has an additional restriction in that the original obfuscated PCL must be copied back to its project specific location as well. The easiest way to accomplish this is to have a post-build event in the Dotfuscator project to do the copying:

Screenshot of post-build event

Adding a "ObRelease" and/or "ObDebug" configuration can be useful to only obfuscate when explicitly needed and wanted. This can be accomplished by adding a Condition property to the Dotfuscate element in the csproj (for instance: Condition=" '$(Configuration)' == 'ObRelease' "). Note that when adding a new "Release" config for Android, one needs to disable "Use Shared Runtime" and "Enable developer instrumentation" in the Android Options under the Packaging tab.

Once these steps are complete, you should be able to see Dotfuscator’s build output during your builds in either Visual Studio or Xamarin Studio:

Screenshot of VS build output

Screenshot of Xamarin build output

This will produce output packages containing obfuscated assemblies ready for deployement and testing!

Example Dotfuscator File

This is a fully configured Dotfuscator file for an Android project as described in this post. Note especially the use of properties as well as the post-build event.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE dotfuscator SYSTEM "">
<dotfuscator version="2.3">
    <property name="controlflow.disabled_manglers" value="ILSpyBreaker" />
    <property name="OutDir" value="C:\Users\ObfuscationUser\Documents\Visual Studio 2015\Projects\ObXFormsP\ObXFormsP\ObXFormsP.Droid\bin\Release" />
    <property name="OutputPath" value="\bin\Release" />
    <loadpaths />
      <inputassembly refid="52f75f71-2d9e-4e8a-911b-a24e252f60c6">
        <file dir="${OutDir}" name="ObXFormsP.dll" />
      <inputassembly refid="840c659d-7536-4ad6-9040-2f9c520a8968">
        <file dir="${OutDir}" name="ObXFormsP.Droid.dll" />
    <file dir="${configdir}\Dotfuscated" />
        <file dir="${OutDir}" name="ObXFormsP.Droid.dll" />
      <type name="ObXFormsP.App" />
      <mapoutput overwrite="false">
        <file dir="${configdir}\Dotfuscated" name="Map.xml" />
      <referencerule rulekey="{6655B10A-FD58-462d-8D4F-5B1316DFF0FF}" />
      <referencerule rulekey="{7D9C8B02-2383-420f-8740-A9760394C2C1}" />
      <referencerule rulekey="{229FD6F8-5BCC-427b-8F72-A7A413ECDF1A}" />
      <referencerule rulekey="{2B7E7C8C-A39A-4db8-9DFC-6AFD38509061}" />
      <referencerule rulekey="{494EA3BA-B947-44B5-BEE8-A11CC85AAF9B}" />
      <referencerule rulekey="{89769974-93E9-4e71-8D92-BE70E855ACFC}" />
      <referencerule rulekey="{4D81E604-A545-4631-8B6D-C3735F793F80}" />
  <controlflow level="high" />
    <event type="postbuild">
        <file dir="c:\windows\system32" name="cmd.exe" />
        <environment commandline="/c copy /y &quot;${configdir}\Dotfuscated\*.dll&quot; &quot;${OutDir}&quot; &amp; copy /y &quot;${configdir}\Dotfuscated\ObxFormsP.dll&quot; &quot;${configdir}\..\ObXFormsP\${OutputPath}&quot;" workingdir="" />
  <sos mergeruntime="true">
    <smartobfuscationreport verbosity="all" overwrite="false" />

Available Exclusively to Visual Studio 2015 Users

August 13th, 2015 by Sebastian Holst

Live technical support from PreEmptive’s (world class) product support team plus an application protection white paper

The fine print… Visual Studio 2015 users who register Dotfuscator CE (it’s inside Visual Studio 2015 already) will receive immediate access to the recent white paper, Application Protection. Why bother? AND receive a credit to open one (1) support ticket with PreEmptive’s product support team any time in (you guessed it) 2015.

So, you think you just might want to protect your applications against reverse engineering and tampering sometime in the not too distance future? Perhaps inject feature monitoring? Register your copy of Dotfuscator CE NOW to

a) “bank” a credit to open a support ticket at no cost to you and

b) to download a white paper that just might give you the insight you need to answer that question about whether or not your app needs protection (and no - the answer is not always yes).

What’s the catch?
Other than the requirement that you register with your company’s domain email – and that the support credit be used before the end of 2015 – there are no catches.

How do you register? Open up Visual Studio 2015 (any version other than Express) and open Dotfuscator from the tools menu. Once you’re in Dotfuscator CE, simply click on the “Register now” link on the first screen (as illustrated below).

Fill out the form (be sure to use a valid business email address) and you’ll be sent a link and your 1 support ticket credit will be secured.

Who would use Dotfuscator CE to obfuscate their applications? We don’t know! (Unless you register - but we still don’t know what you’re doing) We do collect some anonymous usage information assuming you first opt-in (that’s distinct from the product registration) – but even then, we collect no PII (your registration on our website does NOT change this). For some early insight into how Dotfuscator CE is being used in VS 2015, check my earlier post Visual Studio 2015 Dotfuscator CE Adoption: the first 500 users.

Are these users doing anything serious with Dotfuscator CE? We can’t be sure, but what I CAN tell you is that among the first 1,000 unique users of Dotfuscator CE 2015, users were obfuscating applications with as many as 44 unique assemblies and 3,145 classes – and these Dotfuscator CE 2015 users’ applications were targeting .NET Assembly Runtime Versions 1.1, 2.0, 3.0, 3.5, 4.0, and (of course) 4.5.

What are you waiting for?
Register Dotfsucator CE 2015– we haven’t really decided when we’ll discontinue this offer of free support (seriously) so don’t wait until its too late.

Visual Studio 2015 Dotfuscator CE Adoption: The first 500 users

August 10th, 2015 by Sebastian Holst

For the first time since its launch in 2003, Dotfuscator Community Edition (CE), the no cost obfuscator included with Visual Studio, can send anonymous usage data for analysis (only after opt-in of course). …and after one week and 500 users, the resulting application analytics is already proving its worth.

Before I share some of the insights, let me also point out that the instrumentation now inside Dotfuscator CE is the very same as what Dotfuscator CE has been able to inject into .NET apps for Visual Studio users since VS2010. In other words, you can use Dotfuscator CE to achieve these same kinds of results inside your own applications.

Opt-in: of course we collect no information without a user’s informed consent. Happily, 93% of all of our users opted-in (thank you Dotfuscator CE users!). Note, Dotfuscator can inject opt-in policy enforcement too.

Visual Studio SKUs: One important data point we were keen to know was the distribution of our users across the new Visual Studio 2015 SKU’s (Enterprise, Professional and Community Edition). One important historical note: Dotfuscator CE was never included in Visual Studio Express – only the paid SKU’s. For the first time, Dotfuscator CE is now available inside the new (free) Visual Studio CE SKU – and over half of our initial users are coming from this new community. Does this suggest that our total Dotfuscator CE community will double as Visual Studio users migrate to VS 2015? We sure hope so! …and how does this tie back to user registrations? You can bet that we will be tracking this closely.

.NET Runtimes: We can infer quite a bit about the kinds of development our users are focused on by the .NET runtimes their apps target (not the .NET runtime installed with VS2015 which his 4.5 of course). While everyone is excited by the promise of modern development and universal apps, many development organizations’ current projects are still grounded in earlier .NET generations. Clearly, our application protection and analytics will need to support these runtimes for some time to come.

Equipment Manufacturers: In much the same vein, when looking at the underlying devices of these early VS2015 users, we see that they are mostly running on-prem (note, we are looking exclusively at VS2015 Dotfuscator CE users). While everyone is excited about Windows 10 and embracing Azure; early use is still mostly on-prem and, it is for this exact scenario, that our application protection and analytics support on-prem dev environments (and app deployments).

Follow links for:
A comparison of Dotfuscator CE and our other Dotfuscator versions
General information on PreEmptive Analytics

Stay tuned for more Visual Studio 2015 insights via Dotfuscator CE.

6 Signs That You May be Overdue for a Mobile Application Risk Review

June 24th, 2015 by Sebastian Holst

Every organization must ultimately make their own assessment as to the level of risk they are willing to tolerate – and mobile application risk is no exception to this rule.

Yet, given the rapidly changing mobile landscape (inside and outside of every enterprise), organizations need to plan on regular assessments of their mobile risk management policies – especially as their mobile applications grow in importance and complexity.

Here are 6 indicators that you may be overdue for a mobile application risk assessment.

  1. Earlier PC/on-premises equivalents ARE hardened and/or monitored. Perhaps these risks need to be managed on mobile devices too – or, conversely, the risks no longer need to be managed at all.
  2. Enterprise mobile apps are distributed through public app marketplaces like Google Play or iTunes. Using public marketplaces exposes apps to potentially hostile users and can be used as a platform to distribute counterfeit versions of those very same apps.
  3. Mobile apps are run within a BYOD infrastructure alongside apps and services outside of corporate control. Access to a device via third-party software can lead to a variety of malicious scenarios that include other apps (yours) installed on the same device.
  4. Mobile apps embed (or directly access) proprietary business logic. Reverse engineering is a straight forward exploit. Protect against IP theft while clearly signaling an expectation of ownership and control – which is often important during a penalty phase of a criminal and/or civil trial.
  5. Mobile apps access (or have access to) personally identifiable information (or other data governed by regulatory or compliance mandates). Understanding how services are called and data is managed within an app can readily expose potential vulnerabilities and unlock otherwise secure access to high-value services.
  6. Mobile apps play a material role in generating or managing revenue or other financial assets. High value assets or processes are a natural target for bad actors. Piracy, theft, and sabotage begins by targeting “weak links” in a revenue chain. An app is often the first target.
  7. Below is an infographic identifying leading risk categories stemming from increased reliance on mobile applications. The vulnerabilities (potential gaps) call out specific tactics often employed by bad actors; the Controls identify corresponding practices to mitigate these risks.

    The bottom half of the infographic maps the capabilities of PreEmptive Solutions Mobile Application Risk Portfolio across platforms and runtimes and up to the risk categories themselves.

    For more information on PreEmptive Solutions Enterprise Mobile Application Risk product portfolio, check out: PreEmptive Solutions’ mobile application risk management portfolio: four releases in four weeks.