Archive for the ‘Application Lifecycle Management’ Category

Automating Runtime Intelligence Code Injection

Monday, August 30th, 2010 by Joe Kuemerle

With the release of Dotfuscator Community Edition in Visual Studio 2010, developers were given a way to quickly and easily add application analytics functionality to their projects at no additional cost. Using Runtime Intelligence, developers or build managers can implement a customer experience improvement program to track how people are actually using the deployed applications in the wild. In May 2010, PreEmptive Solutions partnered with CodePlex to provide commercial level Runtime Intelligence data reporting to any project hosted on CodePlex.

The version of Dotfuscator that ships with Visual Studio 2010 can’t be added to an automatic build script because it requires user interaction to perform a build. The commercial version of Dotfuscator has both an MSBuild task and a command line option for build automation, but purchasing a commercial license for a pure open source project is normally not an option. At the request of the community, we are making two options available to help alleviate this issue.

The first option, available to anyone who has Visual Studio 2010 Professional or higher, is to register for and download a patch to upgrade the installed version of Dotfuscator CE to version 5.0.2601. This version of Dotfuscator includes a command line interface and removes the restrictions that block automation. It does not require any user action to start a build, nor does it require Visual Studio to be running. The instrumentation abilities are identical to the previous versions: up to 10 named features with none of the advanced functionality from the commercial version (custom data gathered at runtime, detailed system and performance data, unique serial numbers, custom tamper and expiration behavior). To download this patch, you will need to create an account here . Go to My Account and the patch will be available in the Downloads section. After you install the patch, you will have a new DotfuscatorCLI.exe application in your Dotfuscator CE installation directory which you can use to automate builds. The command line is similar to the commercial version of Dotfuscator and is documented in the Command Line Interface reference in the online documentation .

The second option is that open source projects hosted on CodePlex can use the commercial version of Dotfuscator to instrument the application. Any project administrator can request a PreEmptive Open Source Project License here and receive the full version of Dotfuscator to use as the Runtime Intelligence code injection tool for their project. The project will then have access to the full range of instrumentation features available to commercial users including custom data gathered at runtime, support for occasionally connected clients, easy integration for Silverlight XAP and ClickOnce packages and ongoing enhancements as we release new commercial versions of Dotfuscator. Additionally, the project will be able to use the MSBuild task or the command line to easily integrate into their automated build environment.

With these options, developers are now better able to get accurate and actionable feedback on how their applications are really being used and can tighten the feedback look between themselves and their users. Better information on usability and functionality will lead to improved applications, and now it’s easier than ever to get that data.

How do I love thee? Let me count the ways.

Thursday, August 20th, 2009 by Sebastian Holst

“How do I love thee? Let me count the ways. I love thee to the depth and breadth and height” - Sonnet 43, Elizabeth Barrett Browning

So “what’s love got to do with it?” (Private Dancer, Tina Turner) Hint: if people live for love, then businesses live for money

On July 14th, Microsoft announced Azure pricing and a “grace period” through PDC 2009. A primary rationale here is to enable development organizations to optimize deployment and monetization models to maximize Azure commercial opportunities.

So, whether you are a romantic (like Ms Browning above) or perhaps more hardened like Tina Turner’s Private Dancer (or Stanley Kubrick a la Full Metal Jacket), one thing is for sure - Microsoft wants Azure to “love you long time.” How deep, wide, high or long is the question.

Check out a this article in SD Times - PreEmptive’s Dotfuscator instruments Azure applications By David Worthington – where Dave Worthington makes many of the very same points.

Of course, we announced Runtime Intelligence Service (RIS) Azure support to help developers answer these very questions. While perhaps not as soaring as a sonnet – Runtime Intelligence allows for any .NET component deployed into Azure to be injected (post-build) with session, feature and method level monitoring. The runtime intelligence is streamed out of Azure for analysis. Other than writing a custom solution, this is perhaps the only means to measure adoption, usage patterns and performance inside Azure in near real-time.

Now, my posts are all intended to help you (blog followers) find more ways to make more money (we want to spread the love). So, you will note that I very specifically said the RIS helps to answer these questions. What the Azure development community really needs is an ROI calculator that will combine real usage data (from both legacy and piloted Azure applications) with Microsoft pricing and the offset IT expenses to come up with an Azure ROI calculator. I know there are lots of calculators being written – but how many of them can incorporate actual usage data before and after deployment to the cloud? That’s not our business – but could it be yours?

If yes, let me know and I will make sure you have what you need to call our RI Service via our RESTful API – making your calculator uniquely able to reliably predict cloud ROI.

As always, i have a more philosophical take on this issue on my personal blog at http://apps-are-people-too.blogspot.com/2009/08/how-do-i-love-thee-let-me-count-ways.html

Application Intrusion Detection

Wednesday, August 19th, 2009 by Paul Tyma

