0

I've read this blog (and readers' comments therein) with interest and it highlights UWP's binary compilation -- intended to boost performance -- but at the same time playing part in making reverse engineering difficult due to binary compilation. On making reverse engineering difficult, I have also come across various comments alluding to how the the async/await asynchronous programming plays an important role in obfuscation (but not seen a detailed analysis on the subject to quote as a reference). I have also noted an interesting kinda thought-provoking argument here which makes these evolving programming technologies even more interesting.

Does UWP .Net Native with asynchronous programming make obfuscation irrelevant? Can we feel that a plain UWP apps's intellectual property protection (IPP) is as good as a non UWP app with 'good' obfuscation?

user5525674
  • 921
  • 1
  • 7
  • 19
  • 2
    Reflector understands enough about async to be able to decompile it now. I'd expect other decompilers also do now. In and of itself, async/await was only an obstacle to decompilation until the decompilers are updated to spot the compiler transformations. – Damien_The_Unbeliever Dec 07 '15 at 10:00
  • Interesting input. So async programming is not a major impediment to decompilation on its own, which means just leaves the .Net Native toolchain. But, when you refer to Reflector, you don't mean for **.Net Native**, right? – user5525674 Dec 07 '15 at 10:13
  • 1
    Obfuscation is impossible, you must submit your package to the Store server without it. Otherwise it can't re-package it, the .NET Native translation step happens on that server, not your machine. The only reason you have it is so you can test the Release build of your app. Very important, .NET Native cannot translate every program without help. But sure, nobody ever attempts to decompile hundreds of kilobytes of machine code. – Hans Passant Dec 07 '15 at 12:58
  • I follow your point about .Net Native being on the server. The question still remains whether **.Net Native + asynchronous programming** makes obfuscation unnecessary, to the extent that we need not worry about IPP more than with obfuscation applied to the app (yes, I do realize you cannot submit with Store Apps). – user5525674 Dec 07 '15 at 13:08

1 Answers1

3

I have always felt that obfusation is the wrong answer to the problem.

But you are correct: decompiling and reverse engineering the output of a .NET Native compiled program is much harder. It would in fact be even harder than what obfuscation on IL used to do. But it's still not impossible though.

Can we feel that a plain UWP apps's intellectual property protection (IPP) is as good as a non UWP app with 'good' obfuscation?

Yes, in fact, it will be even better.

Kris Vandermotten
  • 10,111
  • 38
  • 49
  • 2
    Beyond this, using an obfuscator is specifically unsupported with .NET Native. – MattWhilden Dec 09 '15 at 01:05
  • @matt-whilden: Thank you for correcting the Tag. I can understand your remark above without the phrase *Beyond this*. Can you explain what you mean with the qualifier phrase *Beyond this*? – user5525674 Dec 09 '15 at 08:37
  • 1
    I really just meant that Kris is correct in that it's certainly more difficult to understand the native compiled binaries that come out of .NET Native. I just want to make sure that when obfuscation and .NET Native is being talked about that it's specifically called out that obfuscated binaries are explicitly non supported by the .NET Native compiler. They produce IL that is too different from the IL we normally see out of the C#/VB compiler and will very likely lead to compilation issues. Let me know if that helps. – MattWhilden Dec 09 '15 at 19:00
  • Thank you Matt, that clarifies it. – user5525674 Dec 10 '15 at 04:42