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