Please use this identifier to cite or link to this item: http://dspace.dtu.ac.in:8080/jspui/handle/repository/19109
Full metadata record
DC FieldValueLanguage
dc.contributor.authorKUMAR, NIRAJ-
dc.date.accessioned2022-06-07T06:10:40Z-
dc.date.available2022-06-07T06:10:40Z-
dc.date.issued2018-05-
dc.identifier.urihttp://dspace.dtu.ac.in:8080/jspui/handle/repository/19109-
dc.description.abstractAndroid eco system works in two steps as far as an application developer is concerned. In the first step, developers design and develop an Android app and subsequently publish it on Google Play Store either as paid apps or with some advertisements to earn monetary benefit or sometimes as free app just for building user base. Besides the bona fide Android ecosystem, there is a parallel dark world of malicious attackers who repackage other developer's application (Free apps available in Play Store or other app stores) and publish it with their own name. Alternatively, they add advertisements with their own bank accounts or even add malicious code and use it for their own benefit. In a similar fashion, malicious attackers embed malware payload into the original applications so as to gain control of the mobile devices on which they are running to retrieve the private data of the user, stealthily read or send SMS messages to premium rate numbers, read banking credentials and so on. Although there are many identification methods which have been used traditionally to detect these repackaged applications existing in various Android app stores. However, it is not always effective to analyse any new application. Repackaged apps are a serious vulnerability these days in Android phones. Various threat mitigation measures have been devised like watermarking in case of rooted device. But, a defence mechanism that prohibits repackaged apps from running on a user device (non-rooted device) is not common. Our repackage-proofing technique for Android apps is trustworthy and covert. Repackaged apps present considerable challenge to the security and privacy of smartphone users. But fortunately such apps can be made to crash (randomly crash to confuse attackers) using keystore check as well as permissions added in repackaged code. Even other techniques like code obfuscation using ProGuard tool are helpful. It does not require any change at the Framework or System level. Private key used to sign the apk is with the original developer. Any app which is installed in an Android system need to pass signature validation. PackageManager API reads an apk and extracts the app information. It then saves the information in three different files on device path /data/system. Out of these three files, the most important is packages.xml. It contains key information like names, code paths, public keys, permissions, etc., 2 | P a g e for all the installed apps. PackageManager API is used to retrieve Kr from the file. We split this Kr value into 8 equal parts and store it as constants in different classes. At runtime, we merge these parts to recreate Kr and compare it with Kr value returned by making use of PackageManager. For repackaged apps as signing key has changed, the two Kr values will be different.en_US
dc.language.isoenen_US
dc.relation.ispartofseriesTD-5692;-
dc.subjectANDROID APPen_US
dc.subjectREPACKAGING DETECTIONen_US
dc.subjectSIGNING CERTIFICATEen_US
dc.subjectPERMISSIONS COMPARISONen_US
dc.titleANDROID APP REPACKAGING DETECTION USING SIGNING CERTIFICATE AND PERMISSIONS COMPARISONen_US
dc.typeThesisen_US
Appears in Collections:M.E./M.Tech. Computer Engineering

Files in This Item:
File Description SizeFormat 
Niraj Kumar M.Tech..pdf1.45 MBAdobe PDFView/Open


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.