README

trueseeing est un scanner de vulnérabilités rapide, précis et résilient pour les applications iOS/Android. Nous opérons au niveau de la machine virtuelle Dalvik pour Android – c'est-à-dire que nous ne nous soucions pas de savoir si l'application cible est obscurcie ou non.

Capacité

Actuellement, nous pouvons :

• Analyser automatiquement une application à la recherche de vulnérabilités, en produisant un rapport au format HTML/JSON/texte (voir ci-dessous)
• Manipuler l'application pour une analyse plus facile : par exemple, activer le bit de débogage, activer la sauvegarde complète, désactiver l'épinglage TLS, modifier le niveau d'API cible, injecter frida-gadget, etc.
• Examiner l'application pour obtenir des informations générales
• Copier/importer des données de l'application via l'interface de débogage
• Rechercher certains appels/constantes/sput/iput
• Déduire les constantes/ensembles de types pour les arguments d'une opération
• Analyser les appels API/privés pour les codes natifs (NB : vous avez besoin de ts2-disasm-ghidra)
• Analyser les applications iOS pour les vulnérabilités de base (NB : vous avez besoin de ts2-disasm-ghidra)
• Attacher des scripts frida
• Fournir une session interactive frida
• Tracer les appels
• etc.

Installation

Conteneurs

REMARQUE :

• Depuis la version 2.1.9, nous sommes sur ghcr.io. (Docker Hub est quelque peu déprécié)
• Nécessite adbd sur l'hôte pour contrôler les appareils.

Nous fournissons des conteneurs que vous pouvez utiliser directement comme suit ; c'est désormais la méthode recommandée, et la seule si vous êtes sous Windows, pour exécuter :

$ docker run --rm -v $(pwd):/out -v ts2:/cache ghcr.io/alterakey/trueseeing

