File systems, partitions and how to use fdisk.

Hey everyone! it's me again. Today (and for the next few posts actually) I'll bring you a series of tutorials and introductions to Linux and its inner workings. Some people have been asking me for some tutorials on Linux and some technical stuff about it and I thought some of you might also benefit from this.

First of all, and before I get my hands dirty with this: today we are going to mess with hard drives, partitions and partition tables so please, BE CAREFUL! if you are simply going to test these commands it is always a good idea to do it on a virtual machine with a virtual HDD.

Partition tables, partitions and file systems

There is a lot of absolutely great documentation on the subject if you want to go into more details which are outside of what I want to talk about in this post but, to give you an idea your physical hard drive probably looks like this:

Here is an image from Wikipedia to better explain how primary, extended and logical partitions are organized

In the very first position we have the MBR partition table, which is a small amount of bytes dedicated to point to primary partitions and whether they are bootable or not (are they an OS partition or simply a data partition?).

Then we find some reserved space, some very interesting reserved space. This space is basically like "rounding" in disk terms and although it's technically unused, some OS use this space to save some session data when rebooting or maybe even some boot sector viruses.

Then we have our partitions, they can be primary or extended which may contain more (logical, in this case) partitions "inside" so you are not limited to the 4 partition limit with MBR partition tables.

These partitions need to be formatted into a properly structured partition using a file system. Some examples? ext4, NTFS, exFAT, FAT, FAT32... There are a few gazillion small differences between these (and the other 95% of other file systems I didn't mention) which you can find here if you are into this sort of stuff.

TL;DR Hard drives are like... sitting on an airplane: The stewardess (Partition table) is at the front and knows who is sitting where, in the first row there is some empty space that no one really uses, and yet there are some weird bags there sometimes (reserved partition). Then we have all the seats (partitions) which have been properly cushioned according to the users' preference (file system) where the users (OS/data) rest their butts on. Oh and that lady with 3 kids in a single seat? that's an extended partition.

Let's get our hands dirty: how to format hard drives in Linux

Note: these tests have been done on a 15GB HDD using a recent arch linux DVD on a VirtualBox VM. No hard drives were harmed during the course of this tutorial.

Also, I will not write the commands directly (you can still see them in the screenshots). Why? to avoid readers copy-pasting the commands and messing their drives.

1) Let's see what we have and what we want

For that we use the -l argument (l from list, get it?)

In the image above you can see we have our empty 15GB HDD as /dev/sda (which, in case you don't know, marks it as a drive 'a', if it were in /dev/sdb, it'd be the second drive 'b')

For this demo, we are going to set the partitions as follows:

• 512MB swap partition
• 5GB ext4 partition
• The rest as another ext4 partition for data

This is by no means the most optimum way or partitioning (swap is usually last for instance), nor may this ratio work for your particular case, you'll have to decide how you want to cushion your seats yourself. (but I think 512MB swap and ext4 is a pretty solid bet as of 2014)

2) Split!

It's time to 'split' the Hard drive into partitions. For that we write fdisk and the drive we are interested in partitioning (/dev/sda in our case). This will take us to a prompt where we can enter our commands (no idea what do? press 'm').

To create our partition we press 'n' (new), set it as primary, partition 1 (this will make our partition /dev/sda1) and size 512MB, typing +512M. Done!

But hey, you lied! this is not swap! Well you're right, it isn't. for now we are simply 'splitting' the drive, then we'll get back to file systems.

Then we do the same for the other two partitions (I'm not including a screenshot or this post will get too long), we simply set the size to be +5G for the next partition (2) and set it as default to fill the rest of the drive in the last one. Once we are done we press 'w' (write to disk)

The result?

3) File systems

Time to set our file systems. You can do this from within fdisk by going back to fdisk <drive> (remember, drive, not partition!) and setting it with 't', but we are going to do this using mkswap and mkfs, to learn more stuff and other ways of doing it.

mkswap /dev/<partition>

will make your partition (in this case it should be /dev/sda1) a swap partition.
Now, to format sda2 and sda3 as ext4 partitions, we make use of mkfs.ext4

