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.

Rsync and "No password? nah, it'll be fine"

You all know rsync, he is our trusty fellow that is always there to help you transfer your stuff and help you forget how scp and rcp treated you bad in the past. He is fast, he is free and he is really nice... maybe too nice.

As it turns out, our good ol' mate is far too nice sometimes and will let passing strangers move your stuff around as well... allow me to elaborate:

1. What is rsync?

Rsync is a small tool developed back in 1996 that allows the user to copy files from one place to another really fast (it's obviously much more complex than that but lets keep it simple for now). This tool can be used for many things but the most common uses are:

1. Copy files and folders locally or to an external location (substituting the cp and scp tools respectively)
2. Automated backups (both local and to remote locations)
3. Mirrors: same idea as backups, since rsync only copies modified files, you can mirror changes in your web directory by rsyncing with your destination.

2. Sounds awesome, what does this have to do with the post title?

Here comes the tricky part: for connecting to remote hosts you can set up a rsync service (rsyncd) and connect to your remote machine via something like:

rsync rsync://<Domain>/

The problem is: many sites have no password protection at all and are accessible by everyone with access to a console.

A quick search on ShodanHQ shows only a few hundred of the thousands of hosts out there with their shares publicly broadcasted, most of them with no password protection.

3. Oh noes! what to do?

Simple: Use rsync over SSH.

Rsync offers the option of using rsync over SSH, protocol that offers lots of possibilities for encryption (please use SSH v2.0 and, if you can, public keys). The usage kinda goes like this:

rsync -avz -e ssh user@host:/remoteDir /localDir/

Here is a quick explanation of the code above

So, that's it! I hope you've learned something today, remember to secure your shares!

More info:

• Official Website
• Arch Wiki
• Rsync man page
• Wikipedia

Why are mobile networks 'cellular'?

Everybody is familiar with the word 'cellular'. But, how many of you can actually explain what a cellular system is? And most importantly, can you explain why all mobile technologies are structured this way? In this first post I will try to enlighten you about this topic as a basis for future posts in which I will deal with topics that require a deep understanding of mobile communications.

Mobile technologies, no matter the generation, use the air interface as their transmission medium. More specifically, it is the electromagnetic spectrum what is used to transmit modulated waves containing information. Since electromagnetic spectrum is a very limited resource, and only a little portion of it is reserved for mobile communications, it is necessary to implement some sort of multiplexing in order to maximize the number of simultaneous users. To achieve this, the transmission bands are divided into channels.

GSM bands.

For example, in GSM-900, transmissions can only take place between 890-915 MHz for the uplink, and 935-960 MHz for the downlink. Each of these bands is divided into channels of 200 KHz width. This would only allow 124 concurrent users in the network, which obviously is not enough. This number can be increased by applying time multiplexing (just dividing each frequency channel into time slots), but the result is still far from optimal.

Additionally, it has been said that the channels are 200 KHz width, and this is not strictly true. The fact is that 99% percent of the transmitted power is contained inside a 250 KHz width band. Since the actual channel spacing is 200 KHz, two adjacent GSM channels interfere with each other, making impossible to use these two channels simultaneously. It is pretty obvious this system is not efficient at all.

Public mobile networks must be able to provide service to a large number of users. To cope with the before mentioned problems, a cellular scheme is adopted. This architecture involves dividing the total coverage area of the network into smaller regions or 'cells', each of which is assigned a set of non-adjacent transmission channels different from the ones assigned to neighboring regions. Each cell is controlled by a network entity (i.e BTS for 2G, NodeB for 3G) which is responsible for managing the cell resources.

The main advantage of using a cellular system is the frequency reuse. For a given coverage area, two or more sufficiently separated cells can operate in the same channels without interference. This sort of 'spatial multiplexing' drastically improves the performance of the network, allowing multiple users to share the same resources at the same time. Normally, cells are grouped into clusters, which are frequency distribution patterns that are replicated all over the total coverage area of the network.

7-cell clusters. f_i denotes a set of frequencies.

The minimum reuse distance depends on the cell radius and the number of cells per cluster, which typically is 4, 7, 12 or 21. This is a key factor, because the smaller the number of cells per cluster is, the bigger the cell capacity becomes, since there are more channels per cell. On the other hand, smaller clusters are more susceptible to suffer interference from neighboring clusters, so the size has to be balanced.

Cells can be classified regarding to the extension of their coverage area. Macrocells, for example, provide service to large rural areas, while microcells, picocells and femtocells are common in densely populated urban environments.

As a first approach to cellular telephony, this is all for now. In the next post I will focus on the cell concept, explaining its elements, and the logical network divisions derived from it.  

Welcome everyone!

Hi all!

So, here we are, finally writing our first, proper (this doesn't count) post!

Even though I'm the one typing, I'd like to present the entire team, mainly because they don't want to write this post and are too busy preparing their awesome first posts. Enough babbling, who are you people and what do you want?

Alessandro

Alessandro is our computer scientist, as of today he has finished his degree and is studying a masters degree in Computer/Network security.

Cristóbal

Cristóbal is our true telecommunication engineer (he chose the main branch, antennas and that kind of witchcraft). He came to us from the cold North Oviedo and currently he is finishing his studies (but he's almost done!).

Juanlu

That will be me. I am finishing my telecommunications degree in Telematics engineering in Madrid, and I plan on doing the exact same masters degree Alessandro is doing.

So, what's your story? why the blog?

We created this blog to learn and post about the fields we are specialized on. Alessandro will mainly deal with security, Cristóbal will be responsible for the telecommunication stuff, and I'll show you how magical the networks can be. Our intention is to publish, at least, a couple of posts per week, and the first one is coming soon so... stay tuned!

Hello World

Hello World' OR ''='' -- '