Dex DEBUG_INFO Format

Question

Tout en regardant un fichier dex, je remarque que dans debug_info_item associée à chaque code_item, il est possible d'avoir:

• DBG_END_LOCAL sans DBG_START_LOCAL avec le même registre avant qu'il
• DBG_START_LOCAL pour un registre qui a déjà un nom d'information de débogage défini et pas encore fermé (bien que cela arrive beaucoup plus rarement)

Je ne comprends pas comment je suis supposé analyser ces cas. Y at-il quelque chose que je ne comprends pas sur le format debug_info_item (https://source.android.com/devices/tech/dalvik/dex-format.html)?

Aussi, pour vous assurer, suis-je raison que:

• Les instructions DBG_START_LOCAL et DBG_END_LOCAL définissent un nom de débogage juste pour les instructions contenues dans la plage d'adresses, et une instruction jump de cette gamme ferait le nom disparaît, même si le pointeur d'instruction ne passe pas par l'adresse pointée par DBG_END_LOCAL
• Un registre est utilisé pour une seule variable, et il ne devrait pas y avoir différents noms de débogage pour le même registre à l'intérieur de la même fonction

Answer 1

Les registres de paramètres sont tous implicitement locaux, vous pouvez donc avoir un DBG_END_LOCAL sans DBG_START_LOCAL pour un registre de paramètres. Dans le cas d'un DBG_START_LOCAL pour un local "existant", j'imagine que vous venez de terminer implicitement le local précédent et de démarrer le nouveau local. Mais gardez à l'esprit que les informations de débogage sont à titre informatif seulement. Il n'y a rien qui vérifie qu'il est structuré correctement, ou a même vraiment un sens. par exemple. un obfuscator peut ajouter des informations de déboguage insensées sans que le fichier dex échoue à la vérification lorsqu'il est utilisé.

Par exemple, j'ai récemment fixed a bug in baksmali lié à des locals de début/fin pour des valeurs de registre qui étaient hors plage pour cette méthode.