Closed SteinsGatep001 closed 2 years ago
@SteinsGatep001 sorry for the late response, this sled under my radar.
It seems that there is a mismatch between the string ID used by Avatar2 for ARM and the one we are expecting when creating a concrete target? See here https://github.com/angr/angr/blob/master/angr/project.py#L170
Can you see what's the ID of the reported ARCH when you declare the avatar_gdb
object?
the binary archis : Arch ARMEL (LE)
I add "ARMEL" to ['X86', 'AMD64', 'ARMHF', 'MIPS32']:
https://github.com/angr/angr/blob/master/angr/project.py#L170 , it works but it is a trick.
Any other methods?
Providing that you know how to synchronize the concrete state of a program running on ARMEL (the best case scenario is that under the hood is the same as ARMHF
), you should be good with that simple modification.
Trying to create a gdb concrete target using
AvatarGDBConcreteTarget(avatar2.archs.arm.ARM, 'localhost', port)
.But it shows that:
Should I add the concrete for this architecture myself or is there already another branch that supports this arch?