Tag Archives: JavaScript

NativeScript/JavaScript Tip: Debugging

Once thing I was made aware of today was that not everyone knows the magic "debugger;" command.   I suppose this makes sense; I rarely see it mentioned, but it is a very useful debugging command in the JavaScript world.

The "debugger;" command is used to cause the application to stop and enter the debugger at that point.   This works in Node.js, the browsers, and even in NativeScript!    In a browser the developer tools must be open; if your debugger tools are closed; it will ignore it.     In node, a debugger must already be attached or it will also ignore it.

In NativeScript it will actually halt the program and WAIT until a debugger is attached!   So don't release your code

So pretend my code in main-page.js is

function pageLoaded(args) {
var page = args.object;
// do something with the page object.

You can then start the application on the device; and it will automatically stop right at that debugger; statement.   Then at the command line type: tns run android --start and you will be in the debugger right at that line.

Introducing NativeScript-Protect

(c) 2014, Yuri Samoilov

(c) 2014, Yuri Samoilov

UPDATE: Works on iOS and Android; see https://AppProtection.net.

Have you spent months working on the perfect application?  Are you now worried someone will just copy your source code right from your NativeScript application?  (This is not a unique issue to NativeScript; ReactNative, Titanium*,Cordova/PhoneGap and any other platforms that are not compiling Java code have this exact same issue. )

Well, I have a solution for you.  After a lot of hard work; I am proud to introduce my first commercial component into the NativeScript eco-system;  NativeScript-Protect.   The NativeScript-Protect plugin is a (very) simple  install and then it will automatically encrypt and/or minimize your source code while you are building your release version of the project.

It automatically ties itself into the NativeScript (tns) command so that you do not have to do anything. When you run anything that does a build; it will automatically encrypt and/or minimize your build copies of the code.

This does NOT touch your original source code; only the BUILD copies that the NativeScript (tns) command copies into the build system.  So it makes itself a seamless part of your standard build process that you can just totally forget it even exists.

The initial release is only for Android; but I expect to have the iOS runtimes done early next year.

If you would like to see it in action; I have a 4 minute video showing it from start to end.

In addition, two demo APK's compiled as a debug app with everything encrypted or just the main app files encrypted, can be downloaded for you to check out and kick the tires.
If you have any questions; please feel free to comment here, or contact me via the contact button on the nativescript.tools website.
* - Titanium has a encryption step; however it is rather simple to decrypt system and so in my book this is actually worse than no encryption since it gives a very false sense of security.
UPDATE: The current version turned into AppProtection.net -- So it fully supports Android & iOS.

Adding External Resource Security

lock-143616_1280In a lot of larger web sites it is pretty common that you use several third party resources like JavaScript.   However, this is a potential malicious door into your customers computer via your website.   What happens if the third party resource is changed by someone who does not have your best interests at heart.  Your page will still happily load the malware right onto your customers browsers.    So what can you do about this?

Well I'm glad you asked.   In the just released Chrome 45 (and soon in an upcoming Firefox release), they have added a awesome new feature to protect your customers (and your reputation).   When you link to any resources in your web page; you can now use the integrity attribute to tell the browser that this file must match this hash to load and use this file.

So <script ... integrity="sha256-some_sha256_hash"> or <link... integrity="sha384-some_sha384_hash">

The browser integrity attribute must support the sha 256, 384 and 512 hashes according to the w3 spec. For browsers that don't support this yet; then this won't do anything and the resources will load fine just like normal.  But in browsers that do support this; when the browser downloads the resource it will hash it and verify the hash matches before allowing it to be used.

On Linux you can generate the hash by doing:
cat the_file_resource | openssl dgst -sha256 -binary | openssl enc -base64 -A

On Windows if you have openssl installed you can do:
type the_file_resource | openssl dgst -sha256 -binary | openssl enc -base64 -A

Or if you don't have openssl installed; you can also easily cheat by using Chrome.   Just add the integrity with a bogus value; then reload the page.   Chrome in the developer log will show you the computed hash for the file when it blocks it.

For the full W3 Spec: https://w3c.github.io/webappsec/specs/subresourceintegrity/