mkfs.ext4 /dev/<partition>

for both sda2 and sda3.

4) Enjoy!

See? that wasn't so bad was it? maybe my explanations are not as great as they could be so if you have any questions, ask below in the comments!

Cells, identifiers and how the network can locate you

My first post tried to be an approach to the cell idea, so in this second part I am going to explain what is, in fact, a cell, how it works and how the service provider can determine in which cell you are at every moment.

Despite there are a number of differences depending on the technology (2G, 3G, 4G), the mobile network model always follow a hierarchical scheme. It is usual to see the network as two separated segments:

• The 'core' segment, the wired part of the network, responsible for communications routing (through packet or circuit switching), mobility management and billing. It is usually composed of a central element (the switching center) and a number of databases for storing information about users. 
• The 'radio access' segment, which is the true 'wireless' part, responsible for the establishment of the radio link between network and users. The basic element of the radio access network is the base station, which is the set of devices (transmitters, receivers, modulators, antennas...) that provide service to a single cell, and several base stations are managed by higher level elements. These are the base station controllers, whose main task is to distribute network resources among its dependent base stations.

A very simplified model of the mobile network architecture.

The total service area of the network is partitioned into smaller geographical regions, to help tracking users location. In GSM/GPRS/UMTS technologies, these regions are known as 'Location Areas', in the case of circuit switching, and 'Routing Areas', for packet switching, whereas LTE introduces the concept of 'Tracking Area'. This logical division is pretty useful in order to optimize signalling, paging procedures, etc.

Each cell, as well as the location area it belongs to, are unambiguously identified by a pair of numbers: the cell ID (CID) and the Location Area code (LAC). These two identifiers allow the service provider to know exactly in which cell the user is. Even though this location method is far from being as accurate as GPS, it is very resource-saving for the network.

Apparently, cells, location areas and all the related stuff are transparent to the user. Is there any way we can access this concealed information? Can we get to know the cell we are connected to? Well, we can write a really simple Android code to show a lot of network parameters (such as CID, LAC, mobile network code, mobile country code, and so on...), it isn't difficult at all, but for the moment, to keep it simple, here is a quick way to reveal this information.

If you own an Android device, try to type *#*#4636#*#* in the dial screen. This code will open the Engineering test menu, where you can check, among other things, network related information.

Phone info screen

In the screenshot above we can see the phone's IMEI, our service provider and, of course, the stuff we are looking for: the network details. We can find the LAC and the CID of the tower we are connected to, the signal strength our antenna is receiving (measured both in dBm and asu), and a list of neighboring cells in ID@strength format. iOS presents a very similar feature, just by typing *3001#12345#*, but the results it retrieves are slightly more extensive, including bandwidth usage and other interesting data.

Easy, right? In the next post I will show you how to implement a simple application to get a more detailed insight of the network parameters.

How to get the APK of an installed Android application

Hi everyone! I'm Alessandro and this is my first post. I will explain a way of getting the APK file of an installed Android application for further analysis.

First of all, I'm assuming we are working in a Windows platform, so we go to Android SDK page and get the version for this platform. In my case, I downloaded a ZIP file and uncompressed it. We will use the adb (Android Debug Bridge) application, which is located at UNZIPPED_FOLDER/sdk/platform-tools/adb.exe.

Once you connect your Android device to the computer, you could use the command adb devices to retrieve a list of devices.

With this tool you can perform several actions, such as opening a shell, retrieving files, recording the screen, etc. In this case, we'll use the adb pull command and the package manager. From the command line, we can list the installed packages on the Android device using adb and the package manager: adb shell pm list packages. After finding the package whose APK we want to save, the next step is to determine the path of the APK for that application. Normally, the APKs are located in the /data/app folder, but if we connect to the device through a shell, we cannot see anything there:

In spite of this issue with the permissions, using the adb tool we can find the correct path for the selected package: adb shell pm path selected.package.name

Now we know the correct location of the APK, we only have to retrieve it using the pull command: adb pull /data/app/yourapplication.apk

How can the APK file be useful? Well, in following articles we'll find out how to decompile it and get the application source code.