More accurate support for lock prefixed instructions
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- cpp
- Área
- compilers, reverse-engineering
Línea de trabajo
Start by locating the HLIL decompiler handling for lock-prefixed instructions, using the assembly and HLIL examples in the issue as the behavioral reference. The change should preserve the interlocked meaning of increment, decrement, compare, and other lock-prefixed operations rather than presenting them as ordinary arithmetic.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
First of all, I want to congratulate anyone who works on BN. I'm evaluating replacing my daily reverse engineering tool (which, I guess anyone who reads this already knows him.) with BN. More than that, I feel like I want to work at Vector35. That is what I really feel about BN. So thank you all for putting this effort into this beautiful project. There are a lot of things already in BN that I want to saw in other tools. But of course there are some other things I want to saw in BN, too! So, here is another one for you... I mean, for us...
Currently, BN's decompiler turns this assembly
004010a0 int32_t list_push(struct list_T* list, struct person_T* person)
004010a3 8b4508 mov eax, dword [ebp+0x8 {list}]
004010a6 83c004 add eax, 0x4
004010a9 f0ff00 lock inc dword [eax]
into this in HLIL view:
004010a0 int32_t list_push(struct list_T* list, struct person_T* person)
004010a6 list->size = list->size + 1
I think it would be more accurate if decompiler make us know that this is an interlocked increment. Maybe something like this?
InterlockedIncrement(&list->size);
There are other variations(decrement, compare etc..) too for sure. Support for all of them in a release would be very pleasant.
- Lenguaje dominante
- C++
- Estrellas
- 1.3k
- Forks
- 298
- Merge medio
- 5 d 5 h
- PR fusionados (30 d)
- 19
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de Vector35/binaryninja-api
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
Vector35/binaryninja-api#8540 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Vector35/binaryninja-api#8516 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
Vector35/binaryninja-api#8503 ·
-
normalize time logs from WARP Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Vector35/binaryninja-api#8446 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Vector35/binaryninja-api#8444 ·
Todos los issues de Vector35/binaryninja-api
Issues similares
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
autowarefoundation/autoware_universe#13413 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
automated-analysis bug memory-safety
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
gazebosim/gz-sensors#662 · 1 comentario ·