Category Archives: Tutorial

Bypass Root detection in Android [by modifying the APK]

Developers implement root-detection mechanism in Android to prevent users from using their app on a rooted phone. The app (apk) will implement different checks to determine whether the phone is rooted or not. Later, after this check, if the phone is rooted then the APK will display some message like “This device is rooted, exiting the application”, or “This application will not work on rooted device, exiting!”, and it will exit the application.

  • How to bypass this – (a) the APK checks at the device level and determines that the device is rooted, (b) APK will display the message and close the application.
  • Between the step (a) and step (b), let the APK know that the device is rooted – but before it gives the command to exit the application – we can change the code to not exit the application even if the device is rooted.

Below are the technical steps to perform this. This method works most of the times, and doesn’t need Xposed modules or other tools.

Lets refer the APK/Application as test.apk for this article. Decompile the APK by using apktool, with the following command:

apktool d test.apk

The code of this apk will be available in a folder named ‘test’. There will be smali files in the folder, which will have all the application code.

Search for text like ‘rooted’, ‘exiting’ or ‘root’ – according to the message which is being displayed when you start this application on a rooted phone. Note the name of the file which is containing this text, open it in a text editor.

Functionality will be like this:

  • APK will check the device is rooted:
    • if yes (e.g. equals to 0),
    • exit
    • if no (e.g. not equals to 0),
    • continue

If you make the condition as ‘not equals to 0’, it will not exit and allow the application to run. After making this change, re-compile/build the APK by using apktool with following command:

apktool b test test-new.apk

A new apk will be created with the name test-new.apk, and then create a key and sign the apk with following commands:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore test-new.apk alias_name

Now the APK is built, signed and ready for installation. Install this APK by using ADB and now it will allow the application to run on a rooted Android device.




SSL/TLS and Your Browser

SSL in Browser



SSL/TLS provides an extra layer of security to the HTTP, making it HTTP Secure (HTTPS). It works on the Application Layer (OSI Model) along with HTTP. HTTPS is not a different protocol, but the underlying HTTP with implementation of SSL/TLS for security.

Public Key Infrastructure and Certificate Authorities are used for making it possible.

How HTTPS works?

Short Version
Just like the TCP Handshake, a handshake happens in SSL between the server and the client. We can break this handshake into three steps: Hello, Certificate exchange and Key exchange.


The client sends a Hello message and the server responds with its Hello message. These messages contain information like the SSL version supported, cipher suite and some random data for key generation.

Certificate Exchange

To provide its authenticity, the server has to send its SSL certificate to the client. On receiving the certificate, the client checks whether its verified and trusted by some Certificate Authority, and takes the decision accordingly. For some sensitive applications, the server can ask for a certificate from the client too.

Key Exchange

A symmetric key is exchanged between the two parties. The client computes a key, encrypts it with the server’s public key, and sends it to the server. Only the server can decrypt it, by its own private key. All the communication then takes place encrypted with this symmetric key.

Long Version
Client Hello

After the TCP connection is established, the clients starts the SSL handshake. The important data in the Client’s Hello message includes:

  • Version Number (eg. SSL 2.0, SSL 3.0, TLS 3.1)
  • Random Data (which is later used with the Server’s Random Data to generate a secret key)
  • Cipher Suite (the list of cipher suite available with the client, which includes – the protocol version, the algorithm for key exchange, the algorithm for encryption, and a hash function)

The Client Hello message can be:

ClientVersion 3,1
SessionID: None (new session)
Suggested Cipher Suites:
Suggested Compression Algorithm: NONE

Server Hello

The Server responds with its Hello message, and some of its fields are:

  • Version Number (The highest version which both of them – server & client support)
  • Random Data (which is later used with Client’s Random Data to generate a secret key)
  • Cipher Suite (the strongest cipher suite which both server & client support is chosen by the server. If there is none, the session will be ended with ‘handshake failure’)

The Server Hello message can be:

Version 3,1
SessionID: bd608869f0c629767ea7e3ebf7a63bdcffb0ef58b1b941e6b0c044acb6820a77
Use Cipher Suite:
Compression Algorithm: NONE

Along with the above mentioned details, the following steps take place in the Server Hello message:

  • The server sends its digital certificate to the client, which has the server’s public key
  • Server creates a temporary key to the client
  • Server asks the client for its certificate, to validate the client’s authenticity
  • End of hello, meaning the server’s Hello message is done, and client can respond

Client Response

After getting the server’s Hello Done message, client starts talking. It sends the necessary messages in the below mentioned sequence:

  • Client certificate – contain’s the client’s public key, to provide its authentication at the server
  • Client Key exchange – the most important part of the communication. The client computes a premaster key from both the random values previously exchanged. This key is then encrypted by server’s public key before sending it, so that only the server can decrypt and get out the original key with its private key.
  • Change cipher spec – all the further messages will be encrypted using keys and algorithms negotiated
  • Client Finished – is the hash of the entire conversation. This is the first message which is encrypted and hashed for the session.