I recently worked with a UNIX security expert setting up a small pile of servers. We hired him to handle the total system security of the servers as those servers would be charged with storing highly sensitive customer data. In fact, the vendor for this data had very strict requirements as to how we were allowed to store this data. The requirements (something similar to PCI Level I) were dictated in a 40 page document where one of the rules literally required a monitored camera to be shining directly on the primary database server at all times.

My job was rather easy as I just had to hire someone to get the servers secure - not actually do the work. I happily found a crackshot security guy that had done large installations at maximum security. And he didn’t disappoint. I know my way around UNIX systems pretty well but he worked magic I’ve surely never seen.

One of the last things he did was to install an intrusion detection system. That is, a system that monitors all interesting system activity and sends out (a lot) of email about everything it noticed. Change a UNIX config file? Get an email. Add a user? Get an email. Issue a command as root? Get an email. Needless to say I started getting a lot of email.

At one point during a discussion we had about the system I asked him why we had the system at all. I mean, if this guy was so good (and to this day, I still believe he is) - an intrusion detection system is sort of like a prenuptial agreement. You get one in the event of something bad happening - but at the same time you can’t really get one without sort of admitting you *expect* something bad to happen.

Wasn’t his system secure? Did he really personally think he left a hole somewhere that would allow a hacker to get into the system?

He responded that he was 100% confident that after his work, the system was as secure as possible. He left no holes and patched all known vulnerabilities. He followed his declaration that of course - regardless of all that - of course the system can still be broken into. His response was utterly matter of fact. Of *course* break in was still possible - even likely.

I suppose this wasn’t a huge surprise. Despite locking the doors to our houses and cars - we still have alarm intrusion detection systems that detect entry. No one is foolish enough to think a car or house door lock keeps out a real thief. A reasonable defense after that is to get immediate notification when an intrusion occurs. Another reasonable defense that many people follow is to hide valuables. You typically don’t leave your stash of cash on your dresser - you hide it somewhere. In your sock drawer or under your mattress - but typically, even though you have a front door lock, and maybe an alarm system, its clearly prudent to add time and difficulty to a prospective thief’s job.

After some more discussion my security guy invited me to attend Defcon. A yearly security/hacker conference held in Las Vegas. I was intrigued and agreed. When I went to pre-register online - I found out that there wasn’t any such thing. No pre-registration, on-site registration only. And - no credit cards - cash only $120.

I arrived early at the convention and gave a nice lady my $120. In return she gave me an anonymous badge. She didn’t want my name or my address or my email. Everyone at the convention was to remain as anonymous as they wanted to be. The convention itself was jam packed. Wall to wall humans mostly in black t-shirts wth typically funny hacker slogans on them.

In one room they had situated 5 teams with networked computers in a competition where they simultaneously defended their servers and attacked the other teams’ servers. Another room had a large projected screen showing passwords of people at the convention that sent them unencrypted over the wireless (I shut-off my laptop and phone for the rest of the weekend). They showed the IPhone hack that could own a remote iphone with a single sent SMS message. I saw talks on hacking websites with request forwarding and one by an MIT student that beat stock spammers at their own game.

Needless to say - the folks at this conference weren’t messing around. To this day I get into discussions with developers as to the appropriateness of code obfuscation. Obfuscation technology has come a very long way past simple identifier renaming. These days it’s more about things like control-flow obfuscation and opaque predicates. Their argument usually circles around to some variation of “If an expert really wants your code - they’re going to get it”.

I couldn’t agree more. In fact, after attending Defcon I believe it even more. The only place I start to disagree is when they contradict themselves with solutions that they think will actually work. If your code is reachable, in any form, by users - its vulnerable. Software-as-a-service is often cited as safety. If that was true, then I wouldn’t have needed to hire a security expert. And he wouldn’t have told me point blank that no matter what you do - an expert can hack your server.

Protecting your software is not about 100% sure solutions - because there are none. It’s about throwing as many obstacles in the way of attackers as you can. Like I said - your front door lock hasn’t a prayer at stopping a thief - but for some reason you still always lock your door. Alarm systems don’t stop thieves; they just let them know that they’ve only got a few minutes to get their job done. Hidden valuables will be found - but the act of hiding them just makes the job harder.

The name of the game is risk and reward. Simple security measures by you that cause major headaches for attackers are what you’re looking for. Obfuscation makes deciphering your IP harder. Software tampering detection lets you know someone is tinkering with your application. By nature, attack surfaces start out pretty large. The best you can do is reduce that area as much as possible.

Lower the Cost of Knowing

Monday, July 6th, 2009 by Gabriel Torok

Before tools like Survey Monkey were available, you could conduct surveys. But the cost was much higher, often including costs of envelope stuffing,  outbound and return postage, incentives such as a dollar in each envelope (to try to increase the response rate), data entry costs, and long time delays. Given the hassle and costs, you might be forgiven for making important decisions based on sparse data. In America, it’s called going with your gut. The rapid proliferation of low-cost web-based survey tools is a clear indication that lowering the “cost of knowing” stimulates organizations to “go find out.” In the past, companies did not survey as extensively because they felt they couldn’t afford the higher costs, and perhaps they did not value knowing enough to invest more.

