What is Docker?

Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow developers to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package.

Docker is something like a virtual machine, but Docker allows application use the same Linux kernel without unnecessary dependencies that may be on the host computer.  This allows for some performance and reduces the size of the application.

The huge advantage of Docker is that is open source. That means that anyone can contribute as a volunteer too.

Who is Docker for?

Docker is a tool that’s designed for developers, administrators and software testers. For developers, it means that they can focus on writing code not maintain the environment. Reduce the number of dependencies, and also quick start with setting up initial development. Administrators get flexible and fast way to create and get running environments on easy way.  Software testers get the same environment that developer get to write feature. The last part is very important for two points: there is no misunderstanding in environment dependencies, and if there is a bug in software is easy to track and reproduce as well.

Getting started

On the Internet, there are a lot of information about Docker and why is so sexy thous days. Beginners guides for Docker, command-link simulators, a lot of images that are ready to use.  But I want to create my own tutorial that will be available on youtube channel. Starting with some basics to some advanced setup as well.

Docker and security

As a lot of tools, Docker brings some security too for the applications that are running in this environment, however, containers are not the thing that we can speak about security.  For example, there is something like kernel exploits, DDOS attacks, breakouts, poisoned images and secrets that can be compromised.


Lv0. VIM user

In the beginning of this post, I asked myself: why Vim and why I would like to cut my fingers? (Joke). An answer to this question is simple: I met with a number of situations in my life where I  actually edit the file on the server or on a specific device connected to the network. But how to do it when there are no possibilities of installing any external text editor?

Everyone has their own toolbox, which is a set of tools that uses in everyday work and even after work. Sometimes it is so that incoming to the company/job anyone could ask a simple question. What tools do you use? So then what you say? In my opinion, either in the work of the tester, programmer or system administrator and any other work related to IT, it is important to know well and use a text editor. And the text editor in both Linux and Unix is Vim. Some will say that the Vi, but for simplicity, I will say that Vi and Vim mean to me almost the same thing.

For the moment someone says, but he is the best Emacs text editor, again, another person can say that Atom is really great. OK, I agree with all the views, but … There are some cons. Especially on any Linux and  UNIX machine. If I log onto the production machine likely I’m will not even have the right to install any additional software but use this one that is already available. Of course, we can look around and see what happens but it will be hard with installing there any additional software. However, we will not use such editors as, for example, nano the text editor is often used on Ubuntu, but Red Hat or CentOS no longer can be a pre-installed editor, which is relatively easy to use.

Vim is free. If we have one machine – our beloved laptop we don’t need to pay for the license. We have 10,000 servers – is still free on each of these machines, there are no hidden costs involved.

The third reason – Vim is super customizable. The ability to install plugins, write your own and the engine itself can not be compared with any paid tool.

Another important thing is that Vim does not require a graphical user interface. Most servers do not have a graphical user interface installed, the X server so inevitably we can not run anything that will allow you to display icons, Eclipse, or are other java-based editors. We can never assume what we have installed on the server.

The last reason: Vim is a fast tool for editing code or editing files. If you’ve ever seen a user who has for several years used the Vim and how he can make changes in the code you were a probably very impressed. There is a competition which aims to see how quickly the participants can do the right things in Vim.

There is one disadvantage, the learning curve but in the end, it is worth it.


Apktool is a tool 😉 for reverse engendering 3rd party, closed, binary Android *.apk files. It can decode resources to nearly original form and then also rebuild them. Rebuild them also when you provide some modifications.

I create two simple apps to try apktool and basically check how it’s work. In directory we have two apps. First: app-debug.apk and app-debug-unaligned.apk. In this case, not matter really what’s are these apps for.

andrzejdubaj  staff  4530973 22 maj 23:15 app-debug-unaligned.apk
andrzejdubaj  staff  4531823 22 maj 23:15 app-debug.apk

To use apktool simply open terminal and go to this directory where are yours app’s(app). Type:

apktool d <name_of_your_app.apk>

and press ENTER. If everything it’s ok output should be similar to this one below:

$ apktool d app-debug.apk 
I: Using Apktool 2.1.1 on app-debug.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /Users/andrzejdubaj/Library/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

In our directory, a new folder was created with name of the app. It contains all folders and files that are contained in the *.apk file, for example:

  • res folder
  • smali folder
  • original
  • AndroidManifest.xml
  • apktool.yml
drwxr-xr-x    7 andrzejdubaj  staff   238 22 maj 23:18 .
drwxr-xr-x    5 andrzejdubaj  staff   170 22 maj 23:18 ..
-rw-r--r--    1 andrzejdubaj  staff  3588 22 maj 23:18 AndroidManifest.xml
-rw-r--r--    1 andrzejdubaj  staff   394 22 maj 23:18 apktool.yml
drwxr-xr-x    4 andrzejdubaj  staff   136 22 maj 23:18 original
drwxr-xr-x  137 andrzejdubaj  staff  4658 22 maj 23:18 res
drwxr-xr-x    4 andrzejdubaj  staff   136 22 maj 23:18 smali

From now ok we can:

  • analyze code
  • create modes