Server Final Response

This is the final message in the conversation between the server and the client to have a secured connection. The server’s final response will have:

  • Change cipher spec – will notify the client that the server will start encrypting the messages with the negotiated keys and algorithms
  • Server Finished – is the hash of the entire conversation to this point. If the client can decrypt this message and validate the hashes, it means that the SSL/TLS handshake was successful.

After the SSL/TLS handshake is done, further communication is secure between the server and the client.


A representation of how your browser starts a HTTPS connection with website

  • Firefox (your browser, for example) connects with the server of with HTTP and asks for the login page which uses HTTPS
  • For the communication, the server sends Firefox a certificate, which contains the server’s public key
  • Firefox verifies the public key of the server from the certificate
  • Firefox chooses a random symmetric key and encrypts it with the public key of the server
  • On receiving the encrypted message, the server decrypts it with its private key. Nobody else on the network who has received the encrypted message can decrypt it, because they don’t have the server’s private key. Now the server has the symmetric key with it
  • Every time Firefox wants to send something to in a secured manner, it will encrypt it with the symmetric key. On the other end, the server will decrypt it with the same key

Every website/server which wants to implement HTTPS (i.e. SSL/TLS security) has to buy SSL certificates from authorities like VeriSign, Comodo, etc. Many websites implement HTTPS part only for some important pages (like login or payment) and other parts of the website work on simple HTTP. Implementing HTTPS for the whole website is not much costly, but the CPU overload increases in processing the requests. Hence many website owners keep away from HTTPS because of the cost factor or the overload factor. Recently Google announced that it will reward the HTTPS webpages with a higher ranking in its search results (source).


Why not use asymmetric key encryption for the handshake?

There’s an answer on StackExchange. (1) Asymmetric encryption is much slower compared to symmetric encryption, (2) For the same keylength, asymmetric is weaker compared to symmetric encryption.

What an attacker can see if you are using SSL/TLS during your connection?

If you are using SSL/TLS correctly, the attacker can interpret only some of your data. That includes – the domain you are connected to, the related IP address and port numbers.

For example, if you are doing a Google search using https, the URL in the browser will be:, and you can see the full URL. But on your cable, only the domain name is sent to the DNS for domain name resolution, instead of the full query/URL. Hence, you can say that HTTPS hides your full URL, only the domain name is revealed.

HTTPS provides confidentiality of data, but not anonymity of who is sending / receiving the data.

This interactive image by EFF provides clear understanding of what can be seen by the eavesdroppers while you are using HTTPS and while you are using Tor.

(References: SSL/TLS in Detail, An answer at StackExchange)

Phonebook course on Codecademy

After a Codecademy course which teaches the game of Rock Paper Scissor step-by-step in Python, last month I used the keyboard for creating a Phonebook utility on Python and put it on Codecademy. The Phonebook exercise there teaches users to create a file for storing contact name-number and later get them as desired. The exercise is under the Codecademy team for beta-testing, and will be avialable in the Track listing soon after reviewing. You can test the exercise here: Phonebook on Codecademy.

Common problems during initial Honeyd configuration

Honeyd is a small daemon for Linux (now also available for Windows) to simulate multiple virtual hosts on a single machine. It is a kind of an interactive honeypot. The latest release can be downloaded from Honeyd release page.

For my project, I have been working with honeypots, and Honeyd is one of them. During the initial stage, I faced some problems while starting the basic setup of some personalities with Honeyd. Here I recall those problems and some misconfigurations which can result in errors (mainly: config file parse error) and can be a problem for first time users.

The command to start honeyd daemon through your terminal is:
# honeyd -d -f honey.conf

Here, honey.conf is my configuration file and -f is used for pointing to that file. -d is used to tell the machine to run honeyd as a daemon.

eth0 not an IP


Reason: Your ethernet connection does not have an IP address.

When you are testing on a single machine, the first thing you need to do is give your interface an IP address. The below command will take care of it. Replace ‘eth0’ with your respective interface.

# ifconfig eth0
(If you are using a different interface like eth2, you need to mention while starting honeyd. Should be -i <interface>, example -i eth2)

Now, here is my sample configuration file:


Lets disect the file line by line.
1: creates a personality, and we will refer to it as windows.
2: name the personality as Windows XP, means someone who is scanning our honeypot will find it so.
3: including the file, which will simulate a FTP server.
4,5,6: opens the tcp ports 135, 139, 445.
7: bind the ip address to our personality.

Try running the honeyd while using our honey.conf file. Error?

parsing configuration file failed

Now, during my initial day I had taken help for the FTP server from a blog on, “Weekend Project: Use HoneyD to fool attackers“. As it is a tutorial on, there are more chances that this post will be on top of your Google search for HoneyD on Linux. My point is, they have simplified the process of configuration, explained well, but there is one small error. I have highlighted it in the below screenshot:


