Mémoire numérisé par la Direction des bibliothèques de l'Université de Montréal.

La modernisation logicielle est un domaine en plein essor du fait du vieillissement des technologies datant des années 1960, tel que COBOL ou FORTRAN. Aujourd'hui, bon nombre de ces applications sont toujours en service du fait de leur criticité. Ce sont elles qui continuent d'assurer le bon fonctionnement du système d'information de l'entreprise. Face à l'arrivée en force de technologies récentes de type Cloud ou Mobile, il devient urgent de les moderniser. Toutefois, près de deux projets de modernisation sur trois échouent à cause du manque ou la perte de documentation de l'application, la complexité du logiciel (qui lui n'a cessé de grandir avec le temps), la perte des connaissances techniques (les jeunes développeurs n'ont jamais étudié ces anciennes technologies), tout cela couplé à un manque d'outils et de méthodes industrielles. Face à ce constat implacable, cette thèse suggère une solution pour l'industrialisation du processus de modernisation à travers l'utilisation de l'Ingénierie Dirigée par les Modèles (IDM), notamment en prenant pour base les métamodèles issus de l'initiative Architecture Driven Modernisation de l'OMG. Nous montrons qu'il est ainsi possible d'automatiser une majorité du processus du fait de l'utilisation de métamodèles pivots technologiquement neutres, ainsi que l'utilisation d'une série d'outils permettant d'obtenir une automatisation des tâches de migration de l'application. Nous proposons également de rendre cette solution adaptable à n'importe quel langage légataire au travers d'une chaîne de modernisation paramétrable via l'utilisation d'un moteur de transformation dédié offrant des mécanismes d'extensibilité et de réutilisabilité. Pour terminer, nous illustrons l'ensemble des idées développées dans cette thèse sur l'exemple concret d'une application codée en COBOL. / Software modernization is a fast-growing sector due to the aging technologies from the 1960s, such as COBOL or FORTRAN. Nowadays, many of these applications are still being used because of their criticality. These applications allow companies to maintain their information system. But to face the arrival of newer technologies and platforms, like Cloud or Mobile, companies must modernize their systems to deliver the same services and also develop new ones in order to compete. However, nearly two out of three modernization projects fail because of the lack or the loss of applications documentation, the complexity of the software (that has continued to grow over time), the loss of technical knowledge (the junior developers have never studied these ancient technologies), plus a lack of tools and industrial methods. Faced with this relentless observation, this thesis suggests a solution to the industrialization process of modernization through the use of Model Driven (IDM) Engineering, especially by using metamodels base from Driven Architecture Modernization of the OMG. We therefore demonstrate that it is possible to automate the process thanks to technologically neutral metamodels and by using a set of tools to get the automation of application migration tasks. We also propose to have this solution adapted to any languages through a configurable chain of modernization by using a dedicated processing engine that provides scalability and reusability mechanisms. Finally, we illustrate the ideas developed in this thesis in the concrete case of a coded COBOL application.

Mémoire numérisé par la Direction des bibliothèques de l'Université de Montréal.