After we perform some edits, we can build our app. For this purpose I create separate folder and copy there decompile folder with all my changes:

total 0
drwxr-xr-x  3 andrzejdubaj  staff  102 23 maj 21:55 .
drwxr-xr-x  6 andrzejdubaj  staff  204 23 maj 21:54 ..
drwxr-xr-x  7 andrzejdubaj  staff  238 22 maj 23:18 app-debug

To build application, we can use:

apktool b <name_of_your_app.apk>

We can get something like that:

$ apktool b app-debug/
I: Using Apktool 2.1.1
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...
I: Copying unknown files/dir...

But I can’t get any *.apk file. But also at that point I was wrong. Why ? Because default directory for output file is:

... /app/app-01/app-debug/dist

Top build and receive *.apk file in the same catalog use:

apktool b <folder_name> -o <file_name.apk>

If everything it’s ok output should be similar to this one below:

$ apktool b app-debug -o apk-debug.apk
I: Using Apktool 2.1.1
I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building apk file...
I: Copying unknown files/dir...

Now we can so that our new *.apk file is in the same directory like rest of files:

-rw-r--r--  1 andrzejdubaj  staff  4512866 23 maj 22:13 apk-debug.apk
drwxr-xr-x  9 andrzejdubaj  staff      306 23 maj 21:57 app-debug
drwxr-xr-x  9 andrzejdubaj  staff      306 23 maj 22:07 app-debug-unaligned

But sometimes command described before really don’t work, and you can receive similar android Exception:

I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building resources...
Exception in thread "main" brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/awesomename/apktool/framework/1.apk, -S, /home/awesomename/out/./res, -M, /home/awesomename/out/./AndroidManifest.xml]
    at brut.androlib.res.AndrolibResources.aaptPackage(Unknown Source)
    at brut.androlib.Androlib.buildResourcesFull(Unknown Source)
    at brut.androlib.Androlib.buildResources(Unknown Source)
    at brut.androlib.Androlib.build(Unknown Source)
    at brut.androlib.Androlib.build(Unknown Source)
    at brut.apktool.Main.cmdBuild(Unknown Source)
    at brut.apktool.Main.main(Unknown Source)
Caused by: brut.common.BrutException: could not exec command: [aapt, p, -F, /tmp/APKTOOL3630495287059303807.tmp, -I, /home/windows/apktool/framework/1.apk, -S, /home/windows/out/./res, -M, /home/windows/out/./AndroidManifest.xml]
    at brut.util.OS.exec(Unknown Source)
    ... 7 more
Caused by: java.io.IOException: Cannot run program "aapt": error=2, No such file or directory
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
    at java.lang.Runtime.exec(Runtime.java:617)
    at java.lang.Runtime.exec(Runtime.java:485)
    ... 8 more
Caused by: java.io.IOException: error=2, No such file or directory
    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.(UNIXProcess.java:135)
    at java.lang.ProcessImpl.start(ProcessImpl.java:130)
    at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
    ... 10 more

I found soloution for that:

apktool d -f -r apkfilename.apk

-f replace previous decompiled apk’s code
-r ignore the decompiling of resources
This would prevent the resources from being decompiled, will copy the same resources when you recompile the apk.


Reading logs with ADB: the most useful commands

Reading logs during testing Android applications often force developer or tester to use appropriate tools. One of them is: Android Device Bridge. ADB comes as a part of the standard Android SDK, it provides a terminal-based interface for interacting with your devices with Android file system. Below I added some useful commands that every tester, programmer use during deal with applications every day.


Useful commands:

adb locat

– access to Android device logs, direct output to the console

adb logcat -d > [filename]

– this command allows to save logs in a file name you have specified, for example: abd logcat -d Users/user/storage

adb logcat -c - all

– logs on devices are erased, after that you are able to grab logs without unnecessary data

adb logcat -v time

– display logs with specified time

adb reboot

– reboot device

adb start-server

– ensure that there is a server running

adb kill-server

– kill the server if it is running

adb push app /system/sd/app

– push apps from comupter onto device

adb get-state

– prints: offline | bootloader | device

adb get-serialno

– prints: serial-number

adb status-window

– continuously print device status for a specified device

adb remount

– remounts the /system partition on the device read-write

adb reboot [bootloader|recovery]

– reboots the device, optionally into the bootloader or recovery program

adb tcpip

– restarts the adbd daemon listening on TCP on the specified port

adb jdwp

– list PIDs of processes hosting a JDWP transport

adb ppp  [parameters]

– Run PPP over USB.
Note: you should not automatically start a PPP connection. refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1 [parameters] – Eg. defaultroute debug dump local notty usepeerdns

adb -s [yourdeviceserialnumberhere] shell

– above command will start an interactive shell from your machine, but running on your device

adb shell rm -r /system/sd/app
adb shell rm -r /system/sd/app-private

– deleting existing apps on SD

adb bugreport

– return all information from the device that should be included in a bug report

fastboot oem unlock

– unlock bootloader, making root access possible

fastboot flash recovery

– flash a custom recovery image to your phone

am start -n com.package.name/com.package.name.ActivityName


adb shell am start -n com.package.name/.ActivityName

– starting application using adb tools