1. Qu'est-ce que SpyNote5.0 ?
SpyNote est un outil utilisé pour créer des programmes malveillants Android. Ses fonctions sont très attrayantes, notamment la lecture de contacts, l'enregistrement, l'exécution de commandes, la gestion d'applications, l'enregistrement de claviers, le positionnement GPS, etc. Ces fonctionnalités jouent un rôle clé lors de la recherche de logiciels malveillants Android. Nous pouvons avoir une première compréhension de son utilisation à travers une série d'articles, "Tutoriel de gestion à distance de l'outil graphique SpyNote V5.0 sur téléphone Android", "Attention, l'outil cheval de Troie Android SpyNote est gratuit !" La surveillance à distance est si simple", "Attention, la télécommande Android (spynote) a été mise à jour..." et ainsi de suite.
2. Préparer les outils
Peu de gens sont intéressés par l'analyse inverse de SpyNote5.0 Client_APK Ci-dessous, je présenterai brièvement l'utilisation des outils, puis lancerai le processus d'analyse inverse.
1. SpyNote5.0
Adresse de téléchargement : https://github.com/soDLL/SpyNote OU https://github.com/miladzero/SpyNote
2. https://github.com/skylot/jadx/releases
3, androidkiller
Adresse de téléchargement : https://www.guguzhu.com/soft/270509.html
3. Analyse technique
Nous commençons à analyser Client_APK. Nous aimons généralement faire glisser le programme APK généré par le client dans Androidkiller. Une fois le programme glissé dans AndroidKiller, il sera automatiquement désassemblé et générera des résultats d'analyse du programme.
À gauche, les autorisations Activité, Récepteur, Service et application (Utilisations-Permisson) sont classées selon la relation d'héritage. Vous pouvez voir que le client nécessite de nombreuses autorisations applicatives. Sur le côté droit se trouvent la fenêtre d'assemblage du smail et l'établi. Cet outil peut afficher clairement les autorisations et diverses relations d'héritage, mais en raison de la version inférieure de l'outil, la restauration du code n'est pas suffisamment complète. J'ai changé l'outil et utilisé jadx-gui, puis j'ai commencé l'ingénierie inverse et importé Client_APK.
Nous pouvons voir trois packages, à savoir android.support, con.eset.ems2.gp, yps.eton.application. Parmi eux, android.support est le package de support Android, qui comprend les versions basses, v4 et v7, et con.eset.ems2.gp est le package de configuration qui contient l'hôte, le nom_client et d'autres informations. il faut analyser.
Ouvrez yps.eton.application, nous pouvons voir 14 classes. Comme de nombreux codes doivent être analysés, certains codes clés sont analysés de manière ciblée.
Il ressort de la structure d'analyse précédente d'Androidkiller que les classes d'écriture A, F, G et k héritent de Service, et Service représente une exécution continue en arrière-plan dans le système Android. Autant deviner ce qui pourrait se trouver dans Client_APK et qui doit être exécuté en continu ? Peut-être que les objets clés seront exécutés, contrôlés, surveillés, multithreads, etc. Notre analyse se concentre sur certaines de ses fonctions et sur la manière d’identifier le trafic.
3.1 Analyse de démarrage de l'exécution de la commande
Nous commençons par la méthode A, démarrons d'abord le service, puis parcourons l'objet R et obtenons le troisième élément, s'il est égal à 1, exécutons la fonction j(). Sinon, démarrez le service après avoir déterminé si a() a été instancié. Il continuera ensuite à déterminer si j() dispose des autorisations root.
Continuez à regarder j(). Après avoir exécuté la commande su dans j(), écrivez Do I have root ? dans le fichier /system/sd/temporary.txt et jugez s'il dispose des autorisations root.
Ensuite, regardez h(), qui utilise le multi-threading pour obtenir les paramètres de configuration stockés dans l'objet R, et utilise des boucles et des sockets pour renvoyer des informations.
3.2 Analyse fonctionnelle partielle de l'application d'encodage Base64
En examinant la liste d'importation de l'objet A, nous avons constaté qu'elle contient android.util.Base64, indiquant que l'encodage base64 est utilisé pendant le fonctionnement. Recherchez ensuite le mot-clé Base64 et vous verrez que Base64 est enveloppé dans ((BitmapDrawable) applicationIcon).getBitmap(), qui est en fait l'icône de l'application à l'intérieur. Le client transmet certaines informations via la segmentation c0c1c3a2c0c1c se terminant par 9xf89fff9xf89 et utilise fxf0x4x4x0fxf pour les informations et options d'exception.
<br>
<br>
public void k() { new Thread(new Runnable() { public void run() { String str; try { StringBuffer stringBuffer = new StringBuffer(); PackageManager packageManager = A.this.getApplicationContext().getPackageManager(); for (ApplicationInfo applicationInfo : packageManager.getInstalledApplications(128)) { if (packageManager.getLaunchIntentForPackage(applicationInfo.packageName) != null && !packageManager.getLaunchIntentForPackage(applicationInfo.packageName).equals("")) { essayer { Date date = nouveau Date(packageManager.getPackageInfo(applicationInfo.packageName, 4096).firstInstallTime); String str2 = packageManager.getLaunchIntentForPackage(applicationInfo.packageName) != null (applicationInfo.flags & 1) == 1 ? ""; ApplicationIcon dessinable = packageManager.getApplicationIcon(applicationInfo.packageName); Chaîne str3 = nouvelle chaîne(); if (applicationIcon != null) { Bitmap bitmap = ((BitmapDrawable) applicationIcon).getBitmap(); ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); bitmap.compress(CompressFormat.JPEG, 50, byteArrayOutputStream); str = Base64.encodeToString(byteArrayOutputStream.toByteArray(), 2); } else { str = str3; } stringBuffer.append(packageManager.getApplicationLabel(applicationInfo) + "c0c1c3a2c0c1c" + applicationInfo.packageName + "c0c1c3a2c0c1c" + str + "c0c1c3a2c0c1c" + "c0c1c3a2" c0c1c" + date.toString() + "c0c1c3a2c0c1c" + A.this. getPackageName() + "9xf89fff9xf89"); } catch (NameNotFoundException e) { A.this.h("applicationsfxf0x4x4x0fxf[My/Exception]" + e.getMessage().toString()); } } A.this.h("applicationsfxf0x4x4x4x0fxf" + stringBuffer.toString()); } catch (Exception e2) { A.this.h("applicationsfxf0x4x4x0fxf[My/Exception]" + e2.getMessage().toString()); } } }).commencer(); }
3.3 信息获取部分功能分析
Object A contient une méthode b très longue, qui utilise trop de branches d'instruction switch case, provoquant des exceptions lors du démontage. Il n'est pas difficile de voir à partir des commentaires que l'essentiel de la logique d'obtention d'informations y est mis en œuvre. Par exemple : informations sur l'appareil, informations système, informations Sim, informations WIFI, etc., y compris les fonctions promues par l'outil.
Il y a certaines choses à noter dans la réécriture de la méthode b, qui est utilisée pour obtenir le chemin de stockage. Le délimiteur des informations sur le chemin de transmission utilise e1x1114x61114e. Le séparateur d'informations sur le nom de fichier utilise -1c0c1c3a2c0c1c-1c0c1c3a2c0c1c-1c0c1c3a2c0c1c. Ces informations peuvent être utilisées pour déterminer plus précisément l'opération du client lors de la livraison.
4. Résumé
La mise en œuvre de chaque fonction peut être vue au cours du processus d'analyse. Lorsque le client utilise une transmission non cryptée et codée en base, la caractéristique la plus notable est l'apparition de délimiteurs. Le comportement de transmission du client peut être évalué efficacement grâce au programme. Le paquet est donc capturé pendant le processus de transmission.
Les symboles délimiteurs et le contenu de l'encodage base64 sont clairement visibles sur l'image. Pour cela, nous pouvons écrire des règles dans Snort pour l'identification. Exemple d'identification :
alert tcp any any -> any any (contenu : "fxf0x4x4x0fxf"; sid:1; msg:SpyNote5.0 Client. ;)
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!