Tuesday, 30 September 2014

How to open apps from terminal on mac

I switched to mac from ubuntu recently. I noticed that apps installed from .dmg files are not accessible from terminal. In ubuntu to open say, gvim (MacVim in mac) I used to simply type gvim in the terminal. This doesn't work on mac :(

After doing some analysis on how apps are maintained, I noticed that each application (.app) is stored in /Applications folder. And .app file is simply a directory holding contents of the app. Say I open firefox, the executable which launches the app (firefox), stored in /Applications/Firefox.app/Contents/MacOS is executed.

So if I execute:
from terminal, firefox is launched!

However I do not want to type this huge path every time I want to launch firefox nor do I want to alias each and every app I install nor do I want to add all of them to $PATH. So I wrote a simple script to automatically open any app I want to.


Download this gist


Make it executable and move it to /usr/bin. You are done!

$ chmod +x app

$ sudo mv app /usr/bin/

How to use it?

Say you want to open chrome from terminal to open a html file

$ app chrome index.html

Say you want to launch vlc from terminal to open a file

$ app vlc file.mp4

Say you want to open MacVim from terminal and open a file. Note that it is case insensitive.

$ app macvim file

Thursday, 25 September 2014

ShellShock: Largest security bug ever in the computing world

​'Bigger than Heartbleed': Bash bug could leave IT systems in shellshock

Shell Shock: Bash bug labelled largest ever to hit the internet
- Sydney herald

You might have heard about "ShellShock" bug in bash shell that everyone is talking about. You might ask what is the big deal about it? and say that you don't even use bash. It might astound you if I say that this bug exists in so many systems from your fancy smart watches to android phones to Macbooks to powerful web/email/DHCP servers. Basically, bash shell is used everywhere!
"Heatbleed" bug, a vulnerability in OpenSSL servers, created a huge fuss few months back. Experts think that ShellShock is much more serious than that considering the number of systems being affected. Lot of military and government organizations are at risk.

So what is Shell Shock?

It is a vulnerability present in bash till 4.3. Because of this lot of applications using bash are not safe. This 22 yr old bug exists because of the way bash handles environment variables. It is common to assign a function to an environment variable in shell scripts. However it was noticed that the trailing code in the function definition is also executed. Hence it is possible to remotely execute malicious code in many websites by just injecting it at the end of function definition.

To give more detail consider:

env X="() { pwd; ls;}; echo hacked" bash -c "echo done"

The result is:

After function definition, malicious code echo hacked was also executed!

Am I safe?

Open terminal and execute this:

env X="() { pwd; ls;}; echo hacked" bash -c "echo done"

You have to worry if the result is:

instead of

In action!

There are three files in the folder:

after executing this all files get deleted!:

env X="() { :;}; rm -rf *" bash -c "echo completed"

Note that rm -rf * is injected (Here I have just typed :P) and it wipes the folder clean

How to fix this?

Considering the amount of legacy code which can't be modified, we need a patch in bash itself. Fortunately, a workaround is provided by RedHat here.
Sysadmins make sure that you apply this patch if you don't want to get fired :P

Worth Reading

Bash 'shellshock' bug is wormable

​'Bigger than Heartbleed': Bash bug could leave IT systems in shellshock

Wednesday, 17 September 2014

42.zip - Zip Bomb!

I was reading online sometime back and I came across this really interesting thing called 42.zip also known as Zip Bomb, Zip of Death, Peta bomb or decompression bomb.

The file is only 42,374 bytes (42KB). When unzipped it becomes 4,503,599,626,321,920 bytes (4.5 Peta Bytes)!!!

The main use of it is to render useless the host reading the file, usually to disable antivirus. When you unzip it, the antivirus will be busy scanning the unzipped files, sucking up all the available resources and a malicious program injected can execute itself undetected!

How it works?
42.zip has 16 zipped files.
Each of these 16 have 16 zipped files.
Each of these have 16 zipped files.
Each of these have 16 zipped files.
Each of these have 16 zipped files.
Each of these have 1 file, with the size 4.3GB

Still. How is this level of compression achieved??
It relies on repetition of identical files!! Think of it as same file being unzipped over and over again.
Awesome isn't it?!

Also read Fork Bomb.

Tuesday, 2 September 2014

Convert Little-endian UTF-16 to ascii

I took a csv export from mssql. I had to read this file in python. However there was a problem. Python was reading it in binary format.

file.readlines read it like this:

'\xff\xfe2\x000\x001\x003\x00-\x001\x000\x00-\x001\x000\x00 \x000\x000\x00:\x000\x002\x00:\x000\x000\x00,\x00i\x00n\x00s\x00t\x00a\x00l\x00l\x00 \x002\x000\x001\x003\x00,\x00t\x00o\x00o\x00k\x00 \x00r\x00a\x00\r\x00\n'

When i used file command on that file I got:

Little-endian UTF-16 Unicode text, with very long lines, with CRLF, CR line terminators

When I tried to use dos2unix command I got this error:

dos2unix: Binary symbol 0x000B found at line 9419305
dos2unix: Skipping binary file calls.csv

So I tried iconv command to convert the file to urf-8

iconv -f utf-16 -t utf-8 input_file > output_file

And it worked! Now python reads it properly.

Open file in existing gvim in new tab

We know that gvim -p can be used to open multiple files together in different tabs in gvim. However if you want to open a file in a new tab in the existing gvim session "gvim -p" wont do any good. For that we can use client server concept available in gvim. Add the following line in "~/.bashrc" file and you are good to go!

alias gvim='gvim --servername gViM --remote-tab'

Now you can simply give gvim [file(s)] to open in new tab in the existing gvim session!