Reading time : Less than an hour
It has been more than a week since the Malaysian Airline Flight-370 has been missing after its successful take off from a Malaysian airport. I have been closely researching on the topic since it came as a shocking news to me as well as I was amazed how modern technology is limited when it comes to situations like these. The aircraft was a passenger jet boarded with 239 people including crew and pilots, and it was an ER series (stands for Extended Range) Boeing 777 which is usually used in 9/11 kind of attacks. I live in India and one US diplomat speculated that the same flight could have been hijacked to execute an attack similar to 9/11 in an Indian city. I’m trying to analyse as much information as available to see what could have happened to the air plane and a set of events happened in the past 10 days.
The aircraft went into the missing status on 8th of March 2014. It was a very normal international flight from Malaysia to China registered as 9M-MRO and marked as Flight-370 enroute Kuala Lumpur to Beijing. The airlines issued a statement exactly after 5 hours 56 minutes from the last contact with the airplane. Speculation have been raising ever since the missing plane could have been actually subjected to hijack, sabotage, pilot suicide or even a technical error that crashed the plane into some deeper region of the surrounding sea area.
To get a better picture about the missing, the initial event timeline needs to be studied deeply. The missing aircraft is a Boeing 777, a total of 1178 of them are produced and is under operation as of February 2014. The particular variant registered as 9M-MRO was a 777-200ER, which is an extended range version of the 777-200 base model. There are 412 (or more) 777-200ERs in fully functional airline operations out of 422 total deliveries. This particular variant 200ER can fly 4605 kilometres more than the base model and has more take of weight capacity. One thing to be noted here is that, in general cases, ER series aircrafts has larger fuel tanks. Among four aircrafts used in 9/11 attacks, two aircrafts which took down the twin towers of world trade centre was ERs. Since they can carry more fuel, the more damage it can cause to the target by the aviation oil burning.
This doesn’t mean that the aircraft could actually have hijacked for an attack similar to 9/11, but considering it as a possible option for someone so inclined to do so. On the other hand, this aircraft cannot be considered as a state of the art machine in terms os security. There were three total loss (hull loss) happened to the Boeing 777 series aircraft, where all three of them happened to 777-200ER. That is around 0.7% percent of 777-200ERs were involved in hull loss accidents. So it could be an accident which happened in a remote and yet-to-uncover location inside the circle with 14000 kilometres radius.
Why it is wise to rule out a crash possibility?
Again, most search operations relies on the possibility of a crash landing, and most of them believes the crash happened in sea, and they are looking for debris in the Malacca Strait on the initial stages of the search. Infact, there is an equipment that is fitted on most commercial aircrafts, that is an Emergency Locator Transmitter (ELT). Again, the ELT on the MA370 was made by Honeywell, and is highly reprogrammable. Designed to provide emergency transmission for aircraft flying over land, Honeywell’s RESCU 406® AFN Emergency Locator Transmitter (ELT) automatically transmits a digitally encoded signal upon impact in the event of a crash. As per their documentation, this device has triple frequency transmitter (121.5/243/406.028 MHz) and 50 hours of battery life. It works independent of the other subsystems. It also has a USA Federal Aviation Administration (FAA) certification. It is a quite reliable device, and it is affirmative to think that, if the plane has crashed, this equipment would have actually worked. Since, there was no pick ups reported for these signals, it could be either that the plane has not yet crashed, or the search squad has failed to pick up the signal.
Before getting deep into the actual missing event of the flight, it is worth checking how an aircraft is generally tracked and what happened with Flight-370.
The location tracking and Identification process
GPS systems as we see on our mobile phones are generally not used in ground controls due to different security reasons. Indeed, there is an onboard GPS device which can obtain its own location by contacting GPS satellites. This information is available to a pilot and is typically handed over to any request parties such as Air traffic control operators. To fully understand this concept, it should be learned how ATCs work. Air traffic control centres are operated associated to every airport in the world. Its primary job is to make use of the limited number of runways and airstrips to be allotted to various aircrafts that intents to land in the airport or leave the same. Also, it has to avoid collision between aircrafts both on the ground as well as mid-air. To do this, ATC operated two types of RADARS. First is the primary RADAR or the classic RADAR which picks up reflections of signals it emits, from any flying objects. It could be aircrafts, balloons, birds or even UFOs. Primary RADARs does not require permission from the tracked object to identify its presence. The associated system is a secondary RADAR, which acts in the following pattern.
The aircraft registration is usually kept live in the ATC till the aircraft enters another ATC records. It is quite obvious from the above step that, the transponders are key components in this procedure.
Modern day aviation transponders are made by companies like Honeywell, Garmin etc. Also most aircrafts have backups for mission critical electronic systems such as these. These equipments are fairly tamper proof and highly sophisticated. Transponders are programmed when aircrafts are purchased and registered. A flight registration number such as 9M-MRO is embedded into the transponders and then it gets attached an aircraft. So there are two possibilities to compromise a transponder.
These two option leaves potential hijackers possible yet difficult opportunities to fake an aircraft as another similar one, by completely fooling the experts at any ATC. We have multiple sources informing that 20 engineers from Freescale, an embedded MCU manufacturers from USA, and an IBM employee, were also travelling on Flight-370. Also, here is a news from Freescale’s website suggesting that they have aviation contracts with Honeywell. Although we don’t have clear idea about what exactly were the job titles of these engineers from Freescale, we have a strong trace to work with.
ACARS is another tamper proof and reliable data link system used between an Aircraft and a ground station like ATC. It can send short messages to any requesting stations through radio or satellite channels. ACARS also sends information such as Aircraft maintenance data, generally relayed to the aircraft maintenance agencies, and also weather or delay information to the ATCs. In case of Flight-370, ACARS was turned off 14 minutes before the Transponder suggesting that, these systems were not actually damaged in a sudden emergency. There are four software modules in any ACARS.
The first component is required by the aircraft to complete the system. That means, if the Airborne client on the plane is compromised by a hacker or an engineer, it could stop working leaving the entire ACARS system useless. Although these devices are tested against general ruggedness, I’m personally not sure how deep the software security checks are done. ACARS are generally built by a company named SITA. Their systems are highly software based and generally known good and obviously they are market leaders.
There are three associated events that is known to have happened during the first two hours of flight.
Both the 2nd and 3rd event suggest that the aircraft was subjected to some sort of deliberate actions. It is unclear that if this was due to any external triggers such as to avoid a cumulonimbus or to avoid any potential threats ahead, but still, these are very unlikely to happen. There is another point to note down here. The Pilots extensively makes use of the Autopilot in cruising altitudes. To gain manual control, the pilot has to ask permission from ATCs because there might be other aircrafts using a nearby altitude. Neither of these events ware known to have happened in case of MA370. Thus there is a plausible situation that could have happened to the aircraft.
The aircraft would have been under control of a human onboard, who doesn’t wanted to talk to a ground control station.
The second event, a violent change in altitude, is worth studying in detail. At higher altitudes, aircraft cabins are pressurised by the onboard cooling system since the availability of oxygen at higher altitudes is comparatively less. At a cursing altitude, that is 32000 - 43000 feet, there is significant difference of 50% in oxygen availability. Thus in most aircrafts, at 40000 feet, oxygen masks are dropped if the cabin is not pressurised. On a rapid ascent to this heights could leave every single passenger with enough time to catch a mask, or even contact someone on the ground to let know of the situation. But there is another possibility. Suppose the pressurisation was not working from take off itself, a risk of possible hypoxia kicks in. The below image shows a mechanical pressure valve left open on an aircraft before take off. If it is kept the same while flying, the pilot would be getting an alarm when he tries to cruise.
When a human body is subjected to a breathing condition where the oxygen availability is comparatively less, then a medical situation called hypoxia arises. Hypoxia is a critical problem since at this situation, people tend to forget things that they have even learned very well. That means, if the passengers were subjected to hypoxia, then they would have even forget how to use an oxygen mask, or even how to use their mobile phones. So imagine the situation where you have your mobile phone in your hands, and you see something very unusual, yet, you don’t know how to dial your relatives or a friend to let know of the situation. Very disturbing it is. In air crash history, the Helios Airlines Flight 522 was subjected to such a situation where all the passengers and crew knocked out by hypoxia. The aircraft crashed when it ran out of fuel.
So a possible theory based on these information goes like the following. It could be completely wrong and is based on information available all over the media and the web.
Limitations of RADAR Systems
Secondary RADARs are generally used by ATCs. It has very less coverage and usually a few kilometres around airstrips. Primary radars are used by military agencies. Primary radar installations are there in many known and unknown locations across the globe and many countries executes continuos monitoring of the same. Although, primary RADARs has to have the aircraft to be in higher altitudes since the coverage of primary RADARs are in shape of a cone opening upwards. At altitudes as lower as 5000, it is quite possible to fly undetected on primary RADARs. In aircraft history, there is a very good example of making use of the same trick.
Operation Entebbe and Capabilities of Military Radars.
In Operation Entebbe, the Israelis had to fly to Uganda which is pretty much far away from Tel Aviv, to execute a rescue mission for its 92 citizens. To reach Uganda, they had to fly over the airspace of nearly 8 countries. Also, they had to use Lockheed C-130s, to move big cargo and ground militia of approximately 100 commandos, to execute the rescue mission successfully. C-130s are bulky and heavy as well as it leaves large RADAR signatures. Also there were four of them to be flown to Uganda to carry out this mission. So their only option was to hide from the military RADARs of all these countries. To do this, they did a wonderful job. They flew over these countries at an altitude, as low as 2000 feet. They had to spend a lot of fuel to do this, that they even had to make a refuelling agreement with Kenya after the rescue mission when flying back to Israel. But, this proves that, flying low can keep you out of RADARS in general.
In case of MA370, for those who know it is possible to fly skipping the RADARs, it would be a viable option to execute such a manure. Fuel loss is a necessary risk, although it is quite possible to re-enter the airspace while faking as another Aircraft as described in this article.
The search is based on multiple tiny information available from different sources. There is a speculation that the aircraft could be crashed in some remote locations in the Indian ocean. Also, some suspects that it could have been hijacked to execute a 9/11 model attack in an India city. And afterall, many experts suspects that it could be the first cyber attack ever reported to have happened to an aircraft.
There are many countries participating in the search. But there were reports that, most of them operates independently due to security reasons, and the unwillingness to share technical know-how with other countries. Thus it is not very wise to believe that the search operation is very efficient. Lets wait and see what turns out to be.
// Thanks for readinge
Reading time : Less than 30 minutes
Its been a while since I touched this blog, apologies first. And this is my third (perhaps fourth) mobile platform article in this blog. I have touched the following in the past,
And today, it is going to be iOS. The reason why it took a decade to touch the iPhone platform is that, the development tools offered by the parent company, that is Apple, is not so much cross platform. You need a Mac and a iDevice to develop applications for this platform. And of course, it is going to cost you a fortune. A proper Macbook Pro (ME866HN/A) and an iPhone 4S eaten up around $2800 from my wallet. But on the flip side of that, it is a good investment to make, at this point of time. Apart from the opportunity to build iOS applications, it gives you a very good laptop and a smartphone. Lets get to the actual topic now.
Apple did a wonderful job developing and packing a very good development tool called Xcode into a single unit. For those who come from other mobile platforms and IDEs, they are gonna feel like in heaven. Xcode can be used to develop apps for both the mac as well as the iOS. It also includes all the documentation required for both and all the device simulators like iPhone and iPad. So, it is a rugged, one click installation package, which brings you everything, to get started with the actual development.
Overview : What we are going to do in this post?
Create a New Project
Launch Xcode. It will be in your Applications folder if you have installed it from the App Store. And select Create New Xcode Project from the welcome screen. Xcode will now greet you with a template selection dialog. Obviously, select iOS > Application from the left pane, and select Single View Application, and press Next. This next window may seem a bit of overkill, so just fill it with what you see below.
Press Next and you will be asked where do you want to save your project to. Select some convenient location and press Save. You project will be presented as the following in the Xcode main window.
I’m not going into a lot about Xcode, you may find tons of info about it on the web. The left pane is the navigation pane, where you can select a file or resource from the project and the centre pane will be presenting you with the contents of the same. And you will find a very interesting file named Main.storyboard. In layman terms, this file contains the user interface for the application you intent to build. iOS architecture is MVC complaint, and the VC (View and Controller) part of it belongs to the storyboard file. Every screen in your application is roughly a view controller. And the transition between screens is generally called a segue.
Building a Small Calculator Application
When you click on the storyboard file, you will be presented with the visual user interface editor in the centre pane. And the right pane is split into two halves. The bottom half is called the library. You will see a small cube icon there, which is the object library, form where you can drag and drop UI elements into your storyboard. For building a calculator application, we need two text boxes and four buttons for representing each of the four arithmetic operations. Here is the UI I have built with my storyboard.
On the left, I have one label to display results as well (the text in it is set to 0.00 initially). You can adjust properties related to a particular UI element from the top half of the right pane. Select the text boxes one by one, and change Keyboard type from Default to Number Pad. Guess why we do this! :) It is worth the time to get yourself familiar with different tabs and panes in the Xcode application.
Now we have all the required UI, and what left is the code which drives the UI to derive the expected result. The coding part is not marly coding in Xcode. What we need from the UI is the actions, such as the button click for each of the buttons corresponds to each arithmetic operation. For doing that, we need to tap those events from our code. Since we have created a Single view application, there will be only one set of code files in our project folder. Which in my case ViewController.h and ViewController.m. There are another set of code files named AppDelegate.h and AppDelegate.m, which we don’t have to worry about, for now.
Discuss the Code
The linking of action from the UI to the code is an interesting task. As the first step, switch Xcode to the Assistant Editor mode. For doing this, click on the Assistant Editor button on the top right portion of the Xcode toolbar.
Now you have both the storyboard as well as ViewController.m visible in the centre pane. You will see two sections in the ViewController.m file. One is the @interface section and the other is @implemenation section. Now carefully select the first button from the storyboard, that is “Add”, and press control. Now keeping the control button pressed, drag it to the @implementation section in the ViewController.m file, and let go off the mouse. You will be presented with a small popup window that looks like what you see below. You might feel a bit strange doing this, or fail a couple of times doing this correctly, but this will feel quite comfortable after a while.
Enter the name for the function as addNumbers and press connect. You will see that a method stub appear in the ViewController.m file. Do the same for all the four buttons, resulting into four method stubs looks almost the same. My stub names are the following.
Now that we have all the action handlers. It is promised that when any of the four buttons are clicked, those events will be passed into these functions. But for doing the actual arithmetic operation, we need to read the values from the two text boxes we have. For doing that, we need references to the text boxes from the UI. Just as like we did for the buttons, click on each text boxes and Control+Drag it to the @interface section. Note that it is not the @implementation section like we did for buttons. Name each of the text boxes accordingly. Yet again, we also need references to the Result Label to print the results back to the UI. So Control+Drag the label to the @interface section as well. After dragging all three, my @interface section looks like the following.
@interface ViewController ()
@property (weak, nonatomic) IBOutlet UITextField *num_one;
@property (weak, nonatomic) IBOutlet UITextField *num_two;
@property (weak, nonatomic) IBOutlet UILabel *result_label;
Now, we are ready for coding. What we need to do is the following.
I have the complete code for your reference. Please note that, I have refactored it a little bit. I created a function which does all the arithmetic operations.
Running the Application on a Simulator
Now it is time to run the application. Press Command + R and Xcode will launch you an iPhone simulator by default. Here is the result screen.
Obviously, there will be an exception if you are trying perform a division, while the second number is zero. Exception handling and working with bugs in the application has a good deal of process to do with the inbuilt objective-C debugger, which is a very interesting topic. May be I can put up another post for that. This one is already getting too long
Thanks for reading // Happy hacking.
Reading time : Less than 30 minutes
Its been a while I was thinking to post an article about broadcast receivers. I have done a number of projects which makes extensive use of broadcast receivers. There are a number of use cases where broadcast receivers are highly usable as well. Lets see how broadcast receivers can be made use of in Android. In layman terms, broadcasts are like a message that is sent across the entire system. Anyone with the appropriate address and permission can read the broadcast-ed message. For the sake of simplicity, I’m dropping out the concept of permissions. Basically you can catch broadcasts using a Broadcast Receiver with correct address or action as called by Android guys :). The word address in the context of broadcast receivers refers to an Intent Filter, by means of which, anyone can receive broadcasts that comes under that filter. Lets start with Intent Filters. Intent Filters can be defined in your Android application in two ways.
Note, that you cannot typically use an Intent Filter defined in the manifest through any Java files or vice versa. Or atleast I don’t know if that is possible. Anyway, it is safe to say that, you can use Intent filters defined in your java files to create broadcast receivers that has an Activity scope, and you can use manifest based filters to create receivers that has the Application context. So it turns out that, you can create two types of broadcast receivers.
To enable a broadcast receiver, you need to register it per se. As explained above, you can register it for the entire application by registering it through the manifest file, or you can register it inside any activities you need to receive broadcasts. Before going into depths of the same, lets see how to send a simple broadcast.
Ok, there is a hell lot of variants for the broadcast sending function. For now, lets check out the simplest one, that is sendBroadcast(Intent intent). This method takes an intent as the parameter. Lets see how this can used in a typical condition.
This is simple huh? It sends a simple broadcast with an action string ACTION_HELLO as the so called address. This simply means that, any broadcast receiver with intent filter set to ACTION_HELLO can receive this broadcast. Lets create such a broadcast receiver.
Ok, it still doesn’t says what intent filter this receive is planning to use. So we have to enable or register this broadcast receiver to do that. As we have seen earlier, we can register it for the entire application or we can register it for just one activity. For registering it for the entire application, you need to add the corresponding entry into the manifest, inside the <application> tag.
And for doing the same inside an activity, you can do it simply as follows. Remember, this particular receiver will work only if the activity is visible and it cannot receive any broadcasts if the activity is not in the foreground.
Ok, this part needs a little bit of explanation. We may simply register this receiver in the onCreate() itself. But in that case, there is a risk of leaking memory if the activity is killed or has moved to the background. To avoid this, I register the receiver inside the onResume() and safely unregister the same from inside the onPause(). As you might know, onPause() will be triggered when the activity is about to go to the background. A complete sample project is available here for downloading and testing out broadcast receivers.