It's funny looking at some of the contributors to this. Some of the accounts seem to be vague, single-duty accounts made for the express purpose of contributing code to CyberChef and nothing else. I admire their OPSEC
I've been contributing on and off to the project since it went open source (#4 on that page), it's an interesting experience communicating with blank faces that you can't know or find anything about.
Unrelated: About a year in they sent me an award[0] for continued contributions, but there's a puzzle on it I'm yet to solve; if anyone runs across this I'd appreciate any input!
Makes me wonder what GitHub can see (e-mail addresses, IP addresses). I also wonder if it is possible to use code analysis to figure out who these people are. Not that it is relevant for me, just curious...
Look up "authorship attribution" if you're interested in the identification part. There's quite a bit of research into identifying people by their unique habits. Some claim that this is possible even after your code has gone through compilation or other obfuscation processes, but academics have a habit of exaggerating claims based on small data sets. I spent around a year researching this and it's a really fun field - and no doubt the non-public research and technology is as always further advanced than what we can see.
Perhaps OP is referring to traking based on the coding? I.E. if you had all the code repos from an individual and ran some sort of pattern reconition software to cross refrence thigs like folder structure, layout of the code, frequency and time of uploads, function & variable naming techniques, etc. This reminds me of a technique called eBiomentrics[0]
Certainly an interesting idea, I suppose most of the things I listed can in fact be mitigated quite easily. Compilers and obfuscators exist even now that would totally destroy most distinguishable patterns. If anyone knows any case studies on this, please drop a link here.
At first glance, only feature requests I might have added when I did this sort of work would be in for audio spectrographs in the multimedia section. Useful for finding stego, embedded thumbnails, hidden channels etc, and a generalized malicious ZIP parser that deals with the myriad of nasties packers can use.
The demand to scale this capability within an agency like that makes it worth while to build tools like this, wonder whatother easter eggs are in there beyond alert msgs.
This is REALLY cool. Basically given an unknown string or file from something CTF-y you can run this tool on it to look for low-hanging fruit like it being e.g. base64 encoded.
This is a really old reversing trick, for what it's worth; for instance, pulling gzips out of firmware images, or spotting zipped Java images. You can also often identify cryptography primitives from their ASN.1 OID strings. There are a bunch of tools that do stuff like this.
It reminds me of SnD Reverser Tool[1], although compared to this, SnD RT has a bit more constrained scope in what it does, but it's also a standalone exe of just ~150KB. such a shame it's no longer being developed...
Cryptool is similar and I think older. At least I remember that I have used the desktop version in the 90s.
While I appreciate that they made a web version I think they scattered their efforts to create different versions too much so that the project suffered regarding features and quality.
It's fascinating to me (as someone who has written a similar system) that everybody, almost without exception, makes this leap.
If the problem is that clicking is too cumbersome, then add better keyboard support. That's the solution to the problem as stated. You don't need to throw out the whole UI for that, and there's lots of things a GUI can do that a CLI can't.
I haven't been able to determine if this is the common reaction because people simply assume a GUI can't have good keyboard support, or because they're making an excuse for some unstated other reason.
No matter how hard you work on keyboard support, it will never be good enough. If you do make it good enough, what you will end up with is basically a CLI, so why not skip the BS and just give me a real CLI from the beginning?
And anyone who goes through the effort to learn all the custom keyboard shortcuts for your application is likely a person who would quickly pick up a standard CLI, so why not save them the effort?
And once you do end up learning all the keyboard commands for an application having clickable things on screen becomes redundant. So what do you end up with when you remove all that? Just some representations of inputs and outputs, which again can be clearly displayed in a CLI terminal in some format. And because inputs and outputs rarely need to take up the whole screen, just delete all the extra whitespace too so you end up with a very compact workspace.
But at that point, just reduce your program down to a CLI and keep it in its purest form.
I think lost of folks don't think about a GUI having good keyboard support. I recall wowing a Windows admin in the late 90s by using the keyboard to navigate a mouseless Windows 'server.'
macOS seems to have eschewed good keyboard support for operating the GUI -- Steve Jobs insisted on a single button mouse because two buttons were two complicated; I could assume he would have disliked the idea of operating without point-and-click by only using the 100+ keys on a keyboard. I've witnessed many 'admins' in IT departments all to happy to point and click around their Windows AD admin interfaces without ever even thinking to ask if something faster is available.
My point here is that, anecdotally, the keyboard users and the mouse users apparently don't overlap much. This leads to keyboard users just wanting "CLI everywhere!" without consideration for a GUI with good keyboard support. I think you make an excellent point (that honestly didn't occur to me): If the problem is that clicking is too cumbersome, then add better keyboard support. It's an open source code base - we can certainly bring ourselves to bear on scratching this itch.
You need to drag specific operation(s) from Operations and drop them into Recipe. And then supply input(s) in Input tab. You can also check the Auto Bake icon in the bottom.
Ah, that's it! I discovered that I could add operations by double-clicking them, but I was so intent on trying to find a "type some raw input" operation that I completely missed the "Input tab".
If you don't trust it you can use it in a VM without network access, or something like Qubes (essentially the same). Personally, I use Opensnitch (a personal firewall like Little Snitch) on Kali Linux, but it isn't foolproof.
In this particular case, it's been posted only three times this year, and the first two had only 2 or 3 points, meaning that hardly anyone saw them--I know I didn't. I wouldn't have learned about this if not for the repost.
I don't see anything wrong with reposting perennially useful stuff at reasonable intervals. Maybe twice in as many months is too much in general, but it seems to have worked out all right.
I've never seen this before, and am glad that I have. One of the ten thousand I guess and I visit hacker news at least a few times a week. There are tons of new stuff on here everyday. No use complaining about a repost
I may be just naive, but I trust and regularly use both Cyberchef and NSA’s Ghidra. I think it’s very unlikely that these tools are backdoored (and Cyberchef runs completely in-browser).
If you've ever looked at the way the NSA treats exploits, remote access software and such, they're very careful about deploying them against people who may be able to detect and analyze them themselves.
Putting such things in public code like that which would both directly point the finger at them and possibly turning secrets into widespread knowledge in the security community would be... incredibly stupid.
Ok, fair enough, I appreciate the answers to my question - why on earth would I get docked 4 points for asking a question is a mystery though.. whoever you are.
(From: https://github.com/gchq/CyberChef/graphs/contributors)
https://github.com/n1474335
https://github.com/j433866
https://github.com/d98762625
https://github.com/s2224834
https://github.com/GCHQ77703