Project Topics
Get Complete Project Material File(s) Now! »
Detailed design
In this section, we start by presenting the architecture of our system. Then we move to detail each layer mentioned above in the global design.
System architecture
We explain the schema mentioned above by detailing the different system layers designs.
MVC layers designs
In this section, we start by presenting the data structure that we used in the application. Af-ter that, we expose the design of controller functionalities. Finally, we focus on the application’s view.
Data layer design
In our application, all needed data is centralized in a specific server. Android users have to send logcat and dumpsys messages to this server in order to make them accessible.
As for logcat messages sending, we have taken advantage from « Collimator probe », an android application which was designed and developed by Madynes members. Its main func-tionalities are collecting these logs and sending them to a server for storage.
The Collimator probe is organized under one basic user Interface, the activity Collimato-rActivity, which controls 2 background services .
LocationService : retrieves geolocation information which is added as an extra string to logcat messages.
CollimatorService : collects and sends the logcat messages.
Collecting and sending logs were separated. The collected logs are now stored in a buffer before sending them. The reception of each log by the server is done before sending the next log. This has been possible by the use of TCP( Transmission Control Protocol). If an error occurs when when sending, sent data is removed from the buffer, and sending process is restarted a minute later. The following figure presents the collecting and sending processes performed by the Collimator probe : To store logs sent by users, a dedicated program called Syslog-ng using the data logging standard Syslog has been used for the purpose. It is simply an enhanced syslog daemon whic collects logs from the devices and store them in a MySQL database without any treatment. To store logs sent by users, a dedicated program called Syslog-ng using the data logging standard Syslog has been used for the purpose. It is simply an enhanced syslog daemon which collects logs from the devices and store them in a MySQL database without any treatment.
Tool screenshots
In this section, we depict the achieved work through some screenshots of the application.
Home page : The user has to mention if he wants to get access to the tool as a simple user or an analyst.
Analysts home page : If he is an analyst, a Registration/Authentication view, as shown in figure 4.6, will be displayed.
Analysts registration : If he is a new analyst, he should register before getting access to the tool functionalities.
Devices view : As shown in figure 4.8, the analyst, once authenticated, can consult the list of registered devices and choose one of them in order to explore it.
Applications view : Once the device is chosen, the interface of figure 4.9 will be displayed to give him the possibility to consult the list of applications of that device and choose one of them in order to visualize its behavior.
Application behavior graph : After choosing the application, the analyst can visualize its behavior. The interface of the figure 4.10 permits him to get different information of different components of the given application.
Logcat information interface : The analyst can focus on a single component and get its logcat information. By clicking a single rectangle or choosing from the tree hierarchy, the analyst can have details about a logcat event related to the chosen component. (figure 4.11).
Logcat attributes view : To get attributes values of the chosen element, the analyst has to click one of the set of rectangles representing that element. (figure 4.12).
Dumpsys information view : The analyst can also get dumpsys information about a specific component. Figure 4.13 represents the structure of dumpsys information related to the intents of Facebook appli-cation.
Dumpsys attributes view : The analyst can get different attributes associated to a specific element of the hierarchy. As shown in figure 4.14, he can choose the attribute and click the rectangle associated to it.
Table of contents :
1 Preliminary study
1.1 State of the art
1.1.1 Android environment
1.1.2 Mobile malware
1.1.3 Android application components
1.1.4 Android logging system
1.1.4.1 Logcat
1.1.4.2 Dumpsys
1.2 Study of existing solutions
1.2.1 Androguard
1.2.2 DroidBox
1.3 Project approach
1.4 Conclusion
2 Analysis and specification of requirements
2.1 Requirements analysis
2.1.1 Functional requirements
2.1.2 Non functional requirements
2.2 Use cases
2.2.1 General use case
2.2.2 Detailed use case
2.3 Sequence diagrams :
2.3.1 Scenario of application visualization by a simple user :
2.3.2 Scenario of application visualization by an analyst
2.4 Conclusion
3 Design and structure
3.1 Global design
3.2 Detailed design
3.2.1 System architecture
3.2.2 MVC layers designs
3.2.2.1 Data layer design
3.2.2.2 Controller layer design
3.2.2.3 View layer design
3.3 Conclusion
4 Implementation details
4.1 Work environment
4.1.1 Hardware environment
4.1.2 Software environment
4.2 Development process
4.2.1 Logs analysis
4.2.2 Logs visualization
4.2.3 Graphs interpretation
4.3 Tool screenshots
4.4 Conclusion
Bibliography