Les smartphones sont devenus omniprésents dans notre vie quotidienne à cause des options qu'ils proposent. Aujourd'hui, Android est installé sur plus de 80% des smartphones. Les applications mobiles recueillent une grande quantité d'informations sur l'utilisateur. Par conséquent, Android est devenu une cible préférée des cybercriminels. Comprendre le fonctionnement des malwares et comment les détecter est devenu un défi de recherche important. Les malwares Android tentent souvent d'échapper à l'analyse statique en utilisant des techniques telles que l'obfuscation et le chargement dynamique du code. Des approches d'analyse ont été proposées pour exécuter l'application et surveiller son comportement. Néanmoins, les développeurs des malwares utilisent des bombes temporelles et logiques pour empêcher le code malveillant d'être exécuté sauf dans certaines circonstances. Par conséquent, plus d'actions sont requises pour déclencher et surveiller leurs comportements. Des approches récentes tentent de caractériser automatiquement le comportement malveillant en identifiant les endroits du code les plus suspicieux et en forçant leur exécution. Elles se basent sur le calcul des graphes de flot de contrôle (CFG) qui sont incomplets, car ils ne prennent pas en considération tous les types de chemins d'exécution. Ces approches analysent seulement le code d'application et ratent les chemins d'exécution générés quand l'application appelle une méthode du framework, qui appelle à son tour une autre méthode applicative. Nous proposons GPFinder, un outil qui extrait automatiquement les chemins d'exécution qui mènent vers les endroits suspicieux du code, en calculant des CFG qui incluent les appels interprocéduraux explicites et implicites. Il fournit aussi des informations clés sur l'application analysée afin de comprendre comment le code suspicieux a été injecté dans l'application. Pour valider notre approche, nous utilisons GPFinder pour étudier une collection de 14224 malwares Android. Nous évaluons que 72,69% des échantillons ont au moins un endroit suspicieux du code qui n'est atteignable qu'à travers des appels implicites. Les approches de déclenchement actuelles utilisent principalement deux stratégies pour exécuter une partie du code applicatif. La première stratégie consiste à modifier l'application excessivement pour lancer le code ciblé sans faire attention à son contexte originel. La seconde stratégie consiste à générer des entrées pour forcer le flot de contrôle à prendre le chemin désiré sans modifier le code d'application. Cependant, il est parfois difficile de lancer un endroit spécifique du code seulement en manipulant les entrées. Par exemple, quand l'application fait un hachage des données fournies en entrée et compare le résultat avec une chaîne de caractères fixe pour décider quelle branche elle doit prendre. Clairement, le programme de manipulation d'entrée devrait inverser la fonction de hachage, ce qui est presque impossible. Nous proposons TriggerDroid, un outil qui a deux buts : forcer l'exécution du code suspicieux et garder le contexte originel de l'application. Il fournit les événements framework requis pour lancer le bon composant et satisfait les conditions nécessaires pour prendre le chemin d'exécution désiré. Pour valider notre approche, nous avons fait une expérience sur 135 malwares Android de 71 familles différentes. Les résultats montrent que notre approche nécessite plus de raffinement et d'adaptation pour traiter les cas spéciaux dus à la grande diversité des échantillons analysés. Finalement, nous fournissons un retour sur les expériences que nous avons conduites sur différentes collections, et nous expliquons notre processus expérimental. Nous présentons le dataset Kharon, une collection de malwares Android bien documentés qui peuvent être utilisés pour comprendre le panorama des malwares Android. / The last years have known an unprecedented growth in the use of mobile devices especially smartphones. They became omnipresent in our daily life because of the features they offer. They allow the user to install third-party apps to achieve numerous tasks. Smartphones are mostly governed by the Android operating system. It is today installed on more than 80% of the smartphones. Mobile apps collect a huge amount of data such as email addresses, contact list, geolocation, photos and bank account credentials. Consequently, Android has become a favorable target for cyber criminals. Thus, understanding the issue, i.e., how Android malware operates and how to detect it, became an important research challenge. Android malware frequently tries to bypass static analysis using multiple techniques such as code obfuscation and dynamic code loading. To overcome these limitations, many analysis techniques have been proposed to execute the app and monitor its behavior at runtime. Nevertheless, malware developers use time and logic bombs to prevent the malicious code from executing except under certain circumstances. Therefore, more actions are needed to trigger it and monitor its behavior. Recent approaches try to automatically characterize the malicious behavior by identifying the most suspicious locations in the code and forcing them to execute. They strongly rely on the computation of application global control flow graphs (CFGs). However, these CFGs are incomplete because they do not take into consideration all types of execution paths. These approaches solely analyze the application code and miss the execution paths that occur when the application calls a framework method that in turn calls another application method. We propose in this dissertation a tool, GPFinder, that automatically exhibits execution paths towards suspicious locations in the code by computing global CFGs that include edges representing explicit and implicit interprocedural calls. It also gives key information about the analyzed application in order to understand how the suspicious code was injected into the application. To validate our approach, we use GPFinder to study a collection of 14,224 malware samples, and we evaluate that 72.69% of the samples have at least one suspicious code location which is only reachable through implicit calls. Triggering approaches mainly use one of the following strategies to run a specific portion of the application's code: the first approach heavily modifies the app to launch the targeted code without keeping the original behavioral context. The second approach generates the input to force the execution flow to take the desired path without modifying the app's code. However, it is sometimes hard to launch a specific code location just by fuzzing the input. For instance, when the application performs a hash on the input data and compares the result to a fixed string to decide which branch of the condition to take, the fuzzing program should reverse the hashing function, which is obviously a hard problem. We propose in this dissertation a tool, TriggerDroid, that has a twofold goal: force the execution of the suspicious code and keep its context close to the original one. It crafts the required framework events to launch the right app component and satisfies the necessary triggering conditions to take the desired execution path. To validate our approach, we led an experiment on a dataset of 135 malware samples from 71 different families. Results show that our approach needs more refinement and adaptation to handle special cases due to the highly diverse malware dataset that we analyzed. Finally, we give a feedback on the experiments we led on different malware datasets, and we explain our experimental process. Finally, we present the Kharon dataset, a collection of well documented Android malware that can be used to understand the malware landscape.

No description available.