Docstoc

Viber Communication Security - Bad Request

Document Sample
Viber Communication Security - Bad Request Powered By Docstoc
					              Viber Communication Security
                               unscramble the scrambled




    Michiel Appelman                                           michiel.appelman@os3.nl
    Jeffrey Bosma                                                  jeffrey.bosma@os3.nl
    Gerrie Veerman                                               gerrie.veerman@os3.nl




                                            Abstract

     In the past couple of years more and more communications which used to use the regular
mobile operator networks started moving towards ip-based networks. This has given rise to
‘apps’ on smartphones that enable consumers to connect to each other without the use of their
mobile operator. More recently the security implications of switching from the closed network
of the operator to the open Internet have become apparent after some ‘apps’ have shown severe
weaknesses. In this project we will take a look at one app in particular: Viber, a voip application
used on cellphones. The report tries to answer the question how Viber performs — security-wise
— in comparison to other services. A definitive conclusion has not been found but most details
of the protocol used to transfer the voice data have been documented. The application code has
been analyzed but no real weaknesses were found. This lack of weaknesses found doesn’t mean
that the app is secure, due to limited time and experience of the authors a lot of investigation is
still to be done.




                                      December 24, 2011
Contents

1 Introduction                                                                                             1
  1.1   Viber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    1
  1.2   Why focus on Viber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .         1
  1.3   Viber policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     1
  1.4   Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       2

2 Preliminary Research                                                                                    4
  2.1   Other Services    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    4
  2.2   Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .        9

3 Experiments                                                                                             12
  3.1   Local Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     12
  3.2   Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       17
  3.3   Application Code Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       25
  3.4   Other Weaknesses      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   33

4 Conclusion                                                                                              35
  4.1   Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   35
  4.2   Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      35
  4.3   Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     36

Appendices                                                                                                37

A Acronyms                                                                                                37

B Bibliography                                                                                            38

C Log                                                                                                     40




                                                     i
Introduction                                                                                 Chapter   1

1     Introduction

1.1   Viber

Viber is a communication application for mobile phones. The current version works on Android and
iOS devices. You are able to call, send text messages, photos or your current Global Position System
(gps) location. Reviews predict this can be a real competitor to Skype, this because of the simplicity
that Viber offers.[1] It can be used free of charge and no registration is needed, only your phone
number is required. Viber states to be freemium which means offering free services with one app
and having a paid app with more attributes and possibilities. Since it is a relative new application
we would like to see what kind of security implementations Viber has made. This since privacy and
security became an important issue regarding communication.


1.2   Why focus on Viber

There is virtually no research done in the field of Viber and their security. An extensive search
on the internet resulted in only a few vague statements from a spokesperson of Viber. This was
intriguing and made us very sceptical, because of the amount of information that could be found.
The openness about security implementation and the clarity on matters of the spokesperson stating
these claims is very dubious to say the least. The findings about the security implementations in
Viber, or their absence, are quoted below. Talmon Marco is an online spokesperson for Viber and
answered a few questions asked by consumers. About encryption of messages he replied as follows:

      They were not in the very first version, but they are now.[2]

