Pages

Monday, September 16, 2019

How to located the installed & cache directory path for Deno?


Recently, I had installed the Deno v0.18.0 using brew on macOS. Then tried couple of samples given there. I was amazed to see, how closely it behaves like Golang. When we run the script for the first time, Deno downloads all the dependencies provided in the import statement that is required to run the script. When I ran the same script next time then it doesn't download any dependency. So that means it caches all those dependencies and uses the same next time.

Now I was eager to see the cache, but can't find it at the usual locations but after some time with the help of Google, I was able to find the correct location. So I thought it would be pretty useful to put it in blog for ready reckoner.

So here is the sample path on all major platforms

Platform / Location
Binary
Cache
Windows
C:\Users\me\AppData\Roaming\deno\
C:\Users\me\AppData\Local\deno\
macOS
/Users/me/.local/bin/
/Users/me/Library/Caches/deno/
Linux
/home/me/.local/bin/
/home/me/.cache/deno/

Here is the same path using the bat / bash syntax

Platform / Location
Binary
Cache
Windows
%appdata%\deno\
%localappdata%\deno\
macOS
$HOME/.local/bin/
$HOME/Library/Caches/deno/
Linux
$HOME/.local/bin/
${XDG_CACHE_HOME-$HOME/.cache}/deno/

That's it!

Wednesday, September 4, 2019

Protect your Android app from reverse engineering & plagiarism

Few years back, we faced a hard technical problem while working in IoT project. We were having a mobile app to control smart electronic appliances that consumes our web-service. A third party somehow managed to use our mobile app with their service. We assume that they had reverse engineered to crack the services. So we had to protect our mobile app which was cordova based cross platform app

I have been allocated to analyse this issue and propose a solution. So during my initial analysis I found that first we should secure the mobile application installer because Android's .apk installation file usually packaged together all the resource files used in the hybrid project. Crackers could reverse engineer it to get those files. I know that we can ensure protection only by increasing the level of security.

So I minified all the files, bundled together and applied obfuscation over it; which made hybrid portion bit more secure. After this I used Arxan to protect the mobile app at binary level.

The next step was to ensure the service authenticity; for which I'd used session based synchronous incremental token validation system on app level and get it implemented on a web-service layer to support it.

The outcome was that our app become much more secure & protected. It took few releases till all the users updated the app. Now the third party has stopped supporting our app as we don't see any cross origin requests in our logs.

From this incident we learned that usually we think that the project is at startup level, so they don't worry much about security and protection of the project initially. But with time project grows, it becomes more vulnerable. So we should always keep in mind the basic things like security; during the startup phases.

Now I use this app protection technique in all other enterprise level apps and try to get it implemented during the startup phase.