keystone
keystone copied to clipboard
keystone-engine
option for default hex number parsing
It would be great if there was an option/syntax to override number parsing. With this option all numbers are interpreted as hex (mov eax, 01334000 assembles to mov eax, 0x1334000 instead of mov eax, 0x5B800).
sorry but i think input like what you want is really confused. you save 2 characters, but get back little.
would be better to force the input to be in a correct clean format
It's not about saving characters. The reason is that x64dbg uses hex per default for everything (the only sensible option when dealing with assembly in my opinion) and I want to mimic that behavior without having to write a parser that converts everything manually. On Fri, 29 Apr 2016 at 12:20, Nguyen Anh Quynh [email protected] wrote:
sorry but i think input like what you want is really confused. you save 2 characters, but get back little.
would be better to force the input to be in a correct clean format
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/keystone-engine/beta/issues/11#issuecomment-215678201
I'm not saying this should be implemented, but just for perspective / historical reference: Microsoft's masm assembler supported this using the .radix 16 directive, borland's turbo assembler used the radix 16 directive and the GNU GASP assembly preprocessor also seems to support .RADIX 16.
Multiple people have requested this option in the x64dbg issue tracker now.
is it possible for x64dbg to stick 0x in front of every immediate, before feeding assembly code to Keystone?
It could be a directive in the assembler like suggested, or a random option name. Maybe_RADIX16 On Fri, 9 Sep 2016 at 10:57, Nguyen Anh Quynh [email protected] wrote:
what can be the name of this option, in the form of KS_OPT_SYNTAX_xxx?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-245858190, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmeNEBRiAqxh7Rh43m-1NRtOWVB6gks5qoR9_gaJpZM4ISiej .
Just the number base. On Fri, 9 Sep 2016 at 11:16, Nguyen Anh Quynh [email protected] wrote:
what does RADIX stand for?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-245862270, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmeu2BAUwoJQoyAp6JCk1RXDlPpYxks5qoSPVgaJpZM4ISiej .
done, see https://github.com/keystone-engine/keystone/commit/eac9cc9d6712c4417ce57cb0aedeb8f0a39667c5 (including some samples on KS_OPT_SYNTAX_RADIX16 in samples/sample.c)
Okay, I will test it as soon as possible! On Fri, 9 Sep 2016 at 20:07, Nguyen Anh Quynh [email protected] wrote:
done, see eac9cc9 https://github.com/keystone-engine/keystone/commit/eac9cc9d6712c4417ce57cb0aedeb8f0a39667c5 (including some samples on KS_OPT_SYNTAX_RADIX16 in samples/sample.c)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-245992930, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmTBDgyHpNRxP0hV8DSOEwM56PfwKks5qoaBugaJpZM4ISiej .
No, I have been very busy with University. It's still on my backlog. On Fri, 23 Sep 2016 at 05:54, Nguyen Anh Quynh [email protected] wrote:
do you have any issues with this new option?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-249096484, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmWBtsGqtPJXc7cnN1Zvm6d8XrQt4ks5qs01jgaJpZM4ISiej .
Okay, so I tested and it does work for decimal constants mov eax,123 assembles to mov eax,0x123 but you can still not use hexadecimal values in the constant, so mov eax,abc fails with error 144.
Well then what is the point of a radix16 option jf you cannot enter hex numbers? On Sat, 24 Sep 2016 at 01:14, Nguyen Anh Quynh [email protected] wrote:
Because in this case Keystone does not know abc is label, or constant.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-249323362, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmZ0HrpYGPZzvSPhRK18MXbOLoVkKks5qtF1AgaJpZM4ISiej .
I don't know how keystone handles this but the radix16 option has to be requested so it's safe to assume that it's not a label. In x64dbg hex number have priority over labels, so a label beef will resolve to 0xBEEF and not the label address because that's the desired behavior.
MASM requires a 0 in front of the number. I disagree with this though, my suggestion is to assume it is a number if it is a valid hex number sequence, or if that's too edgy, check if it's a label and change it to a number if assembling with that fails.
Masm does it right: you must avoid ambiguous, dont confuse your users. So i would suggest you take the same approach for x64dbg
I disagree, zero prefixed numbers are also used for octal. If you don't want to implement it, feel free to close the issue, but there is absolutely no ambiguity here there are no labels present in single instruction assembling. On Sat, 24 Sep 2016 at 02:12, Nguyen Anh Quynh [email protected] wrote:
Masm does it right: you must avoid ambiguous, dont confuse your users. So i would suggest you take the same approach for x64dbg
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-249330066, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmQx737CQhUdDJXNkHtEb3BuSFWF1ks5qtGsJgaJpZM4ISiej .
Think about that: if in your code has a label "abc", then this instruction confuses your own user, no?
External labels are not supported by keystone anyway right? And no it doesn't confuse users it has been the default behavior for three years. On Sun, 25 Sep 2016 at 09:58, Nguyen Anh Quynh [email protected] wrote:
Think about that: if in your code has a label "abc", then this instruction confuses your own user, no?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-249408462, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmZbEtGlyhQrhkEb_ycg-1HXSYz94ks5qtimZgaJpZM4ISiej .
symbols will be supported with a new API, but that is another story.
in case the code has both label "abc" & "mov eax, abc", how do they know what this instruction mean?
They don't, but since you explicitly choose for hexadecimal numbers you can safely assume that the user wants 0xabc when seeing "abc" On Tue, 27 Sep 2016 at 02:00, Nguyen Anh Quynh [email protected] wrote:
symbols will be supported with a new API, but that is another story.
in case the code has both label "abc" & "mov eax, abc", how do they know what this instruction mean?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/keystone-engine/keystone/issues/11#issuecomment-249731821, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmZOcpKOIcJ5rxx53sig7UnN1QAt-ks5quFywgaJpZM4ISiej .