Feature request: Simple arithmetic is not possible in CyberChef #1129
Comments
|
Have you tried the fork operation?
https://gchq.github.io/CyberChef/#recipe=Fork('%20','%20',false)To_Base(16)&input=OTcgMTA
Best,
Sebastian
From: Trevor Leach <notifications@github.com>
Reply-To: gchq/CyberChef <reply@reply.github.com>
Date: Monday, November 23, 2020 at 4:04 PM
To: gchq/CyberChef <CyberChef@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [gchq/CyberChef] Feature request: Allow for working with arrays of numbers (#1129)
As of right now, as far as I can tell, there is not an easy way to use CyberChef to do mathematical conversions or operations on various numbers. For example, I can use the ToBase operation to turn 97 into its equivalent hexadecimal 61, OR input 16 to get 10. However, I cannot input "97 16" to get an output of "61 10" (example here<https://gchq.github.io/CyberChef/#recipe=To_Base(16)&input=OTcgMTA>). There is no easy way to do an operation on an array of numbers. The majority of modules assume that the input is ASCII.
Additionally, modules like multiply and divide take all inputs from the data itself, which is also being mangled. There is not an easy way to multiply the result of some conversion by 2 without altering the input, and if your input is being altered by several modules it can be very cumbersome to figure out a way to get the mathematical operation to work without destroying your input, not to mention this is infeasible on large inputs. There needs to be mathematical operation modules like the following.
[Image removed by sender. image]<https://user-images.githubusercontent.com/20407804/100013846-1f1b5d80-2d9b-11eb-84b7-d0bff282e00d.png>
These would also allow the intake of an input like "2 4 6" and when run through the MultiplyByX module with a setting of 2, could output "4 8 12"
Also, as a side point, many of the module names can be misleading. For example, the ToHex module assumes that input is text, so when inputting a number, that number is converted to the hexadecimal value for that character in the ASCII table. The example here<https://gchq.github.io/CyberChef/#recipe=To_Hex('Space',0)&input=Mg> takes 2 and outputs 32 instead of 2. This is correct if the input is text but incorrect if the input is meant to be a number. I suggest changing the names of the modules to something like ToAsciiHex, or leave the name and add a dropdown to the module allowing you to define the input/output as numerical. There have been many others confused about this in the past (962<#962>, 609<#609>, 1029<#1029>...). A name like FromHex or ToHex is too ambiguous when the module itself does a very specific thing.
TL;DR
As it stands right now, you cannot properly work with numerics in CyberChef.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#1129>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKWFL3IDUE5BO3L4KAUHM3TSRLE4VANCNFSM4T776QEQ>.
|
|
Fork seems to solve the problem of working with arrays, thank you. However, this still leaves the issue that you cannot properly run mathematical operations on the forked numbers because the arithmetic modules are lacking. I cannot multiply, divide, add, or subtract by an arbitrary number. This in turn means I cannot run shifts on ASCII to simulate things like Caesar cipher rotational encoding, or really anything involving math in general. The only mathematical operations I can run are between numbers already in the input. I could potentially alter the input to work around the current state of the mathematics modules, but this isn't feasible for large inputs. It also isn't intuitive or simple like CyberChef is meant to be. It should be as easy as adding a multiply module and setting it to multiply the current input by X, like the example image I have in the original post. (I still do think modules like FromHex should be renamed to FromAsciiHex, but this is less important.) |
|
I agree that in certain cases it does take some playing around with the inputs/outputs, but generally I’ve found solutions for the types of manipulation you describe by combining various steps, e.g.
https://gchq.github.io/CyberChef/#recipe=From_Charcode('Space',16)ROT13(true,true,13)To_Charcode('Space',16)&input=NDEgNDIgNDMgNDQ
One of the best things I’ve found with CyberChef is the extensibility. It would be straightforward to fork the codebase and add some of the items you’re missing. You can even rename existing functions, though I don’t know that would pass a pull request 😊
Best,
Sebastian
From: Trevor Leach <notifications@github.com>
Reply-To: gchq/CyberChef <reply@reply.github.com>
Date: Tuesday, November 24, 2020 at 7:50 PM
To: gchq/CyberChef <CyberChef@noreply.github.com>
Cc: Sebastian Ganson <sganson@trustedsecurity.com>, Comment <comment@noreply.github.com>
Subject: Re: [gchq/CyberChef] Feature request: Allow for working with arrays of numbers (#1129)
Fork seems to solve the problem of working with arrays, thank you. However, this still leaves the issue that you cannot properly run mathematical operations on the forked numbers because the arithmetic modules are lacking. I cannot multiply, divide, add, or subtract by an arbitrary number. This in turn means I cannot run shifts on ASCII to simulate things like Caesar cipher rotational encoding, or really anything involving math in general.
The only mathematical operations I can run are between numbers already in the input. I could potentially alter the input to work around the current state of the mathematics modules, but this isn't feasible for large inputs. It also isn't intuitive or simple like CyberChef is meant to be. It should be as easy as adding a multiply module and setting it to multiply the current input by X, like the example image I have in the original post.
(I still do think modules like FromHex should be renamed to FromAsciiHex, but this is less important.)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#1129 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKWFL3IFLZUVDROXGXUBMU3SRRIE5ANCNFSM4T776QEQ>.
|
|
I edited my message after posting, which doesn't do much for email notifications, but yes I do realize there is a ROT13 module. A Caesar cipher shift was just the first example I pulled out of my head. My point is that if CyberChef allowed for arbitrary math to be done on inputs, it would allow for a lot more than what you can reasonably do now. Yes, there probably is a workaround available to get CyberChef to do what I want, but it's not intuitive and it's not apparent to me what that is. Why can the multiply/divide/add/subtract modules not be supplied a number? I'd think most people would imagine it should. It doesn't make much sense to force these modules to only be capable of running arithmetic between numbers already in the input. If someone wants to divide a potential cipher key by 3 before XORing that number in binary form with a ciphertext, the first thing they are going to search for is divide. That person is going to be disappointed when they quickly realize that something as simple as a division is not possible in CyberChef. If I can find time to fork and modify the code base to submit a PR I will, but I am quite busy with my own projects right now. So in the meantime if one of the maintainers are able to include this feature as an update I think it would be very beneficial to CyberChef users. PS: I've changed the issue title to better match the actual problem in this discussion, as working with number arrays is possible but arithmetic is not |
executionByFork
changed the title
Thank you for this! I was looking at a much more trivial example of the number 42 being converted to 00110100 00110010 via "To Binary": https://gchq.github.io/CyberChef/#recipe=To_Binary('Space',8)&input=NDI The workaround is to add an extra "From Decimal" step (which, by itself, only produces the output "*") before the "To Binary" step: https://gchq.github.io/CyberChef/#recipe=From_Decimal('Space',false)To_Binary('Space',8)&input=NDI |
This isn't always viable. If you want to convert 12345 to hex, from_decimal can't convert it to a byte, and fails. |
As of right now, as far as I can tell, there is not an easy way to use CyberChef to do mathematical conversions or operations on various numbers. For example, I can use the ToBase operation to turn 97 into its equivalent hexadecimal 61, OR input 16 to get 10. However, I cannot input "97 16" to get an output of "61 10" (example here). There is no easy way to do an operation on an array of numbers. The majority of modules assume that the input is ASCII.
Additionally, modules like multiply and divide take all inputs from the data itself, which is also being mangled. There is not an easy way to multiply the result of some conversion by 2 without altering the input, and if your input is being altered by several modules it can be very cumbersome to figure out a way to get the mathematical operation to work without destroying your input, not to mention this is infeasible on large inputs. There needs to be mathematical operation modules like the following.
These would also allow the intake of an input like "2 4 6" and when run through the MultiplyByX module with a setting of 2, could output "4 8 12"
Also, as a side point, many of the module names can be misleading. For example, the ToHex module assumes that input is text, so when inputting a number, that number is converted to the hexadecimal value for that character in the ASCII table. The example here takes 2 and outputs 32 instead of 2. This is correct if the input is text but incorrect if the input is meant to be a number. I suggest changing the names of the modules to something like ToAsciiHex, or leave the name and add a dropdown to the module allowing you to define the input/output as numerical. There have been many others confused about this in the past (962, 609, 1029...). A name like FromHex or ToHex is too ambiguous when the module itself does a very specific thing.
TL;DR
As it stands right now, you cannot properly work with numerics in CyberChef.
The text was updated successfully, but these errors were encountered: