IL String Rendering Ignores Types for Read-Only Sections

Aperta
#2,969 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
cpp

Direzione di ricerca

No source files, tests, or entry points are named. Reproduce the issue with an ELF .rodata section or read-only segment, change a string variable to an int or struct, and compare the IL rendering; review related issue 2971. Done means explicitly non-string types no longer render as strings while valid string rendering remains available.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Component: UI Effort: Low Impact: Medium

Version and Platform (required):

  • Binary Ninja Version: 3.0.3233-stable, 3.0.3255-dev
  • OS: Manjaro Linux
  • OS Version: Up to date

Bug Description:
Ascii string rendering in IL ignores type information for data variables in ReadOnlyDataSectionSematics sections, or a segment with read but not write segment flags if no sections are defined. Any reference to an address which contains a valid ascii string, regardless of whether or not that address has been identified to be of type const char[]/char[]/const char */char *, or of some other non string type such as an int, or a struct (with or without a char[] as its first member), will result in the rendering of the string in the IL. See image below for an example. This behavior is primarily a problem with structures in a readOnly section which happen to have a char[] (or otherwise valid ascii) for their first field.

It's also clear that binary ninja does know the correct type for that address, as demonstrated in the image: the struct member accesses are displayed as expected.

This appears to be related to a similar issue, where string rendering is completely disabled when the addresses being referenced reside in a read-write section at the time the view is initialized and loaded. I am still tracking that down though, and will file a separate issue.

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

  1. Open a binary and ensure that there is a section containing ascii strings mapped with ReadOnlyDataSectionSemantics (ELF's .rodata is fine)
  2. Locate a reference to an address of one of these strings, such that the IL is rendering the string
  3. Change the type of the string var to something else, for example an int or struct
  4. Observe that the string is still rendered in the IL

Expected Behavior:
Strings should not be rendered in IL if the types of the underlying variable at the "string" address has been explicitly set to not be a string. I think the behavior to default to string rendering when it seems plausible is fine and in fact very useful, but it needs to be overrideable in cases where it was incorrect (for example in the case of the struct with a char[] as its first member).

Screenshots:
Correct IL, displayed only when world resides in a read/write section
20220215_09h35m14s_grim
Incorrect IL, displayed when world resides in a read-only section
20220215_09h35m53s_grim
Definition of the data variable world
20220215_09h36m26s_grim
Manually redefinition of world to explicitly not have a char[] as it's first member, no change in IL behavior
20220215_09h36m45s_grim

Additional Information:
I'd like to share an example in the form of an x86 ELF bndb file, where I've manually set the .data section to have ReadOnlyDataSectionSemantics for the sake of demonastration; see the first few lines of the main function, just after the call to srand.

Lingua principale
C++
Stelle
1.3k
Fork
298
Merge medio
5g 5h
PR unite (30g)
19

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Vector35/binaryninja-api

Tutte le issue di Vector35/binaryninja-api

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.