Si vous souhaitez exécuter sans état, omettez le montage du volume sur /cache (déconseillé pour une utilisation quotidienne ; voir aussi #254) :

$ docker run --rm -v $(pwd):/out ghcr.io/alterakey/trueseeing

Installation avec uv

Alternativement, vous pouvez installer notre package avec uv comme suit. En particulier, la forme d'installation uv tool install peut être utile pour les extensions (voir ci-dessous), car elle leur accorde la plus grande liberté. N'oubliez pas que vous avez besoin d'un JRE et du SDK Android (facultativement ; pour interagir avec les appareils) :

$ uvx trueseeing

$ uv tool install trueseeing
$ trueseeing

Installation avec pip (déprécié)

Bien sûr, vous pouvez toujours utiliser le bon vieux pip si nécessaire :

$ pip install trueseeing

Utilisation

Mode interactif

Vous pouvez analyser/analyser/corriger, etc. les applications de manière interactive – ce qui en fait le choix idéal pour une analyse manuelle :

$ trueseeing target.apk
[+] trueseeing x.y.z
ts[target.apk]> ?
...
ts[target.apk]> i                      # afficher les informations génériques
...
ts[target.apk]> pf AndroidManifest.xml # afficher le fichier manifeste
...
ts[target.apk]> a                      # analyser également les ressources
...
ts[target.apk]> /s quelquechose        # rechercher du texte
...
ts[target.apk]> as                     # scanner
...
[+] terminé, 6403 problèmes trouvés (174.94 sec.)
ts[target.apk]> gh report.html

Mode batch

Nous acceptons une commande en ligne (-c) ou un fichier de script (-i) à exécuter avant de vous donner l'invite, ainsi que la possibilité de quitter immédiatement au lieu d'afficher l'invite (-q ; nous n'avons pas besoin d'un tty dans ce mode !).

Vous pouvez utiliser ces fonctionnalités pour effectuer une analyse par lots, comme suit par exemple pour vider les résultats directement sur stderr :

$ trueseeing -eqc 'as' target.apk

Pour générer un rapport au format HTML :

$ trueseeing -eqc 'as;gh report.html' target.apk

Pour générer un rapport au format JSON :

$ trueseeing -eqc 'as;gj report.json' target.apk

Pour obtenir le rapport généré sur stdout, omettez le nom de fichier dans la commande g* finale :

$ trueseeing -eqc 'as;gh' target.apk > report.html
$ trueseeing -eqc 'as;gj' target.apk > report.json

Mode d'analyse non interactif (déprécié)

Traditionnellement, vous pouvez analyser les applications avec la ligne de commande suivante pour obtenir les résultats listés sur stderr :

$ trueseeing --scan target.apk

Pour générer un rapport au format HTML :

$ trueseeing --scan --scan-output report.html target.apk
$ trueseeing --scan --scan-report=html --scan-output report.html target.apk

Pour générer un rapport au format JSON :

$ trueseeing --scan --scan-report=json --scan-output report.json target.apk

Pour obtenir le rapport généré sur stdout, spécifiez '-' comme nom de fichier :

$ trueseeing --scan --scan-output - target.apk > report.html
$ trueseeing --scan --scan-report=html --scan-output - target.apk > report.html
$ trueseeing --scan --scan-report=json --scan-output - target.apk > report.json

Utilisations avancées

Extensions

Vous pouvez écrire vos propres commandes et signatures en tant qu'extensions. Les extensions sont placées sous /ext (conteneurs) ou ~/.trueseeing2/extensions/ (uv/pip). Alternativement, vous pouvez distribuer vos extensions sous forme de wheels. Nous fournissons des informations de type afin que vous puissiez non seulement vérifier les types de vos extensions avec zuban, mais aussi obtenir une assistance décente des IDE. Voir la section Détails pour plus de détails.

Construction

Vous pouvez le construire comme suit :

$ docker build -t trueseeing https://github.com/alterakey/trueseeing.git#main

Pour construire des wheels, vous pouvez le faire avec flit, comme suit :

$ flit build

Pour le bidouiller, vous devez créer un environnement de construction approprié. Avec uv, vous pouvez simplement faire :

$ git clone https://github.com/alterakey/trueseeing.git wc
$ uv sync --locked --dev
$ (... bidouiller ...)
$ uv run trueseeing ...                                    # pour exécuter
$ uv run zuban check trueseeing && uv run ruff trueseeing  # pour valider
Success: no issues found in XX source files
$ uv run flit build                                        # pour construire (wheel)
$ docker build -t trueseeing .                             # pour construire (conteneur)

Avec pip, pour en créer un, commencez par configurer un venv, installez flit et les chaînes d'outils de validation (zuban et ruff) dedans, puis faites tirer les dépendances par flit. En bref, faites quelque chose comme ceci :

$ git clone https://github.com/alterakey/trueseeing.git wc
$ python3 -m venv wc/.venv
$ source wc/.venv/bin/activate
(.venv) $ pip install flit zuban ruff
(.venv) $ flit install --deps=develop -s
(.venv) $ (... bidouiller ...)
(.venv) $ trueseeing ...                                   # pour exécuter
(.venv) $ zuban check trueseeing && ruff check trueseeing  # pour valider
Success: no issues found in XX source files
(.venv) $ flit build                                       # pour construire (wheel)
(.venv) $ docker build -t trueseeing .                     # pour construire (conteneur)

Détails

Classes de vulnérabilités

Actuellement, nous pouvons détecter les classes de vulnérabilités suivantes, en grande partie celles couvertes par OWASP Mobile Top 10 - 2016 :

• Utilisation inappropriée de la plateforme (M1)

  • Débogable
  • Publication involontaire d'activités, services, fournisseurs de contenu, récepteurs de diffusion

• Données non sécurisées (M2)

  • Sauvegardable (c'est-à-dire sensible à l'attaque par sauvegarde)
  • Permissions de fichiers non sécurisées
  • Journalisation

• Communications non sécurisées (M3)

  • Absence d'épinglage (c'est-à-dire sensible à l'attaque d'interception TLS)
  • Utilisation de HTTP en texte clair
  • WebViews falsifiables

• Cryptographie insuffisante (M5)

  • Phrase de passe/clés secrètes codées en dur
  • Chiffrements Vernam avec clés statiques
  • Utilisation du mode ECB

