Setting sym_resolver suddenly causes default radix to become hexadecimal

[ExpHP]

keystone version: 0.9.2

If you create a keystone.Ks, initially the default radix is decimal. However, setting sym_resolver causes it to become hexadecimal.

import keystone

asm = 'cmp dword ptr [ebp+12], eax'

ks1 = keystone.Ks(keystone.KS_ARCH_X86, keystone.KS_MODE_32)
ks2 = keystone.Ks(keystone.KS_ARCH_X86, keystone.KS_MODE_32)
print('ks1', ks1.asm(asm))  # prints ([57, 69, 12], 1)
print('ks2', ks2.asm(asm))  # prints ([57, 69, 12], 1)

ks1.sym_resolver = lambda *args: False
print('ks1', ks1.asm(asm))  # prints ([57, 69, 18], 1)  <-- !!!
print('ks2', ks2.asm(asm))  # prints ([57, 69, 12], 1)

# Things get even stranger as you create more Ks objects.
# Eventually it starts affecting Ks objects that have never even
#  had a sym_resolver!
ks1 = keystone.Ks(keystone.KS_ARCH_X86, keystone.KS_MODE_32)
print('ks1', ks1.asm(asm))  # prints ([57, 69, 12], 1)
print('ks2', ks2.asm(asm))  # prints ([57, 69, 12], 1)
ks2 = keystone.Ks(keystone.KS_ARCH_X86, keystone.KS_MODE_32)
print('ks1', ks1.asm(asm))  # prints ([57, 69, 12], 1)
print('ks2', ks2.asm(asm))  # prints ([57, 69, 18], 1)  <-- !!!

[iMoD1998]

Any update on this?

I have a the same problem on powerpc.

[iMoD1998]

Problem seems to be here: https://github.com/keystone-engine/keystone/blob/e1547852d9accb9460573eb156fc81645b8e1871/llvm/keystone/ks.cpp#L525

[wtdcode]

Looks like relevant to #382. I'm taking a look.

[ExpHP]

In that issue they're disagreeing over which value is the correct one to put there, but honestly I don't see why that line even exists.

ks_option is clearly meant to be called multiple times, to set a single option each time. This is simply not the place to implement a default (this should be done during initialization), and no value that is assigned here will be correct.

Edit: that said, I suppose it might make more sense if the line were inside the KS_OPT_SYNTAX branch. And the values were adjusted so that both 10 and 16 are possible outcomes. Since this line supposedly was the solution to an uninitialized read, however, that bug might resurface and will need to be fixed the proper way... whatever that is.