The error that you will get will be: parsing configuration file failed. It will be on line:3. Set is used for setting our personality to some predefined condition, while add is used to provide something extra. If you are using set for providing preloaded scripts, then surely you will face parsing error.

Solution: replace set with add.
This should be your configuration:

4Now, your honeypot will start its work without any error. Time to rejoice? Kind of.


How to log any attacks or scans on your honeypot? Use -l <filename>. Normally, it is logged under a directory named honeyd under the /tmp directory. If you dont have that directory, create it with mkdir.
The command I used for logging the attempts was:

5Ah, permission denied!
How to solve this? You guessed right – the file is write-protected, and hence give the write permission to everyone. Use chmod command.
# chmod 766 /tmp/honeyd/log

Can’t detect Ping?

As you’ve seen the configuration file, I have not yet given any MAC address to my honeypot. Hence, it is not yet accessible to the outside world. Try pinging from a different computer, it will fail.
Provide a MAC address to your honeypot with the line as shown in the below screenshot. Check the MAC address of your host machine, and give the address of your honeypot as near as possible to the host address.


It is good if you have given the personality name as “Microsoft Windows XP Professional SP1”. If you have given a name like Windows XP (like I have given, in the below screenshot) or Linux Ubuntu 13.10, you are prone to getting an error while parsing the configuration file.



There are conventions for naming the personalities. There is a list of fingerprints (or names for such personalities) which should be used for naming the honeypot personality. The fingerprints are located in nmap.prints file. It uses the fingerprints which are identified by nmap scan, and hence when someone is scanning the honeypot, they will get the name provided by you.

Locate the nmap.prints file, with locate command. The you can use more to view the whole file, or if you simply want to view the fingerprints, use the grep command as shown in the below screenshot: (ref: Honeyd FAQ)9

You can use any of the personalities in the list displayed by the above command.
While sometimes, there is a need to specify the fingerprint file on the command line. The command should include -p <fingerprint.file>
# honeyd -d -f honey.conf -l /tmp/honeyd/log -p /usr/share/honeyd/nmap.prints

Again, start your honeypot with a new personality.
Ping the honeypot from a remote machine. It will log everything, along with displaying it on the console.
Try doing FTP to your honeypot. It will show you the FTP login screen. (As usual, anonymous login is not allowed!)
Let me know if you face any other problems in configuring your honeypot.

Conclusion: HoneyD is very easy to work with, and hence the choice of many. But some common mistakes like typo or proofreading can bug you till infinity. You mostly need to take care with the initial configuration.

A Python exercise on Codecademy

print “Hello World!”

These days I was busy with college work and exams. I learnt Python some months back, and found it very interesting to work with. My sources of learning Py were Head First Python (O’Reilly) and Beginning Python (Wiley Publishing), plus some online tutorials. While my first and favourite source was Python exercises on CodeAcademy. Hence, afterwards I made an exercise on that website for playing Rock Paper Scissors. You know that the coding of such program is too easy, but the backside validation for the user inputs was much tricky. Willing to make some more exercises at an advanced level. The Rock Paper Scissors exercise, after some beta testing by the website peeps, is available here: Rock Paper Scissors on Codecademy

Snort on Debian

Snort, is an Intrusion Detection and Prevention System for Windows and *nix machines. You can download it from here: Snort Download.

Well, for debian we dont require to download it from there. The command to download and install it is-

# apt-get install snort

This will download and install Snort to your Debian.

Next step is to configure the Snort for generating alerts for any activity.  For example, we can consider ICMP-ping requests for alerts. Whenever someone pings our machine, an alert will be logged.

For configuration, 3 directories are necessary. If they are not created on their own, create them with mkdir command. They are:




Now, our configuration file is: /etc/snort/snort.conf

If you need, you can take a backup of the original file, and then create a new file and edit it as below:

include /etc/snort/rules/icmp.rules

We don’t need to add other lines, as right now we are considered about only the ICMP requests, we will configure only the icmp.rules file and hence it is referenced in the snort.conf  file.

Now, the icmp.rules file contains the below content:

alert icmp any any -> any any (msg:”Hey, someone pinged!”; sid:477; rev:3;)

This line will log any ICMP request from any source, with the given message. The sid and rev are used to uniquely identify Snort rules and its revisions.

Now, to start Snort listening on interface eth1, the command will be:

snort -c /etc/snort/snort.conf -l /var/log/snort -i eth1

The first location is where the Snort configuration file is located, while the second location with -l is where to store the alert, and -i provides the interface selection.

Now, ping the machine from some other machine, and you will find an entry in the alert file located in /var/log/snort. It will contain the source and destination IP addresses, the time and date of the incident and other information related to the query.

Similarly, you can configure Snort to generate alerts on various incidents like FTP login, SSH attempts, Telnet requests.

Snort Configuration for ICMP