Likewise, before point-of-sale systems were widely available, retailers were able to track customers and their buying habits, but at a very high cost and hassle factor. It was probably easier to “go with your gut”. Now, point-of-sale systems are a multi-billion dollar a year business and retailers are at an extreme disadvantage if they don’t use one.

A lower cost of knowing continues shifts in our desire and use of information. Developments such as nearly free international communication to practically ubiquitous Internet search have made knowing quick and easy. For example, today it is possible to very quickly discover which vendor has the best price and service. Improved information allows everyone to make better and faster decisions.

And yet today, many software producers still take a reactive “go with your gut” approach to understanding how their customers use their applications and measuring the satisfaction they receive from them. That is because historically, it’s been difficult and expensive to measure how users - individually or in aggregate - actually use applications. In other words, they perceive the cost of knowing as higher than the value of knowing.

This will change as new options significantly reduce the cost of knowing for software producers. In tighter economic times such as now, getting low cost, accurate and timely insight into software behavior, stability and performance will become essential. Successful software producers will benefit from the value of enhancing the customer’s experience by proactively understanding problems and opportunities and acting decisively based on their knowledge. What your customers aren’t telling you might be hurting you. After all, why would you rely only on your “gut” or a handful of customers for feedback when you can easily listen to your applications in a broad and precise way?

How to sell to over one million .NET developers with VS 2010 and VSTS 2010

Monday, June 15th, 2009 by Sebastian Holst

Roughly 15% of all Visual Studio developers have used Dotfuscator Community Edition (CE) to prevent reverse engineering (and I think we can all agree that this is a relatively specialized requirement). If you accept the next uncontroversial assumption that more developers would want to know who is using their software, how and why than would be concerned about reverse engineering – then we can also assume that the new Dotfuscator CE that includes application monitoring capabilities will be adopted by perhaps 2X or even 3X more developers – or between 30% to 45% if the 6 million+ Visual Studio users.

This next series of posts will outline specific opportunities for entrepreneurial developers to build solutions targeting the millions of .NET developers likely be using these new capabilities as VS2010 reaches general availability.  For an earlier example of this, see my blog entry how to make $5 from every .NET developer on the planet.

Post 1 – Code coverage!? I got your code coverage right here pal!

If you think development teams would benefit from being able to readily reconcile testing code coverage results with beta usage code coverage to improve quality and reduce development costs – read on…

With VS2010 Dotfuscator CE feature tracking, you can stream back feature usage during a beta release that can provide a complete picture of what methods were called, in what order and on what technology stack. If only there were an easy way to not only visualize this in the context of the application’s code base but also to overlay this information on earlier testing code coverage results to ensure I have tested what is being used and my beta users are using what I think needs to be tested! That might be an opportunity…

We’ve got an “opp” for that! (apologies to the iPhone ad guys). If you have evaluated VS Beta 1, you may have already noticed that VSTS 2010 Architecture is a completely new release which leaves behind the current Distributed System Designer and the underlying System Definition Model (SDM ) and replaces them with the Unified Modeling Language (UML), Domain Specific Languages (DSLs) and other tools that are not related to UML. The specific tool I want to point to here is the Architecture Explorer (AE).  AE visualizes relationships inside code using the Directed Graph Markup Language (DGML). By extending the DGML, one can use the Architecture Explorer to create visual models of assemblies – post-build – combining both the relationships inside the code (this comes with AE out of the box) and testing and usage coverage results by extending the styles already included in AE. In short, The Architect Explorer with its DGML support and the ability to extend/modify styles offers an ideal means to quickly reconcile usage data with testing code coverage (and platform and framework coverage as well).

This screen shot shows a generic rendering inside the VSTS Architecture Explorer. The rendering is entirely driven through XML data and, as such, can be easily extended to provide specialized views that are relevant across the entire lifecycle of an application.

In this case, the color schemes (or fonts or sizes) can be driven by:

The level of testing completed as reflected inside a TFS repository to quickly answer the questions

  • Testing status – how much testing has been completed?
  • Testing the right things – are there components that should be getting more (or less) attention?

The level of usage by beta test users as reported via the instrumentation capabilities included in Visual Studio 2010 Dotfuscator CE to quickly answer the questions

  • Beta adoption sufficient – have enough users actually run the software through its paces?
  • Critical path coverage – are the new components being exercised as expected?
  • Testing coverage map to usage profile – combining both testing data and usage coverage data can identify areas of code that are not being tested sufficiently given the patterns of usage that are being observed? (mash up)
  • Platform/framework coverage – are enough users evaluating on Vista SP1 or .NET 1.1 or …?
  • What exceptions have been detected that have not been reported through other channels?