• Problèmes de qualité du code client (M7)

  • WebViews réflexibles (c'est-à-dire que les XSS dans ces vues devraient être escaladables en exécutions de code à distance via la réflexion JS)
  • Utilisation d'une politique non sécurisée sur les contenus mixtes

• Falsification de code (M8)

  • Certificats codés en dur

• Ingénierie inverse (M9)

  • Absence d'obscurcissement

API d'extension

Notre API d'extension se trouve sous le package trueseeing.api. Comme nous fournissons des informations de type avec celle-ci, votre IDE vous assistera lors de l'écriture de vos extensions. Assurez-vous simplement que son (ou celui de son serveur de langage) PYTHONPATH couvre le venv où se trouve notre package ; voir uv tool list --show-paths si vous l'avez installé avec uv tool install. Si vous l'avez installé avec uvx, envisagez de le réinstaller avec uvx install. Si vous l'avez installé avec pip, vous savez déjà où il se trouve.

Commandes

Pour définir de nouvelles commandes, implémentez trueseeing.api.Command et publicisez-les.

La classe suivante fournira une commande d'exemple en tant que t, par exemple :

from typing import TYPE_CHECKING
from trueseeing.api import Command
from trueseeing.core.ui import ui
if TYPE_CHECKING:
  from trueseeing.api import CommandMap, CommandPatternMap, ModifierMap, OptionMap, ConfigMap

class MyCommand(Command):
  @staticmethod
  def create() -> Command:
    return MyCommand()

  def get_commands(self) -> CommandMap:
    return {'t':dict(e=self._test, n='t', d='commande exemple')}

  def get_command_patterns(self) -> CommandPatternMap:
    return dict()

  def get_modifiers(self) -> ModifierMap:
     return dict()

  def get_options(self) -> OptionMap:
    return dict()

  def get_configs(self) -> ConfigMap:
    return dict()

  async def _test(self) -> None:
    ui.info('hello world')

Signatures

Pour définir de nouvelles signatures, implémentez trueseeing.api.Signature et publicisez-les.

La classe suivante fournira un détecteur d'exemple en tant que my-sig, par exemple :

from typing import TYPE_CHECKING
from trueseeing.api import Signature
if TYPE_CHECKING:
  from trueseeing.api import SignatureMap, ConfigMap

class MySignature(Signature):
  @staticmethod
  def create() -> Signature:
    return MySignature()

  def get_sigs(self) -> SignatureMap:
    return {'my-sig':dict(e=self._detect, d='signature exemple')}

  def get_configs(self) -> ConfigMap:
    return dict()

  async def _detect(self) -> None:
    self._helper.raise_issue(
      self._helper.build_issue(
        sigid='my-sig',
        title='hello world',
        cvss='CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N/',
      )
    )

Formats de fichiers

Pour définir de nouveaux formats de fichiers, implémentez d'abord des Context (classes abstraites) pour vos formats, puis implémentez trueseeing.api.FileFormatHandler pour créer et retourner leurs instances, et publicisez-les.

La classe suivante fournira le support des fichiers APK sous le type nommé apk2, par exemple :

from typing import TYPE_CHECKING
from trueseeing.api import FileFormatHandler
from trueseeing.core.android.context import APKContext

if TYPE_CHECKING:
  from typing import Optional, Set
  from trueseeing.api import FormatMap, ConfigMap
  from trueseeing.core.context import Context, ContextType

class MyAPKContext(APKContext):
  # Utilisez un type de contexte différent
  def _get_type(self) -> Set[ContextType]:
    return {'apk2'}

class APKFileFormatHandler(FileFormatHandler):
  @staticmethod
  def create() -> FileFormatHandler:
    return APKFileFormatHandler()

  def get_formats(self) -> FormatMap:
    return {'apk2':dict(e=self._handle, r=r'\.apk$', d='format de fichier exemple', t=None)}  # si ce gestionnaire peut suggérer un type de contexte d'appareil, publicisez-le dans t

  def get_configs(self) -> ConfigMap:
    return dict()

  def _handle(self, path: str) -> Optional[Context]:
    return MyAPKContext(path)

Ensuite, assurez-vous de vérifier le type du contexte dans vos signatures, afin qu'elles soient ignorées sur les contextes non pris en charge :

context = self._helper.get_context().require_type('apk2')

En cas de succès, require_type(...) tentera de les convertir vers le bas vers les types appropriés pour votre commodité.

Mais par conception, cela ne fonctionne que pour les types connus (actuellement, le apk). Donc, si vous définissez une interface détaillée dans vos nouvelles classes de contexte comme nous le faisons pour le type apk, vous devez effectuer une conversion vers le bas ici, c'est-à-dire :

context: MyAPKContext = self._helper.get_context().require_type('apk2')  # type:ignore[assignment]

Il est possible de définir plusieurs formats correspondant au même motif. Nous évaluons les motifs dans l'ordre du plus strict (c'est-à-dire long) au moins strict. Vous utilisez le commutateur -F pour forcer un format à utiliser avec le fichier cible, par ex. :

$ trueseeing -F apk2 target.apk

Prérequis de package

Les extensions peuvent être : a) tout package placé sous /ext (conteneur) ou ~/.trueseeing2/extensions (pip), ou b) tout module installé nommé avec le préfixe trueseeing_ext0_.

Origine du nom du projet ?

Le sort de D&D, Vraie Vision.