When asked about the encryption of calls:

      To be honest, since our code is not open source, we cannot claim ‘encryption’ as it is
      not open to outside scrutiny. The most we can say is that ‘it is scrambled’ (and in our
      opinion the same applies to anybody who does not have an open source technology. So,
      Viber messages are scrambled.[3]

We want to look closer into the security of Viber since it’s a relative new application and see if it
has any dangerous security flaws. More information about why this research is done can be found
in the project proposal.[4]


1.3   Viber policy

It is always interesting to look into applications their policy. To see how they describe to protect your
data and how they handle your data. Sometimes data gets stored by the services other applications
remove the data when it is being delivered. Those policies also differ per country, different kind of
rules and laws are present. Let’s have a look on what Viber claims to do. Their information and
data protection policy:

                                                   1
Introduction                                                                              Chapter   1

      We do not rent, sell, or share any information about the user with any third-parties.
      We may disclose your Personal Information if we believe such action is necessary to: (a)
      comply with the law, or legal process served on us; (b) protect and defend our rights or
      property (including the enforcement of our agreements); or (c) act in urgent circumstances
      to protect the personal safety of users of our services or members of the public.[5]

      We take reasonable precaution to protect Personal Information from misuse, loss and
      unauthorized access. Although we cannot guarantee that Personal Information will not be
      subject to unauthorized access, we have physical, electronic, and procedural safeguards in
      place to protect Personal Information. Personal Information is stored on our servers and
      protected by secured networks to which access is limited to a few authorized employees
      and personnel. However, no method of transmission over the Internet, or method of
      electronic storage, is 100% secure.[5]

What they say about their encryption policy:

      Some companies in our field claim that they encrypt their traffic. They do so while using
      proprietary technologies, not open to external scrutiny. We believe that unless you use
      open technologies, you should not claim that you use encryption. At Viber, we believe
      in being 100% truthful to our users. This applies to everything we do and even more
      so when it comes to matters of security and encryption. Since Viber uses proprietary
      technologies, we believe we cannot claim that Viber is truly encrypted and as such, unlike
      some companies in our field, we do not claim that we are encrypted. We leave the decision
      of how to use our service and whether to trust its security to our users.[6]

As you can read Viber claims to secure your data. But they can’t promise you this for 100%. They
also have to obey laws and legal processes and may share your personal information. However it
claims not to be encrypted because it uses proprietary technology. Let’s find out if Viber can be
trusted in their security mechanisms or not.


1.4   Research Questions

After these interesting facts the focus of research was set to find out how secure the app Viber
actually is and the main research question is:

      How secure is communication through the Viber application in comparison to other voip
      services?

The research is also split up in two areas with several subquestions. The first will span the local
storage of Viber with the following questions:

   • What information is stored by Viber, and in what form?

                                                  2
Introduction                                                                             Chapter   1

   • How does Viber for iPhone differ from the implementation on Android?

   • Are Viber messages stored encrypted/scrambled? If yes, what kind of encryption is used?
     How prone is it to currently known attacks? What about photos, and transmitted location
     information?

The second area which will be researched is the data that is actually being sent over the wire:

   • How are Viber messages send, are they encrypted/scrambled?

   • Can one modify the content, the recipient address, or the sender address of a message?

   • What other kind of flaws are present in the protocol, and how can they be improved?




                                                 3
Preliminary Research                                                                       Chapter   2

2     Preliminary Research

2.1     Other Services

This chapter will focus on mobile communication services and their security. Some different services
will be looked into. What exploits have been found in those applications and is it possible to maybe
reproduce those attacks.


2.1.1    Communication Risks

Many of the services that are in use today already existed before the mobile-phone platform became
huge. It shouldn’t surprise you that those services who already were built for Voice over ip (voip)
software on desktops or voip phones now also build them for mobile-phones. This was not only a
way to expand some company their business, but also a great moment for new competitors to join
the competition in becoming a big player in mobile communication.
The main reason people use those services is for today-to-today communication. Normally normal
users don’t see any problems in using those services. Until a security exploit is found in one of them
and gets leaked/published into the media. Then users suddenly are aware that it is maybe possible
someone saw their messages or captured their voip communication. Security is always a big issue
regarding communication. Most communications that take place are not meant for everyone. You can
suspect you don’t want a third person or party reading them. Now that mobiles are used everywhere
it becomes increasingly worse, users connect their phones to unsecure or untrusted environments,
this without knowing the dangers of it. Applications usually automatically login over those unsecure
channels. Mobile users don’t have any clue what security risks or dangers this can bring for their
privacy. Some of the information that can be gain can be worth a lot for a random hacker or sniffer
on those networks. But not only have those networks formed a risk. Think about your Internet
Service Provider (isp) who forwards all of your traffic, they can capture your data without you even
knowing it. This is why you want your data to be secure.
Developers of those mobile applications are of course also aware of those security flaws, well hopefully
at least. But implementing those security mechanism isn’t always as easy as said. Besides this their
main product/activity is making sure their communication channels are fast and robust. But when
developers implement security mechanism in their service it becomes slower and more complex. Also
hackers know this and search for even more complex ways of breaking it or finding an exploit in a
different angle. All this just too gain mobile users their private information and data.
A problem for securing voip services is that it uses User Datagram Protocol (udp) for the transport
level communication. This to make sure packets arrive in relative ‘real-time’ on the other side. This
is quite important since you want you connection for voice communication as fast as possible. You
don’t want users to have jittering communication channels. Security only adds extra steps which
most likely will slow down this communication service. However some people do care about security
while others don’t.




                                                  4
Preliminary Research                                                                       Chapter   2

2.1.2     Differences

There are already many mobile communication applications on the market. You can distinguish
them into two groups. Some of the most famous ones will be looked into later in this chapter. The
first one only can send messages, applications like this are Whatsapp, Ping and eBuddy XMS. The
other one are those that can send messages and besides this can call over voip communication,
applications in this group are Skype, Nimbuzz and Viber which this document will be concentrating
on.
Most of the applications mentioned above were not secure in the first version. As you would know
by now that’s because they focus on their communication service first. You can say that’s their main
‘product’. When time passed more users began using these applications and security became more
of an issue. That’s why in later versions security got implemented. You can already guess that some
of those applications do this better than others. Below you can read about the different security
issues of those applications. What exploits and security issues have been discovered? If it’s known
what are their security mechanisms?
Analysing which application their security mechanism is more robust and secure can be a very
difficult subject. Because some of the applications say they are very ‘open’ it even says in some of
the policies. But when you look deeper into them they don’t say how it is secured or what kind of
mechanism or encryption there is being used. But on the other hand some other applications do say
what they are using. Also should be noted that some mobile communication applications have more
exploits then others. But this can maybe be because their popularity amongst users. For this reason
some can be more researched looked into then others. Looking at security can be a difficult task and
as Garfinkel would say ‘Security is not some abstract quality that can be analysed in isolation’.[7]
A paper from Marjalaakso formulates the functional and technical security requirements for a voip
communication.[8]

        Functional Security Requirements:

          1. Information exchanged among the participants of a call should be kept confidential,
             and access to such information should be impossible to any third party. Motivation
             for this clause is easy to see: without confidentiality, third parties may misuse the
             information which they were able to eavesdrop during a conversation.
          2. Only service provider should have access to statistical information and such infor-
             mation should be safeguarded against attacks from third parties. Who would like
             to get cought from calling to sex or escort service numbers?

        Technical Security Requirements: Security requirements, which should be met and fully
        supported by any voip protocol to be considered as, secure, are summarized in the list
        below:

          1. All connections between network elements should be encrypted;
          2. The endpoints of all connections should always be authenticated in two-ways to
             prevent man-in-the middle attacks;

                                                   5
Preliminary Research                                                                          Chapter   2

          3. End-to-end user authentication should be provided at terminal devices; and
          4. Both clients and servers should be protected against Denial of Service type of at-
             tacks.

        The list could be continued with many other detailed requirements but the above list
        provides sufficient requirements for the analysis of security constraints in the next section.


2.1.3     Whatsapp

Whatsapp is one of the most used communication application for mobile messaging. Whatsapp
had some pretty bad security issues. A review from around May 2011 announced the following.[9]
Messages where send unencrypted over the network and everyone who wanted could read them. If
you think this is all your wrong, besides this you were able to hijack other users their account and
receive their messages or send messages as them.
With the latest Whatsapp version when sending messages you’re still able to see the following: “(1)
the number the message is going to, and (2) the contact name is still send in plaintext”.[10] It should
also still be able to steal other people their accounts through SMS-spoofing, a detailed explanation
by Ricky Gevers.[11] How exactly the messages are encrypted is unclear in their policy:

        Whatsapp uses commercially reasonable physical, managerial, and technical safeguards
        to preserve the integrity and security of your personal information. We cannot, however,
        ensure or warrant the security of any information you transmit to Whatsapp and you do
        so at your own risk.[12]

If you read their policy you can notice their a little scared about reverse-engineering. Here is a short
sentence in their policy:

        We do disallow any efforts to reverse-engineer our system, our protocols, or explore
        outside the boundaries of the normal requests made by WhatsApp clients.[12]

This last sentence does sound a bit inviting to hackers and sort. Even after some security breaches
it’s still possible to see who calls or sends messages to whom in plaintext. The content however is
‘secure’. But you are still able to count the amount of data flowing between mobile numbers/persons.
What is the reason about not encrypting everything?


2.1.4     eBuddy XMS

eBuddy is a well know communication service that integrates different Instant Message (im) services
in a web browser. For mobile phones they launched their own service called eBuddy XMS. eBuddy
XMS is relative new application on the market for mobile messaging. It has a build-in function
to enable and disable encryption. This because encrypting takes more time to deliver and receive

                                                     6
Preliminary Research                                                                        Chapter   2

messages. Encrypting and decrypting of messages takes more time and end-users in general only
care attention to the speed messages are send/received. Since eBuddy XMS is relative new there are
not many to none security flaws/reviews. eBuddy says to be secure, they say the following about
their encryption:

        To be exact, the method to secure it is Transport Layer Security (tls) 1.0, using a 2048
        bit encryption key. This is considered to be highly secure.[13]

They also say the following about their build-in security function:

        Not using the secure connection does not necessarily mean that all data is unsecured.
        Authentication and uploading your address book is always secured even when you are
        not using the secure connection. So, no one can hijack your account or your address
        book. Not using the secure connection only affects sending and receiving messages.[13]

In their own policy they say the following about users their data security:

        eBuddy will take reasonable technical and organizational measures to protect the infor-
        mation we collect against loss, misuse or any form of unlawful processing. Information
        on eBuddy servers is stored in a secured manner and access is limited to authorized em-
        ployees only. However, it is important to note that we cannot eliminate all security risks
        associated with data transmission and storage.[14]

eBuddy claims to be ‘highly secure’ with their encryption. However no review or media articles
can been found about this. They also claim not storing your data and even encrypting important
information if the security option is off.


2.1.5     Skype

Skype always has been the big player for voip calling this isn’t any different for mobile devices.
Because it’s one of the most used ones you can expect it’s reviewed a lot. That’s why Skype already
was in the media quitted a lot for some security flaws. Some which are even recent. It was possible
to see from where a Skype connection came from.[15][16] On iOS it was possible to steal people their
information, like your address book.[17]
Skype hired a security expert who made a review in 2005 about Skype their security. In this review
is written that Skype is quitted secure, but unclear if this also reflexes to their mobile platform. The
review says the following:

        Skype claims that its system uses the Ron Rivest, Adi Shamir and Leonard Adle-
        man (rsa) encryption algorithm for key exchange and 256-bit Advanced Encryption
        Standard (aes) as its bulk encryption algorithm. However, Skype does not publish its

                                                    7
Preliminary Research                                                                      Chapter   2

     key exchange algorithm or its over-the-wire protocol and, despite repeated requests, re-
     fused to explain the underlying design of its certificates, is authentication system, or its
     encryption implementation. Therefore it is impossible to validate the company’s claims
     regarding encryption. It is entirely possible that the data is both encrypted and not
     secure.[7]

Their policy says the following about your personal information:

     Skype will take appropriate organizational and technical measures to protect the personal
     data and traffic data provided to it or collected by it with due observance of the applicable
     obligations and exceptions under the relevant legislation. Your personal and traffic data
     can only be accessed by authorized employees of Microsoft or its affiliates, subsidiaries or
     service providers who need to have access to this data in order to be able to fulfill their
     given duties.[18]

This same policy says it may or may not store information about you. Because of this you can
concluded they will store anything they know about you. They also say that:

     Skype will retain your information for as long as is necessary to: (1) fulfill any of the
     Purposes (as defined in article 3 of this Privacy Policy) or (2) comply with applicable
     legislation, regulatory requests and relevant orders from competent courts.[18]

Regarding your personal data and information they say the following:

     Except as provided below, Skype will not sell, rent, trade or otherwise transfer any
     personal and/or traffic data or communications content outside of Microsoft and its
     controlled subsidiaries and affiliates without your explicit permission, unless it is obliged
     to do so under applicable laws or by order of the competent authorities. Please note
     that information that you voluntarily make public in your user profile, or which you
     disclose on forums, discussions boards or by posting comments will be publicly available
     and viewable by others. Skype may disclose personal information to respond to legal
     requirements, exercise our legal rights or defend against legal claims, to protect Skype’s
     interests, fight against fraud and to enforce our policies or to protect anyone’s rights,
     property, or safety.[18]

Skype is very strict in keeping their security mechanism to the company. The review claims that
Skype their platform is secure. But can this also be said about their mobile platform since it’s new?
Skype should be secure since it’s used a lot. Not only for normal users but it’s famous amongst
corporate businesses also. But as could be read they still had some security flaws in their system to
gain your address-book for example.



                                                 8
Preliminary Research                                                                         Chapter   2

2.1.6     Nimbuzz

Nimbuzz is a communication application for calling and integrating different im services. They
are based in the Netherlands the same as eBuddy. They have some blogs and posted about how
they think about security: ‘We want to assure you that privacy and security is the top priority for
Nimbuzz’.[19] They also inform users a lot on how they can assure user their own information and
data is secure.[20]
However Nimbuzz got hacked by Anonymous in July this year. They had full access of their network
and data.[21] Although the company claimed this wasn’t the corporate environment and users their
account information and data wasn’t in danger.[22] Besides this not much information can be found
about the security of Nimbuzz.
Their policy says the following regarding data security and private information:

        Nimbuzz takes appropriate organizational and technical measures to protect the personal
        information and communications data provided to them or collected by them. For exam-
        ple, your personal and communications data can only be accessed by authorized Nimbuzz
        staff that need to have access to this data in order for their work. Nimbuzz takes technical
        measures to protect the confidentiality of the content of communications sent over the
        Nimbuzz Services, subject to all applicable obligations and exceptions under applicable
        law.[23]

        Nimbuzz does not sell, rent, trade or otherwise transfer any personal information, com-
        munications data or communications content to any third party without your express
        permission (unless it is obliged to do so under applicable laws or by order of the compe-
        tent authorities) except as set out in this Statement.[23]

Nimbuzz wants to inform their users how security can be guaranteed for example how their password
should look like and what they should and shouldn’t do. They got hacked once but this doesn’t say
that their communication service is insecure. They claim to protect your data very well and should
only be possible to view inside Nimbuzz their company.


2.2     Reverse Engineering

Most protocols in use today are defined according to publicly available standards. Some developers
though, choose to keep their implementation to themselves as to keep others out. This ‘security
by obscurity’ idea is the complete opposite of the Kerckhoffs’s principle which states that a system
should be secure even if anything about the system (except the key) is publicly known. The reason
for this is that eventually people with enough knowledge, materials and time will figure out how it
works and might also find weaknesses the inventor did not think of. This process is called ‘reverse
engineering’ and is used in the it-world to get to know how a program, file or network protocol is
constructed.


                                                    9
Preliminary Research                                                                     Chapter   2

One of the most well-known reverse engineering projects is the Samba-project. It was started in 1992
by Andrew Tridgell in effort to make allow ms-dos clients to access files on a Sun Microsystems server.
The name is derived from the Microsoft-developed protocol it tried to dissect: the Server Message
Block (smb) protocol (also known as cifs).


2.2.1     Techniques

To explain the process Tridgell (also known as the co-write of rsync) describes it as learning French
without the use of any books or courses. One approach may be to just sit down in a French cafe
and listening to what people are ordering. If you do this long enough you soon will know the words
for ‘coffee’ and ‘bread’ and may even be able to call the waiter and order yourself. Tridgell used
some other techniques (and a lot of time) before he was able to build his own Samba ‘French waiter’
which would respond just like a real smb-server.[24]

Documentation
Although the reason for reverse engineering is the lack of documentation, there might be some earlier
work available on which the implementation is based. Tridgell found some old documents sent to the
Internet Engineering Task Force (ietf) in which Microsoft was applying cifs to become a standard.
The draft expired and Microsoft did not follow through with the standardisation process, but the
document was still available (although outdated).

Sniffing
The ‘French cafe’ anecdote can be seen as the explanation for sniffing. The engineer listens in on the
communication between two parties and tries to learn what both of them are saying. After that he
tries to talk to one of them directly and see what kind of responses he can get. This process takes a
very long time and a lot of scanning though large dumps of hexadecimal values.

Scanning
After some information about the semantics of the protocol has been gathered a protocol scanner
can be used to try all possible commands. It will try combinations of different options, flags, pay-
loads, etc. just to see how the other side will respond. This way new commands can be found which
normally aren’t exchanged between server and client.


There are a lot of other techniques and each developer has his own ways of reverse engineering. Rob
Savoye is famous for working on Gnash1 , an Open Source implementation of Adobe’s Flash. In 2009
he gave an interesting talk about his work on Adobe’s Real Time Messaging Protocol (rtmp) and
confirmed that reverse engineering requires a lot of patience and sifting through hex dumps, and
that he would put on some hardrock music and just stare at it for months.[25]
  1
      gnu Gnash – http://www.gnu.org/s/gnash/



                                                 10
Preliminary Research                                                                      Chapter   2

2.2.2   Analyzers

This fine art of reverse engineering is well respected within the Open Source community because of
the time it takes get to a working implementation. There have also been some attempts to automate
this process.

Protocol Informatics Project
The first and one of the more documented tools is the Protocol Informatics Project. Written by
Marshall Meddoe, it is based on algorithms found in bioinformatics.[26] It looks for relationships
between sequences in the data of the packets in the same way researchers would look for relationships
between sequences of genetic information in dna.
To map these sequences and their relations a phylogenetic tree is build, this is an evolutionary tree
that shows differences as time goes on. Network protocol packets also ‘evolve’ in the sense that the
information in their headers is constantly changing. After it has created a ptree it will try to align
fields with common information and thus come up with a packet structure.
This tool is a bit outdated (2004) but can still be useful in some cases, mostly with small binary
protocols or text-based implementations. If there is a lot of zeroed data, it can get a bit confused
though.

Discoverer
Discoverer is a tool which is much less documented and is even less usable. It was developed by
Microsoft employees and unfortunately has not been released. The paper is an interesting read,
though as the procedures are pretty basic and can come up with some decent results.[27]
The tool consists of three steps. The first step tries to find the field boundaries in the packets (to-
kenization) and sorts them based on those characteristics initial clustering. Because similar looking
structures in packets do not mean the packets are of the same kind, another round of clustering is
performed (recursive clustering). After this second step messages of the same or similar kind may
be spread over multiple clusters and the last phase uses a sequence alignment algorithm to group,
and finally merge them to get a definite message pattern.


There are also some tools that aren’t really automated protocol reverse engineering but can be a
huge help to the developer. These allow for differences in messages to be automatically found but
leave the specification up to the developer.[28] Eventually all developers of these tools will explain
that although their programs can be a huge help, there will still be a lot of manual research to be
done. Some pattern recognition logic just isn’t easily implemented in software.[29]




                                                 11
Experiments                                                                               Chapter   3

3     Experiments

In this chapter different approaches are documented which were used to try and reveal any weaknesses
in the application.


3.1     Local Storage

For a mobile communication application it is not only important to secure data which is send or
received from your phone. But also what kind information gets stored and kept on it. Suppose your
phone gets stolen or lost, what may other people retrieve or find on it? In this chapter will be looked
in the files that Viber stores on your phone. What information can be gained from it? Viber not
only uses a database but also uses some Extensible Markup Language (xml) files where it stores
data in.


3.1.1    Database

Viber uses a database to store different kind of information. Viber makes use of a so called SQLite
database for storing their data. The first thing that could be noticed was that everything was
unencrypted and you could access the database fairly easily, once you have access on a phone of
course. Since the implementation can differ between Operating System (os) we will look closer into
Android and iOS and then end with a short conclusion about what can be found.

iOS
It was easy to locate and access the SQLite database on an iOS phone. You only need to jailbreak your
phone. All data is stored into a single database. Only the important data that could be interesting
or important for this project is mentioned. The following information is stored in plaintext inside
the iOS database:

    • Your whole address-book (even non-Viber users)

    • Other address-book with Viber contacts (phone number and name)

    • All messages that have been send plus the current location

    • All calls made and received

    • A list with links to attachment (pictures)

    • Log file for missed and received calls

    • Your Viber user ID

    • A table which counts/summarise all above


                                                   12
Experiments                                                                                 Chapter   3

Android
On Android it’s almost the same to gain access to the files since your Android device also needs to
be rooted to get to them. But once you have done this you can get to the files, it was also quite
easy to locate them. Android has three SQLite databases stored one is called ‘viber_hashes’ which
sounded promising but unfortunately was empty. The other two did contain information one more
than the other. It contained globally the following information:

   • Contains call log information (who called you and did you call)

   • Address book of Viber contacts (phone number and name)

   • All messages send/received with location information and if data (pictures) linked to it

   • Every message has its own token

   • A table which counts message per user contact

   • A table which counts/summarises all above


3.1.2   Files

Viber not only stores data into database but also has some xml files. It also stores the pictures
send and received in a different location on your phone, which are of course possible to get without
rooting your phone.

iOS
Viber has only one xml file on iOS, this file is called ‘settings’ and contains the following information:

   • Your own phone number

   • Count of your Viber contacts

   • If you are registered or not

   • Messages received and send count

   • Version that is being used

   • Some hashes (You can guess that it’s the same as on android)




                                                  13
Experiments                                                                             Chapter   3

Android
In Android Viber has multiple xml files which all contain little information, in those xml files the
following can be found:

   • Viber account version number
   • A ‘dm_registration’ key number (used for the android market)
   • Your ‘device key’ (hash)
   • Last registered number (your own number)
   • Your Viber User ID (hash)
   • A ‘Sync hash’
   • Last message token ID
   • Last mist call log
   • Your activation code (the one you get through SMS)


3.1.3   Conclusion of Viber’s data stored

Is seems that everything you do with Viber gets stored inside a database. Viber makes use of the
SQLite database with some xml files for different kind of data. Both Android and iOS need to be
rooted and jailbreaked to gain access to them. All Viber databases and files are stored unencrypted
or could be said in normal plaintext. The data in the xml files is used for the configuration of
the application. The data inside the database look like log files and only stores messages plus your
address-book. Photos called attachments in the database are saved in a separated directory. But
there can be concluded that your Viber data is easily accessible on your phone both on Android and
iOS.

Database
The databases contain on both os’s all Viber contacts but on iOS also your normal address-book can
be found. All messages send and received are stored with tables for your location (if that function
is on). Both databases have a list of calls received and made. It’s also interesting that on Android
every message has his own token and sequence numbers attached to it while iOS only stores the
sequence numbers. Both databases contain a table with summaries on how many message are send
and calls are made. The iOS database also looks better organised than the one on Android. Android
has two more databases than iOS. Maybe they ‘viber_hashes’ database which also can be found
in Android was used in a previous version of Viber. Below you can compare how the messages are
stored in both databases:
You can see Android uses the token value while iOS doesn’t. Android further in the table also has
a sequence value which is being filled. But iOS on the other hand only has a sequence value filled

                                                14
     Experiments                                                                                                     Chapter    3




                                                        (a) Android Database




                                                         (b) iOS Database



     in, the token value stays zero. The tables in iOS link more to other tables as you can see this one
     contains lesser data/information then the one on Android.

     XML Files
     How though the databases contain some relevant information the most interesting data can be found
     inside the xml files. Those files contain configuration options. On iOS it isn’t really clear what some
     values are especially for the hashes stored it is unclear. Android however has clear attribute names
     saying what the value contains. See an example between iOS and android below:
     Android:
 1   < string name = " reg_viber_phone_num " > 063834 xxxx </ string >
 2   < string name = " viber_udid " >3 d d 7 b a 2 7 3 1 2 2 f 7 4 6 c 1 b d 3 7 c 4 c c 8 1 8 0 d 5 7 b 4 2 6 1 d 5 </ string >
 3   < string name = " pref_list_id " > ’ 421 ’ , ’ 367 ’ , ’ 1204 ’ , ’ 212 ’ , ’ 1841 ’ , ’ 1841 ’ , ’ 244 ’ , ’ 76 ’ , ’ 29 ’ ,
          ’ 1685 ’ , ’ 33 ’ </ string >
 4   < boolean name = " pref_started_before " value = " true " / >
 5   < boolean name = " do_full_sync " value = " true " / >
 6   < boolean name = " pref_clear_prefs " value = " false " / >
 7   < int name = " show_l ocati on_too ltip " value = " 2 " / >
 8   < string name = " reg _v ibe r_c ou ntr y_ cod e " > 31 </ string >
 9   < string name = " r e g _ v i b e r _ l o c a l _ c o u n t r y _ c o d e " >0 </ string >
10   < string name = " r e g i s t e r e d _ v i b e r _ p h o n e _ n u m " > +31063834 xxxx </ string >


                                                                  15
     Experiments                                                                                                                               Chapter       3

11   < string name = " sync_hash " >1 c 5 8 2 c 9 b 3 f 8 d c c 1 2 a 1 e 7 4 f d 9 f e 4 e 2 7 c e 7 9 4 b 9 3 f 9 </ string >

     iOS:
 1                < dict >
 2                           < key >$ class </ key >
 3                           < dict >
 4                                          < key > CF $ UID </ key >
 5                                          < integer >3 </ integer >
 6                           </ dict >
 7                           < key > NS . string </ key >
 8                           < string > 62782 xxxx </ string >
 9                           </ dict >
10                < string > 31 </ string >
11                < string > 2.1.3.244 </ string >
12                < string >3 d 4 a 7 c e 7 d 4 d c d 0 2 f 2 5 5 7 3 e 0 d 0 d 6 9 9 d 6 0 c 2 4 b 6 0 9 4 a 0 7 6 4 0 8 e 4 d 6 e f 8 4 1 4 3 0 e 2 7 a c </
                       string >
13                           < dict >
14                           < key >$ class </ key >
15                           < dict >
16                           < key > CF $ UID </ key >
17                           < integer >3 </ integer >
18                           </ dict >
19                           < key > NS . string </ key >
20                           < string > 24 a 6 d 8 c d 8 b 3 0 2 4 d a 1 1 6 6 d 7 4 1 5 6 3 f 2 7 4 1 4 f 1 c f 6 a 7 </ string >
21                           </ dict >
22                < dict >

     As you can see the attribute names are much better defined in Android then those on iOS. With
     this you can probably distinguish what those values are on iOS through looking at the xml files in
     Android. Those hashes stored in the xml files especially look interesting and maybe can be used to
     gain extra knowledge when reverse-engineering the code. The hashes that are stored are for the:

         • Device key (SHA-256 hash)

         • Viber ID (SHA-1 hash)

         • Sync hash (SHA-1 hash)

     It’s also easy to view your activation code in the Android xml files, where also a ‘last_message_token_id’
     can be found. Further the xml files contain values for all kind of configuration options. An inter-
     esting configuration value can be the one that’s says if your Viber is activated or not. We will come
     back to that one later.




                                                                                16
Experiments                                                                                                       Chapter   3

3.2     Reverse Engineering

In Chapter 2.2 Protocol Reverse Engineering was discussed as a manual and automated process. In
the chapter we will try to apply the same techniques on Viber.


3.2.1    Lab Setup

Before being able to analyze the data, a network has to be set up to capture it. We found an old
Linksys wireless router in the lab to use and connected that to a hub. This hub also connects to
two of our servers, one that would provide the connection to the Internet and another one to just
capture the packets.




                        192.168.1.101                                                              Internet
                                                     192.168.2.1       berlin.stublab.os3.nl




               192.168.1.1
                                       192.168.2.2


                                                                     Hub
                             linksys


                                                                   No IP-address

                                                                                               Viber Serverfarm
                                                                      athens.studlab.os3.nl


                                       Figure 1: The packet sniffing test set-up.

In Figure 1 the set-up is presented in it’s most basic form. The Linksys router wasn’t able to function
as a standalone wireless Access Point (ap) so we had to nat the ip-addresses.
On berlin.athens.os3.nl we added the following IPtables rule to allow nat there as well:
iptables --table nat -A POSTROUTING \
         -s 192.168.2.0/24 \
       ! -d 192.168.2.0/24 -j MASQUERADE

After we completed the setup we could associate a smartphone with the Linksys ap and we started
seeing incoming frames on the capturing interface of athens. We used tcpdump to capture the traffic
that was going over the line and wrote that to several .pcap-files. This allowed us to later filter
these packets.




                                                                     17
Experiments                                                                            Chapter   3

3.2.2   Protocol Informatics

In paragraph 2.2.2 the Protocol Informatics (pi) Project was explained as a tool to automatically
analyze a proprietary protocol. Installing pi requires the following Ubuntu packages:

   • python-pydot

   • python-pyrex

   • python-pcapy

   • python-numpy

This seemed like a good starting point to get some results so we filtered the data to get a one way
voice stream using the following command:
tshark -r long-call.pcap \
       -w long-call-oneway.pcap udp.dstport == 5243

Here we select only the UDP packets with the destination port for the Viber service so it is only
originating voice traffic. The pi python script takes this pcap-file as input.




                                                18
Experiments                                                                                                        Chapter   3

mappelman@athens:~$ ./main.py -p long-call-oneway.pcap
Protocol Informatics Prototype (v0.01 beta)
Written by Marshall Beddoe <mbeddoe@baselineresearch.net>
Copyright (c) 2004 Baseline Research

Found 1890 unique sequences in ’../real-voiceonly.pcap’
Creating distance matrix .. complete
Creating phylogenetic tree .. complete

Discovered 1 clusters using a weight of 1.00
Performing multiple alignment on cluster 1 .. complete

...

0152   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xdc   x84   x24   x11   x0e   ___   ___
0120   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xbc   x84   x23   xd5   x0e   ___   ___
0136   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xcc   x84   x23   xf3   x0e   ___   ___
0128   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xc4   x84   x23   xe4   x0e   ___   ___
0144   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xd4   x84   x24   x02   x0e   ___   ___
0148   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xd8   x84   x24         x8e   ___   ___
0154   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xde   x84   x24   x14   xce   ___   ___
0150   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xda   x84   x24         x4e   ___   ___
0155   x80   x3a   x80   x67   ___   ___   ___   ___   ___   ___   x16   xdf   x84   x24   x16   xae   ___   ___
DT     BBB   AAA   BBB   AAA   GGG   GGG   BBB   GGG   BBB   GGG   GGG   GGG   GGG   GGG   GGG   AAA   BBB   BBB
MT     000   000   000   000   000   007   000   013   001   002   000   013   000   000   006   007   013   000
BYTE    1     2     3     4     5     6     7     8     9     10    11    12    13    14    16    17    18    19

...

Ungapped     Consensus:
CONS x80     x3a x80 x67 x84 xce x99 xad x3e
DT   BBB     AAA BBB AAA BBB BBB BBB BBB AAA
MT   000     000 000 000 001 000 000 000 000

The file contains 1890 different packets which the tool has to analyze, sort into a ptree and align
based on similar fields. Eventually it takes approximately 22 hours to run and comes up with the
(truncated) output as seen in the above blockquote.
The ungapped concensus represents the final structure that pi has found. It gives the Data Type (dt)
and the percentage of mutation (mt). The cons bar indicates the most often found value in that
particular byte-field. It has found that the first byte is apparently a Binary field, followed by an
ascii field, and so on. The rest of the packets apparently has no real consensus, and is treated as
payload.
An obvious limitation here is that all the packets are treated as messages of the same kind, this
limits the algorithm in seeing relationships that might be present but aren’t recognized. Another
issue is that the tool doesn’t account for fields with values that are rising with each packet. These
sequence numbers can be important in how the protocol works but have been lost in the process.




                                                                         19
Experiments                                                                            Chapter   3

3.2.3   Manual Reverse Engineering

A lot of developers have warned us that protocol reverse engineering cannot be easily done auto-
matically and a lot has to be done by hand. Using basic tools we will try to make sense of all the
hex.

Basic Structure
We start by looking at the different kinds of messages and the headers we are sending towards the
serevers. Starting with a truncated list of the first 32 bytes of the udp payload.

4b990100010077cab33159228d1200a0..
4b99020077cab33159228d12060ccc02..
4b99030077cab33159228d12
4b99020077cab33159228d12060ccc02..
4b990600004976a50e34010000
4b9909004976a50e3401000000
4b990600015250a50e34010000
4b9909005250a50e3401000000
4b99030077cab33159228d12
4b99030077cab33159228d12
4b99060000327aa50e34010000
4b990900327aa50e3401000000
4b990600013b54a50e34010000
4b9909003b54a50e3401000000
4b990a0081c8000ceb6e70fbd28754e5..
4b1980673cad3d353a86eb6e70fbe190..
4b9906000174b2a60e34010000
4b99090074b2a60e3401000000
4b1980673cae3d353e46eb6e70fbe620..
4b1980673caf3d354206eb6e70fbe141..
4b99060000eed8a60e34010000
4b990900eed8a60e3401000000
4b1980673cb03d3545c6eb6e70fbe620..
4b1980673cb13d354986eb6e70fbe5a9..
4b1980673cb53d355886eb6e70fbe224..
4b990a0080c90001eb6e70fb81cb0001..
4b990a0081c900071d5a94a399ad3e5a..
4b99050077cab33159228d12

This piece has been immensely truncated but already we can differentiate between two packet types:
long voice packets starting with 0x4b19 and shorter signaling messages starting with 0x4b99.



                                               20
Experiments                                                                               Chapter   3

Signaling Messages The stream of signaling messages all start with a seemingly random stream
identifier (in this case 0x4b99) which in all calls is 0x0080 higher than the actual voice data stream.
The next two bytes indicate some sort of message type. Table 1 displays the values of the two bytes
and their occurrences during a long call. Note that these messages are for the most part just sent
from client to server (except for the 0x0200 messages), the messages from the server to the client
have different starting bytes.

                                         Value   Occurences
                                          0100       1
                                          0200       2
                                          0300      142
                                          0500       1
                                          0600      182
                                          0900      182
                                          0a00       20


                      Table 1: Message type indicators and their occurrences.

Using these numbers and their position in the stream, we can infer the meaning of the values. The
0x0100 value for example only occurs once at the begin of the stream and 0x0500 at the end, so we
can assume that these message mark the beginning and the end of the call sent out by the client. The
0x0300 messages are the only messages that are sent directly to the Internet Protocol (ip)-address
of the other party. They occur a lot more but do not change over time:
<349> mappelman:captures michiel > cat udp-payload.txt | grep "^4b9903" | uniq -c
 142 4b99030077cab33159228d12

This message also includes a special value which is also referenced in the beginning and end messages
(0x77cab33159228d12) so this looks like a simple keep alive message sent from client to client. The
special value changes each call but we haven’t found a source for it. This value is also included in
another type of message which is the only message that originates from the server with the same
first two bytes and has a message type value of 0x0200. Table 2 gives an overview of these messages.
The message value 0x0200 contains the aforementioned special value and the ip of the other client
(twice actually, separated by the values 200 and 63) and some other yet unknown information as can
been seen in Table 3.
Values 0x0600 and 0x0900 are messages which follow a specific routine. First a messages with a
0x0600 value is sent out, then immediatly after that a message with a 0x0900 value and after some
time a reply is received on the incoming stream. In Table 4 one such message exchange is displayed.
A possible explanation might be the measurement of jitter in the network. The client sends two
measurement in rapid succession, the server receives these messages and after a couple of those
message pairs it can see how well the path to the client performs. After that it returns the packet
back to the client which is then able to calculate the Round Trip Time (rtt) and jitter towards the
server.


                                                 21
Experiments                                                                                Chapter   3

                 Time      Source ip       Dest ip           udp Payload
          01.765650000     192.168.2.2     79.125.85.225     4b990100010077cab3315922..
          01.789661000     79.125.85.225   192.168.2.2       4b99020077cab33159228d12..
          01.814890000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
          01.814973000     79.125.85.225   192.168.2.2       4b99020077cab33159228d12..
          02.054238000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
          02.256731000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
          02.503092000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
                     .     .               .                 .
          31.497124000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
          31.704656000     192.168.2.2     145.18.248.29     4b99030077cab33159228d12
          33.042943000     192.168.2.2     79.125.85.225     4b99050077cab33159228d12


                       Table 2: Message exchange between clients and server.

                                  060ccc02     2       204   12    6
                                  1df81291     145     18    248   29
                                  3fc81df8     248     29    200   63
                                  12913fc8     200     63    145   18
                                  06000000     0       0     0     6


   Table 3: Little Endian translations to decimal octets from payload of 0x0200 value message.


The extra byte that follows the 0x0600 message type alternates between 0x00 and 0x01 between
every measurement. This could provide some frame loss checking, for example if the server receives
two messages with that byte set to 0x01 after each other it would know that it missed a whole
measurement with 0x00 set as the value.
The last message type that was captured has a value of 0x0a00 and has a considerably longer payload.
The message is sent to the server every couple of seconds and may contain some information about
network performance, bytes exchanged and possibly even key information if decent encryption will
be used. Table 5 contains a list of data in 32-bit words in the payload. Time was too short to sort
out the meaning of every byte but some patterns did emerge.


Voice Messages The second packet stream starts its payload with the 0x4b19 sequence. It con-
tains the actual voice data and of course some header information. After the first two bytes which
are unique for each call follow two bytes that are the same for each call: 0x8067. Also included is a
sequence number which increases with every packet and a time field that increases with 0x00001000
every quarter of a second. The opening and ending sequence from Table 5 follows that and the end of
the header consist of one byte which varies a lot over the course a call and apparently has no relation
any of the frame characteristics like length. This could possibly be an indication of the quality of
the network as the client itself is experiencing it.


                                                  22
Experiments                                                                             Chapter   3

                 Time    Source ip       Dest ip         udp Payload
              3.821356   192.168.2.2     79.125.85.225   4b990600001a7ea50e34010000
              3.831607   192.168.2.2     79.125.85.225   4b9909001a7ea50e3401000000
              3.875186   79.125.85.225   192.168.2.2     80ba0600001a7ea50e34010000


                    Table 4: Measurement messages between client and server.

                              Value      Type            Description
                           4b990a00      CONSTANT        ‘Known’ Header
                           81c8000c      CONSTANT
                           eb6e70fb      CONSTANT        Opening?
                           d28754fe      INCREASING      +1 each second
                           37f90d9d
                           f9a85dba      INCREASING      Fast increase
                           00000194      INCREASING
                           00009beb      INCREASING
                           99ad3e5a      CONSTANT
                           00000000                      Flags?
                           00001957      INCREASING
                           000000ed
                           54f0f0b9      INCREASING
                           00038d10
                           81ca0002      CONSTANT
                           eb6e70fb      CONSTANT        Ending?
                           01000000      CONSTANT


                     Table 5: Analysis of data in payload of 0x0a00 messages.


We guessed the end of the headers due to the fact that all other data following the last byte was
pretty much random. Running a frequency analysis over this data gives us an indicating of how
random exactly, as shown in Table 7.
This randomness could be because of some decent encryption that has been implemented but even
unencrypted audio data is exceptionally random because of background noise and cosmic interference.


3.2.4   Text Messages

Besides the voice calls that Viber enables the user to make, it also allows them to send and receive
text messages. This functionality uses some specialized tcp-based protocol to connect to the server
and exchange messages. Decoding this stream has not been a priority within this project and there
wasn’t any time left to research this further.



                                                 23
Experiments                                                                             Chapter   3

                                   Value       Description
                                   4b198067    Known Header
                                   3ca5        Sequence Number
                                   3d351c86    Time
                                   eb6e70fb    Constant
                                   e6          Network Quality?


                        Table 6: Analysis of header data in voice messages.

                                         Hex    Frequency
                                           0    6.23839
                                           1    6.13784
                                           2    6.07624
                                           3    6.13482
                                           4    6.1007
                                           5    6.69676
                                           6    5.99381
                                           7    6.73028
                                           8    6.05782
                                           9    6.04726
                                           a    6.10765
                                           b    6.0853
                                           c    6.03457
                                           d    6.73873
                                           e    6.05994
                                           f    6.75987


                       Table 7: Frequency analysis of data in voice packets.


3.2.5   Cryptanalysis

After getting to the voice data in the messages there was not enough time left to get to the bottom
of the cryptography used in the protocol. In paragraph 3.2.3 a frequency analysis has been done
but this of course isn’t particularly useful against data that by nature is already very random. We
can say that because the length of the payload of each packet differs significantly and the smallest
deviation is only one byte, a block cipher seems out of the question and if encryption would be used
it will be a stream cipher.
Of course the question still remains: is it scrambled or encrypted?




                                                 24
Experiments                                                                                  Chapter   3

3.3     Application Code Analysis

3.3.1    Introduction

In the previous sections, a representation was given of Viber’s security seen from the outside of the
application (its externals). In the following section, some interesting details of the internals of Viber
are unveiled. The information in this section by no means covers the welt of information about the
to be presented techniques, but tries to give a fair insight.
Before we continue, let’s first think of how an iOS/Android application is developed. Generally, a
team of developers start programming an application once an idea has been established and com-
pletely worked out. The result of their hard work will be the application’s source code. During several
phases of development, the source code is compiled to form an application that can be executed (and
thus debugged) on the iOS/Android platform. Finally, the result of one or more prototypes is a
finished application that is ready to be distributed. Now, let’s assume this application was accepted
by both Apple and Google, and put available for download in the App Store and Android Market,
respectively. Users will be able to download, install and use the application. Most users however
will not even wonder or think about the level (or lack of) communication security provided by the
application, as described before. The users that do either depend on the information provided by
the author, the information from other users that also use the application, or on the information
gained by studying the externals of the application themselves (like we have done in the previous
sections). Ideally, this last group of users could go one step further and actually also explore some
of the application’s internals. In other words, one could go back to the development phase of the
application and have a look at the application code, be it not always code that is easy to read and
understand. The term that is generally used for this is reverse engineering. Note that the word
source, as in application source code, was intentionally left out. We will get back as to why this is.
Having all this said, we for a moment continue with the general notion of an Android application
and will later switch back to Viber for Android in specific. Moreover, only after this description will
we be able to tell as to why iOS applications were left unspoken of.
Applications for Android are generally developed entirely in the Java programming language.[30] We
will focus on this type of applications. However, it is useful to know there are also applications that
differ due to the fact they are not entirely written in Java, but also contain portions written in the
C/C++ programming language (also called native code). Google does recommend the use of Java,
however portions that are either performance-critical or part of a large base of previously developed
source code in C/C++, are seen as valid reasons to make use of native code.[31]
Applications are stored in an (Application Package File (apk)). Without getting into too much of
the details, since this is not import to understand what follows, consider the package file as nothing
more than an compressed archive with important files in it. These files consist of the compiled Java
application code and the data files that the application and its installation procedure depend on.
What we are interested in is actually a single file named classes.dex. This file is the result of first
compiling one or more Java source code files into multiple class files, followed by another compiler
named dx to convert and optimize these class files into a single dex file. This process is illustrated
in figure 2.


                                                   25
    Experiments                                                                                                 Chapter   3

                  Figure 2: Compilation of Android applications: from source to application[32]




    Obviously, this process can be reverted, otherwise we would not be giving you all this information.
    There are several methods currently available to do so. One can decide to simply reverse the il-
    lustrated process of compilation by first converting the single dex file back into the original class
    files. For this purpose the tool dex2jar 2 (which is actually a program written in Java) can be used.
    Assuming dex2jar did the job correctly, this results in the original class files of an application stored
    in an JAR archive file. At this point one needs to turn the compiled class files into Java code so that
    it is easy to understand by humans. Fortunately, there are several tools available that do the job.
    One of the tools able to do so is JD-GUI, which is ‘a standalone graphical utility that displays Java
    source codes of class files.’3 It does a pretty good job at decompilation, but unfortunately it tends
    to stop responding when trying to decompile certain class files. This is especially troublesome if one
    wants to save decompiled class files to disk. (During such an export JD-GUI saves decompiled files in
    an archive file, and when it suddenly stops responding because it tries to process such a certain class
    file, the archive file is corrupted thus rendering the successfully decompiled files useless.) Moreover, it
    does not allow exporting a selective amount of class files and cannot be used from the command-line.
    Other popular tools for Java decompilation that both do provide these properties, amongst much
    more, are JAD 4 and Soot 5 . However no Java decompiler is perfect in the sense that it reproduces
    exactly the source code that was written by the developers. In fact, it may not even be valid Java code
    at all.[33] Results may vary for different class files depending on the code, coding-style, optimizations,
    obfuscation found in the original Java source code, and the compiler that was used. All in all, despite
    the issues with JD-GUI, it provides enough functionality to be useful for the purpose of this report.
    This brings us to the last point before wrapping up this section and continuing with the decompiled
    application code of Viber in particular. What about the usability of the decompiled Java code? As
    an example, consider the two pieces of Java code given in the listings below (1 & 2).
1   public String getInitParameter ( String name ) {
2     ServletConfig sc = getServletConfig () ;
3     if ( sc == null ) {
4       throw new Ill egalSt ateEx ceptio n (
5          lStrings . getString ( " err . s e r v l e t _ c o n f i g _ n o t _ i n i t i a l i z e d " ) ) ;
6     }
7     return sc . getInitParameter ( name ) ;
8   }
                                             Listing 1: Original Java source code[34]

       2
         dex2jar – http://code.google.com/p/dex2jar/
       3
         JD-GUI – http://java.decompiler.free.fr
       4
         JAD – http://www.varaneckas.com/jad/
       5
         Soot – http://www.sable.mcgill.ca/soot/


                                                                       26
     Experiments                                                                                                      Chapter   3

 1   public String getInitParameter ( String paramString )
 2   {
 3     ServletConfig localServletConfig = getServletConfig () ;
 4     if ( l oca lServletConfig == null )
 5       {
 6          String str = lStrings . getString ( " err . s e r v l e t _ c o n f i g _ n o t _ i n i t i a l i z e d " ) ;
 7          throw new Ill egalSt ateEx ceptio n ( str ) ;
 8       }
 9     return lo calServletConfig . getInitParameter ( paramString ) ;
10   }
                                     Listing 2: Decompiled Java code by JD-GUI[34]

     Even for such a small piece of code, there are quite some notable differences between the original
     source code and the decompiled version of the code. Furthermore, Google provides a tool named
     ProGuard which “shrinks, optimizes, and obfuscates your code by removing unused code and re-
     naming classes, fields, and methods with semantically obscure names. The result is a smaller sized
     .apk file that is more difficult to reverse engineer.”[35] Imagine such a tool being used, this makes it
     even harder to decompile to application code that is readable and at the same time being valid Java
     code. By now you will probably understand why we intentionally did not talk about source code,
     but rather decided to use the phrase ‘application code’.
     For the record, it is also possible to decompile applications for Apple’s iOS platform, however the
     resulting code is more low-level than for most decompiled Android applications (assuming these
     largely consist of components written in Java). The reason for this being the case is that iPhone
     applications are written in Objective-C, which cannot be decompiled but only disassembled. The
     result would be application code in assembly, which we consider a low-level language since it is not
     easily readable by human beings.
     Note, the legality of decompiling and disassembling applications for iOS and Android is bluntly
     ignored throughout the above section.


     3.3.2     Application Code

     An analysis of the most interesting parts of the decompiled Java application code of Viber for
     Android, regarding the contents of this report, is presented in this section. The analysis is based on
     Viber version 2.1.2.116554, which at time of writing is the latest available version.
     After putting the Viber package file through the previous described decompilation process, the total
     number of resulting class files is 468. However when minimizing all the classes that lie outside the
     com.viber namespace, 265 class files directly belong to Viber. By lying outside we mean all other
     namespaces that to not directly belong to Viber but are included in the Viber package file because
     they are depended on, i.e. org.apache.james.mime4j and org.apache.http.entity. After looking
     at the contents of all the class files, we concluded that the application code has not been obfuscated.
     This strongly indicates ProGuard was not used, or at least not for this purpose.
     Now for the actual application code. The first intriguing thing that we found in the application code
     is part of the method GetDeviceUDID, which is shown in listing 3.

                                                                   27
     Experiments                                                                                              Chapter    3

 1   String GetDeviceUDID ( Context paramContext )
 2   {
 3     log ( " GetDeviceUDID " ) ;
 4     Share dPreferences l oca lS har ed Pre fe ren ces = PreferenceManager .
            g e t D e f a u l t S h a r e d P r e f e r e n c e s ( paramContext ) ;
 5     Object localObject = lo ca lSh ar edP re fer enc es . getString ( " viber_udid " , " " ) ;
 6     log ( " UDID in preferences : " + ( String ) localObject ) ;
 7     if ((( String ) localObject ) . equals ( " " ) )
 8     {
 9       log ( " UDID not found in preferences , generate " ) ;
10       String str1 = (( TelephonyManager ) paramContext . getSystemService ( " phone " ) ) .
                getDeviceId () ;
11       if (( TextUtils . isEmpty ( str1 ) ) || ( str1 == null ) )
12       {
13           SecureRandom localSecureRandom = new SecureRandom () ;
14           str1 = localSecureRandom . nextLong () + localSecureRandom . nextLong () ;
15       }
16       try
17       {
18           String str2 = Convert . getSha1 ( str1 ) ;
19           localObject = str2 ;
20           if (! Patterns . UDID . matcher (( CharSequence ) localObject ) . matches () )
21               throw new Ill egalSt ateEx ceptio n ( " error generating UDID - pattern doesn ’t
                        match ! " ) ;
22       }
23       catch ( N oS u c hA l g or i t hm E x ce p t io n l o c a l N o S u c h A l g o r i t h m E x c e p t i o n )
24       {
25           throw new Ill egalSt ateEx ceptio n ( " error generating UDID " ) ;
26       }
27       l o c a l S h are dP ref er enc es . edit () . putString ( " viber_udid " , ( String ) localObject ) .
                commit () ;
28     }
29     log ( " UDID is " + ( String ) localObject ) ;
30     return ( String ) localObject ;
31   }
     Listing       3:                 Method         GetDeviceUDID                                     in            class
     com.viber.voip.registration.HardwareParametersImpl

     This above piece of code is actually responsible for the generation of an Unique Device Identifier
     (udid) . Basically, it first looks in the corresponding locally stored configuration file of Viber to see
     if a udid is already established. If it is, it simply returns the udid as a string. Otherwise, it calls the
     getDeviceId method in the Android framework and stores the result in the str1 variable. Normally
     the getDeviceId method returns the International Mobile Equipment Identity (imei) number (for
     Global System for Mobile Communications (gsm) -based Android devices).[36]
     If it does not return anything, a “a pseudo-random uniformly distributed long” is generated by the
     method nextLong of the SecureRandom class and stored in the str1 variable.[37] The content of the
     str1 variable (either the imei or random number) is then hashed with Secure Hash Algorithm (sha) -
     1. The resulting hash is stored in the str2 variable and compared to a pattern to verify its format
     is correct. The code of this pattern is shown in listing 4.


                                                              28
     Experiments                                                                                                                     Chapter     3

     It does nothing more than making sure any value’s format should be 40 characters in total, where
     the only allowed characters are the (non-capital) letters ‘a’ through ‘f’ and all numbers. Assuming
     the hash in the str2 variable complies with this requirement, it is written to the corresponding
     configuration file and from now on used as the udid .
     The above theory has been tested to be valid. For example, when Viber is registered in an Android
     Virtual Device (avd) , which is nothing more than a way to emulate an Android device on a regular
     computer, the default imei of 000000000000000 for any avd is hashed into c02c705e98588f724ca046ac59cafece65501
 1   static
 2   {
 3     [...]
 4     UDID = Pattern . compile ( " [a - f0 -9]{40} " ) ;
 5     [...]
 6   }
                                 Listing 4: UDID pattern in class com.viber.voip.util.Patterns

     We found another interesting method regarding the process of registration. This method is named
     generateSignature and the corresponding application code is shown in listing 5. Just like the earlier
     described method which generated a udid, the method we are describing in this paragraph is also
     just a small part of Viber’s entire registration process. The method is part of the generation of a
     device key based on an input string passed along to the method. This probably sounds similar to
     the udid we earlier described but in fact it is not. Instead, the device key is generated by the Viber
     services and not at the client-side. When the registration process of a new Viber account is initiated,
     an SSL certificate is retrieved and used to communicate with a web server of the Viber services over
     http Secure (https) . The URLs for the registration process are present in the application code,
     shown in listing 6.
 1   private String generateSignature ( String paramString )
 2     throws Exception
 3   {
 4     SecretKeySpec localSecretKeySpec = new SecretKeySpec ( " 5
           e b 6 5 8 8 0 8 6 b 6 b 2 d 0 5 4 a f 8 0 5 2 7 b 2 6 c a f 7 1 d 1 6 5 0 4 2 1 7 5 e 0 f 9 5 5 0 e a 5 8 a 8 " . getBytes () , "
           HmacSHA256 " ) ;
 5     Mac localMac = Mac . getInstance ( " HmacSHA256 " ) ;
 6     localMac . init ( localSecretKeySpec ) ;
 7     byte [] arrayOfByte = localMac . doFinal ( paramString . getBytes () ) ;
 8     StringBuffer localStringBuffer = new StringBuffer () ;
 9     int i = arrayOfByte . length ;
10     for ( int j = 0; ; j ++)
11     {
12     if ( j >= i )
13       return localStringBuffer . toString () ;
14     local StringBuffer . append ( Integer . toHexString (256 + (0 xFF & arrayOfByte [ j ]) ) .
           substring (1) ) ;
15     }
16   }
     Listing       5:                Method         generateSignature                                                        in                class
     com.viber.voip.registration.GenerateDeviceKeyManager


                                                                           29
     Experiments                                                                                                      Chapter    3

 1   private class ProdServerConfig extends ServerConfig . IServerConfig
 2   {
 3     public ProdServerConfig ()
 4     {
 5       super () ;
 6       this . u r l_ ac tiv ati on _re qu est = " https :// secure . viber . com / viber / viber . php ?
             function = ActivateUser " ;
 7       this . u r l _ re g i st r a ti o n _r e q ue s t = " https :// secure . viber . com / viber / viber . php ?
             function = RegisterUser " ;
 8       this . ur l_country_request = " https :// secure . viber . com / viber / viber . php ? function =
             GetD efaultCountry " ;
 9       this . u r l _ de a c ti v a ti o n _r e q ue s t = " https :// secure . viber . com / viber / viber . php ?
             function = DeActivate " ;
10       this . u r l_ ge ne r at e_ de v ic e_ k ey = " https :// secure . viber . com / viber / viber . php ?
             function = GenerateDeviceKey " ;
11       this . u r l _ g e n e r a t e _ d e v i c e _ k e y _ d o n e = " https :// secure . viber . com / viber / viber . php ?
             function = G enera teDevi ceKey D one " ;
12       this . u r l _ up d a te _ p ho n e _r e q ue s t = " https :// secure . viber . com / viber / viber . php ?
             function = UpdatePhone " ;
13       this . url_voip_host = " aloha . viber . com " ;
14     }
15   }
                   Listing 6: ProdServerConfig URL’s in class com.viber.voip.ServerConfig

     One could easily see that the generateSignature method uses a Hash-based Message Authentication
     Code (hmac) based on sha -256, and a statically configured secret key with the value 5eb6588086b6b2d054af80527b
     We suspect that before the method is executed, an xml -based request is built by other application
     code and then passed onto the generateSignature method which outputs a signature of that input.
     Once this is transmitted along with the xml -based request, it provides integrity of the contents of
     the request.
     Lastly, we have selected some interesting methods regarding sending/receiving messages. First,
     the code of the sendNewMessage method shown in listing 7. This method takes two parameters:
     the recipient’s number, the text of the message, and the current time in milliseconds, respectively.
     Amongst other things, it then passes these parameters on to the method insertNewMessage along
     with nine other static values.
 1   public void sendNewMessage ( String paramString1 , String paramString2 )
 2   {
 3     log ( " sendNewMessage toNumber : " + paramString1 + " , text : " + paramString2 ) ;
 4     insertNewMessage ( null , paramString1 , paramString2 , System . currentTimeMillis () , 1 ,
               0 , 1 , 0 , 0 , 3 , " text " , false ) ;
 5     s en d P en d ingMessages () ;
 6   }
             Listing 7: Method sendNewMessage in com.viber.voip.messages.MessagesManager

     Since the actual insertNewMessage method is long and not very interesting, we decided to show
     the code of the createMessageValues method instead, see listing 8. The reason is that this method
     clearly shows the meaning of almost all the different parameters passed to the insertNewMessage
     method.

                                                                   30
     Experiments                                                                                       Chapter   3

 1   private ContentValues createMessageValues ( Long paramLong , String paramString1 ,
         String paramString2 , long paramLong1 , int paramInt1 , int paramInt2 , int
         paramInt3 , int paramInt4 , int paramInt5 , int paramInt6 , int paramInt7 , String
         paramString3 )
 2   {
 3     ContentValues localContentValues = new ContentValues () ;
 4     lo ca lC ont entValues . put ( " status " , Integer . valueOf ( paramInt3 ) ) ;
 5     lo ca lC ont entValues . put ( " date " , Long . valueOf ( paramLong1 ) ) ;
 6     if ( paramLong != null )
 7        lo ca lC ontentValues . put ( " token " , paramLong ) ;
 8     lo ca lC ont entValues . put ( " read " , Integer . valueOf ( paramInt4 ) ) ;
 9     lo ca lC ont entValues . put ( " body " , paramString2 ) ;
10     lo ca lC ont entValues . put ( " thread_id " , Integer . valueOf ( paramInt1 ) ) ;
11     lo ca lC ont entValues . put ( " type " , Integer . valueOf ( paramInt2 ) ) ;
12     lo ca lC ont entValues . put ( " address " , paramString1 ) ;
13     lo ca lC ont entValues . put ( " flag " , Integer . valueOf ( paramInt5 ) ) ;
14     lo ca lC ont entValues . put ( " seq " , Integer . valueOf ( paramInt6 ) ) ;
15     lo ca lC ont entValues . put ( " extra_status " , Integer . valueOf ( paramInt7 ) ) ;
16     lo ca lC ont entValues . put ( " extra_mime " , paramString3 ) ;
17     List localList = ContactsUtils . get Co nta ct IdF rom Nu mbe r ( this . context , paramString1 )
            ;
18     long l ;
19     if (( localList != null ) && ( localList . size () > 0) )
20        l = (( Long ) localList . get (0) ) . longValue () ;
21     while ( true )
22     {
23        lo ca lC ontentValues . put ( " person " , Long . valueOf ( l ) ) ;
24        return localContentValues ;
25        l = -1 L ;
26     }
27   }
          Listing 8: Method createMessageValues in com.viber.voip.messages.MessagesManager

     This is interesting because we now have an idea on what a message is actually composed of. It
     obviously contains the recipient’s address and the message text, but also a token, a flag, a sequence
     number, et cetera. This brings to another important fact, that of tokens being associated with
     messages. The code responsible for token generation is shown in listing 9.
 1   private int getNewToken ()
 2   {
 3     monitorenter ;
 4     try
 5     {
 6       Share dPreferences l oca lS har ed Pre fe ren ces = this . context . getSharedPreferences ( "
                messages_manager " , 0) ;
 7       int i = lo ca lSh are dP ref er enc es . getInt ( " la st_me ssage_ token _id " , 0) ;
 8       if ( i == 0)
 9           i = 0 x7FFFFFC0 & Math . abs ( random . nextInt () ) ;
10       int j = i + 1;
11       l o c a l S h are dP ref er enc es . edit () . putInt ( " last _mess age_to ken_id " , j ) . commit () ;
12       monitorexit ;
13       return j ;
14     }


                                                          31
     Experiments                                                                              Chapter   3

15       finally
16       {
17         localObject = finally ;
18         monitorexit ;
19       }
20       throw localObject ;
21   }
              Listing 9: Method getNewToken in com.viber.voip.messages.MessagesManager

     The getNewToken method first looks in the corresponding configuration file to see if a token is
     already established. If it is, it increments its value by one, stores it in the configuration file, and
     returns it. Otherwise, a random integer value and some math is used to generate an initial token,
     after which the same steps described above for a existing token are repeated.
     This concludes our analysis of most interesting parts in the application code. Of course there is
     much more to explore (literally) and we recommend anyone that has become interested to do so.
     The ability to look at the application code has many advantages, and could save a lot of time when
     trying to reverse engineer a protocol. However, if an application consists of a couple hundred class
     files, one easily gets lots quickly. This can also get time-consuming when one needs to figure out how
     some functionality in the application itself translates back to the application code.




                                                      32
Experiments                                                                                 Chapter   3

3.4   Other Weaknesses

In this section we will describe a couple weaknesses of Viber’s current design that can potentially
be abused. We mainly focus on something that was on a somewhat other way mentioned in the
previous sections: the registration process. During the project we came across a couple of things
that we find useful to note. Moreover, we felt that the registration process is an important aspect
of Viber and one could argue is it even more important than the communication security. Think of
what would happen if one could manually configure itself to forge a person’s Viber account (their
phone number that is), and by doing so listening in to all communication of that person without
having to decrypt/decipher communication data.
The registration process on the iOS platform is identical to that on the Android platform. It is
explained below. When Viber is run for the first time it will ask for permission to access the
phonebook (According to Viber’s privacy policy it is used to (a) notify you when your contacts
become active on Viber, (b) indicate which of your contacts is already a Viber user, and (c) correctly
display the name of each contact as it appears in your address book when a call is received.[38] ) After
granting access, it will ask for a phone number. This phone number is used as an account identity
to allow one to receive/send messages and calls. After filling in a phone number, an automated
computer system sends a text message with an four digit activation code to this phone number (thus
via the regular telephone network). However, if the text message did not arrive, one can make use of
the provided callback service. This service is provided by another automated computer system that
makes a phone call to the earlier filled in phone number and then reads the four digit activation code
out loud. When the correct activation code is entered into Viber, the account will get activated and
the application can be used.
By now it might already be somewhat clear that the registration process can be abused. For example,
someone could fill in the phone number of another person, and spam them with the automated text
messages and phone calls. Obviously, there is a limitation to the amount of automated text messages
and phone calls from the Viber services: 1 text message and 2 phone calls in 24 hours. Imagine how
frustrating this could get if an imposter would do this every day with your phone number. Luckily
besides annoying someone, as long as the activation code is not known to an imposter, (theoretically)
no harm could be done.
Earlier we described of which steps the registration process is made up of. In Viber for Android
every step has several associated configuration items that are stored in corresponding configuration
files, such as granting access to the phone book, the generated udid, the filled in phone number, the
activation code, the generated device key, et cetera. Moreover, even the currently active registration
step is stored in a configuration file (thus on the client-side). This allows one to modify the current
state of the registration from non-activated to activated without the need of an activation code.
This sounds much easier than it is since the Viber services are of course also keeping track of some
registration state of the client. However, we did manage to bypass the official registration process in
an avd and were suddenly able to use Viber from a completely unknown phone number. Basically
what we did was first adding ourselves as a contact to the address book of the avd, then forced the
registration state to activated by modifying the corresponding configuration file, and then after we
were activated send a text message to one of our own Viber account.


                                                  33
Experiments                                                                             Chapter   3

The figures 3(a) and 3(b) are screen captures taken on a iPhone and show that we were actually able
to communicate two ways once we received a text message from the unknown Viber account.




                     (a) Viber message overview        (b) Viber message log


Unfortunately trying to reproduce this did not turn out to be a success. So we are not sure if we
managed to do so the first time because it is actually a design flaw, a glitch or malfunction of the
Viber services, or due to a certain configuration state of the application. Though, we lean towards
thinking it could be done again if one has enough time to go through various configuration scenarios
in the correct order.




                                                  34
Conclusion                                                                               Chapter   4

4     Conclusion

4.1   Results

Local Storage
As shown in chapter 3.1 Viber contains a SQLite Database with some xml files which contain
configuration data. Everything is unencrypted and can be viewed fairly easy, although your phone
needs to be rooted or jailbreaked. The implementation between iOS and Android doesn’t differ much.
However the local storage on iOS looks better organized and cleaner. The Viber database contains
all calls logged, address-book and message information. While the xml file(s) contain different
configuration attributes, which are more interesting since it contains hashes and application options.

Transferred Data
The data that is sent on the wire was a lot to analyze. Automatic Protocol Analysis tools were used
to speed this process up but was inadequate to get any definitive structure from the packets. Manual
Reverse Engineering is a long process which requires a lot of experience. Some characteristics of the
protocol and the packets were documented but due to time restrictions the data encryption was not
extensively looked at.
When analyzing a protocol like this, it is important to cover all different angles because the key or
location of the key could be revealed anywhere. Therefore the signaling protocol was analyzed as
well but key material was not found.


4.2   Comparison

In chapter 1.3 could be read about Viber their security policy. Information about other communica-
tion applications could be read in chapter 2.1. This chapter should conclude this research document.
Viber states to comply with the law, protect your right and tries to protect your personal data.
They also say no method is 100% secure. However Viber is not the only one having this kind of
policy. Every policy from the different applications are more or less the same. At least on how they
think what they should do with your personal information.
The encryption policy however does change per application. Most applications try to protect the
kind of encryption they are using. However some to see or have announced one time what kind of
encryption they are using. But most state that since you don’t publish your encryption mechanism
you can’t claim your using encryption. Or as the Kerckhoff principle would say: ‘A cryptosystem
should be secure even if everything about the system, except the key, is public knowledge’.[39] you
can only claim cryptography when you use open mechanisms and publish this.
There is also a big difference on how many exploits have been found in different communication
applications. Some applications are relative new on the market and are not researched much yet.
But you can almost count on it that exploits will be found. Hackers only need time and money. For



                                                 35
Conclusion                                                                                Chapter   4

example reverse engineering the source code can be handy for hackers to find exploits or holes in a
application mechanism.
In the end it’s very difficult to compare different communication services. This since some are older
than others and the older ones are as can be expected more researched. In most of them exploits are
already found. This can be a good thing since services become more aware of the security aspects
of their service. Users don’t instantly become aware of those dangers but when a news item gets
published about an exploit they do.
For Viber we can conclude it uses some kind of encryption but what kind of encryption is unclear.
We have found some exploits as could be read in chapter 3.4. We can at least conclude that messages
are not send in plaintext over the internet. However the Viber database is still unencrypted and
easy accessible as could be read in chapter 3.1. We are confident we could have found more if we
had more time for reverse engineering Viber, what we have found concerning this can be read in
chapters 3.2 & 3.3. But for now we have to conclude that ‘the scrambled is still scrambled’.


4.3   Future Research

Due to lack of time we were not able to get a definitive answer on how the data is actually encrypted.
Apart from this there are some other areas that might be interesting to look at.

   • The protocol also uses Transmission Control Protocol (tcp) to exchange messages which hasn’t
     gotten any attention in this report. Reverse Engineering this stream could reveal other potential
     security risks.

   • If we had more time we would have liked to attach a debugger to the running program so that
     every piece of code used for, i.e. making a call and sending a text message, can be closely
     analysed by settings breakpoints (to pause the program) at specific places. Moreover, with
     an debugger it is also possible to dump the memory used by the program to a file for later
     analysis.

   • Since the application is written in Java it is possible to execute Java class files on a normal
     computer just as long as a Java Virtual Machine (jvm) is installed. Although in the case of
     Viber this is not really useful since many classes depend on other classes, it still could help
     one to determine the output of a method in a class when a certain parameter value is used to
     execute it.




                                                 36
Acronyms                                                                     Appendix   A

A    Acronyms                                os Operating System

                                             pi Protocol Informatics
aes Advanced Encryption Standard
                                             rsa Ron Rivest, Adi Shamir and Leonard Adle-
ap Access Point
                                                 man
apk Application Package File
                                             rtmp Real Time Messaging Protocol
ascii American Standard Code for Information
                                             rtp Real Time Protocol
     Interchange
                                             rtt Round Trip Time
avd Android Virtual Device
                                             sha Secure Hash Algorithm
cifs Common Internet File System
                                             sip Session Initiation Protocol
dna Deoxyribonucleic acid
                                             ssl Secure Sockets Layer
dt Data Type
                                             smb Server Message Block
gnu GNU’s Not Unix
                                             sne Systems and Network Engineering
gps Global Position System
                                             ssn Security of Systems and Networks
gsm Global System for Mobile Communications
                                             tcp Transmission Control Protocol
hmac Hash-based Message Authentication Code
                                             tls Transport Layer Security
http Hypertext Transfer Protocol
                                             udid Unique Device Identifier
https http Secure
                                             udp User Datagram Protocol
ietf Internet Engineering Task Force
                                             voip Voice over ip
im Instant Message
                                             xml Extensible Markup Language
imei International Mobile Equipment Identity

ip Internet Protocol

isp Internet Service Provider

irc Internet Relay Chat

it Information Technology

jvm Java Virtual Machine

mitm Man in the Middle

ms-dos Microsoft Disk Operating System

nat Network Address Translation

                                           37
                                                                                   Appendix   B

B    Bibliography



 [1] D. Etherington, “Viber gives skype a run for its money on iphone,” December 2010. http:
     //gigaom.com/apple/viber-gives-skype-a-run-for-its-money-on-iphone/.

 [2] T. Marco, “Are the messages sent between viber users encrypted?,” June 2011. http://www.
     quora.com/Talmon-Marco-Are-the-messages-sent-between-Viber-users-encrypted.

 [3] T. Marco, “Viber for iphone updated with free text messaging (comment),” April 2011. http:
     //i.tuaw.com/2011/04/01/viber-for-iphone-updated-with-free-text-messaging.

 [4] G. V. Michiel Appelman and J. Bosma, “Viber communication security - project pro-
     posal,” November 2011.    https://www.os3.nl/_media/2011-2012/courses/ssn/viber_
     communication_security.pdf?id=2011-2012.

 [5] Viber, “Viber privacy policy,” July 2011. http://www.viber.com/privacypolicy.html.

 [6] V. H. Desk, “Traffic encryption policy,” 2011.        http://helpme.viber.com/index.php?
     /Troubleshooter/Step/View/3.

 [7] S. L. Garfinkel, “Voip and skype security,” January 2005.               http://skypetips.
     internetvisitation.org/files/VoIP%20and%20Skype.pdf.

 [8] M. Marjalaakso, “Security requirements and constraints of voip,” 2010. http://www.tml.tkk.
     fi/Opinnot/Tik-110.501/2000/papers/marjalaakso/voip.html.

 [9] W.      de  Vries,    “Fout   in    verificatiecheck    whatsapp   maakt     meelezen
     berichten  mogelijk,”     May    2011.            http://tweakers.net/nieuws/74576/
     fout-in-verificatiecheck-whatsapp-maakt-meelezen-berichten-mogelijk.html.

[10] R. Gevers, “Whatsapp security weaknesses,” May 2011. http://rickey-g.blogspot.com/
     2011/05/whatsapp-connection-details.html.

[11] R. Gevers, “Hijack whatsapp with your iphone,” May 2011. http://rickey-g.blogspot.com/
     2011/05/hijack-someone-elses-whatsapp-with-your.html.

[12] WhatsApp, “Whatsapp legal info,” November 2009. http://www.whatsapp.com/legal/.

[13] eBuddy XMS team, “Q&A on eBuddy XMS’ secure connection,” May 2011. http://blog.
     ebuddy.com/index.php/ebuddy-blog/qa-on-ebuddy-xms-secure-connection/.

[14] eBuddy, “Privacy policy,” March 2011. http://www.ebuddy.com/privacy.php.

[15] S. Kovach, “Skype for iphone lets others steal your address book contacts,” September 2011.
     http://articles.businessinsider.com/2011-09-20/tech/30178953_1_skype-ios-app.


                                              38
                                                                                    Appendix   B

[16] A. Greene,     “Skype security flaw can expose user locations,         researchers
     say,”    November     2011.           http://www.techflash.com/seattle/2011/11/
     skype-security-flaw-can-expose-location.html.

[17] T. D. Brown, “Skype for ios has a security flaw,” September 2011. http://lifeonmymobile.
     com/2011/09/20/skype-for-ios-has-a-security-flaw/.

[18] Skype, “Skype privacy policy,” October 2011. http://www.skype.com/intl/en-us/legal/
     privacy/general/.

[19] T. Kemper, “Nimbuzz security tips,” August 2010. http://blog.nimbuzz.com/2010/08/03/
     nimbuzz-security-tips/.

[20] jiah, “Security tips and advice for nimbuzz,” August 2010. http://swiftwares.com/forum/
     viewtopic.php?f=34&t=505.

[21] Redactie,  “Anonymous lekt broncode nederlands "censuurbedrijf",”    July             2011.
     http://www.security.nl/artikel/37723/Anonymous_lekt_broncode_Nederlands_
     %22censuurbedrijf%22.html.

[22] A. U. de Haes, “Broncode nederlandse chatdienst nimbuzz gestolen,” July 2011. http:
     //webwereld.nl/nieuws/107221/broncode-nederlandse-chatdienst-nimbuzz-gestolen.
     html.

[23] Nimbuzz, “Nimbuzz privacy statement,” December 2010. http://www.nimbuzz.com/en/legal/
     privacy-statement.

[24] A. Tridgell, “How Samba was written,” August 2003. http://samba.org/ftp/tridge/misc/
     french_cafe.txt.

[25] R. Savoye, “Reverse Engineering of Proprietary Protocols, Tools and Techniques,” March 2009.
     http://www.youtube.com/watch?v=t3s-mG5yUjY.

[26] M. Beddoe, “Network protocol analysis using bioinformatics algorithms,” 2005. http://www.
     4tphi.net/~awalters/PI/PI.html.

[27] W. Cui, J. Kannan, and H. Wang, “Discoverer: Automatic protocol reverse engineering from
     network traces,” in Proceedings of 16th USENIX Security Symposium on USENIX Security Sym-
     posium, p. 14, USENIX Association, 2007. http://research.microsoft.com/pubs/153196/
     discoverer-security07.pdf.

[28] T. Beardsley, “Manual Protocol Reverse Engineering,” January 2009.   http://www.
     breakingpointsystems.com/community/blog/manual-protocol-reverse-engineering/.

[29] D. D. Trammell, “Automated Protocol Reverse Engineering,” January 2009. http://www.
     breakingpointsystems.com/community/blog/manual-protocol-reverse-engineering/.

[30] Google, “What is android?,”      2011.     http://developer.android.com/guide/basics/
     what-is-android.html.

                                               39
Log                                                                                    Appendix   C

[31] Google, “What is the ndk?,” 2011. http://developer.android.com/sdk/ndk/overview.html.

[32] D. Octeau, W. Enck, and P. McDaniel, “The ded decompiler,” tech. rep., Network and Se-
     curity Research Center, Department of Computer Science and Engineering, Pennsylvania
     State University, University Park, PA, USA, 2010. http://siis.cse.psu.edu/ded/papers/
     NAS-TR-0140-2010.pdf.

[33] N. A. Naeem, “Programmer-friendly decompiled java,” Master’s thesis, McGill Uni-
     versity, 2006.   http://www.sable.mcgill.ca/publications/thesis/masters-nnaeem/
     sable-thesis-2006-masters-nnaeem.pdf.

                                                   ,”
[34] pxb1988@gmail.com, “dex2jar wiki entry éxample´ 2011.            http://code.google.com/p/
     dex2jar/wiki/Example.

[35] Google, “Proguard,”    2011.     http://developer.android.com/guide/developing/tools/
     proguard.html.

[36] Google, “Telephonymanager,” 2011. http://developer.android.com/reference/android/
     telephony/TelephonyManager.html.

[37] Google, “Securerandom,” 2011. http://developer.android.com/reference/java/security/
     SecureRandom.html.

[38] I. Viber Media, “Viber privacy policy,” 2011. http://viber.com/privacypolicy.html.

[39] Wikipedia, “Kerckhoffs principle,”       19th     century.    http://en.wikipedia.org/wiki/
     Kerckhoffs%27s_principle.


C     Log

We haven’t really kept any dates but we all worked on individual parts and collaborated during class.
This accounted for at least 15-20 hours every week.


Michiel Lab set-up, Protocol Reverse Engineering, Packet capturing and analysis.


Jeffrey Lab set-up, Program Code Analysis, Other Weaknesses, Packet capturing.


Gerrie Other Services, Local Storage (DB & configuration) Analysis.




                                                 40

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:15
posted:12/31/2012
language:English
pages:42