# ToolsFx: cipher workbench for encoding analysis and CTF > ToolsFx is an ISC-licensed Kotlin desktop application that consolidates encoding, symmetric and asymmetric encryption, hashing, MAC, digital signatures, and classical ciphers into a single GUI. Windows users get bundled JRE packages; JDK11+ installs on other platforms need JavaFX configured separately. **Leon406/ToolsFx** — A cross-platform cryptography toolbox covering encoding/decoding, encoding conversion, encryption/decryption, hashing, MAC, signatures, big-number arithmetic, compression, QR codes, CTF utilities and more. - Repository: https://github.com/Leon406/ToolsFx - Website: https://github.com/Leon406/ToolsFx/wiki - Stars: 2,061 · Forks: 321 - Language: Kotlin - License: ISC - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/leon406-toolsfx ## Encoding breadth: base16 through base100, and an auto-decode scanner The encoding tab covers a wider range than most desktop tools. The base encoding list runs from base16 to base100, with entries at base32, base36, base45, base58, base62, base85, base91, base92, and base100 alongside the more common base64, urlBase64 and base58check. Beyond numeric bases, the module handles UrlEncode, Unicode, JavaScript hex notation (\x61), JavaScript octal notation (\140), binary/octal/decimal/hex display, custom base serial dict, puny code, quote printable, uuEncode, xxEncode, escape, and escapeAll. Auto decode is listed as a crack feature: it attempts to identify and reverse an unknown encoding without the user specifying which scheme was used. Encoding transfer handles converting between two encoded representations without decoding to raw bytes first, which matters when the source encoding is known but the target encoding differs. String processing, including splitting operations, is also part of this module. For CTF work, the range is what counts. A challenge might present text in base85, base92 or a custom alphabet, and having all of them in one interface removes the need to switch between separate tools. ## Hashing handles files over 8Gi, and the HMAC list spells whirlpool differently The digest module covers md serial, sha1, sha2, sha3, SM3, RIPEMD, whirlpool, Tiger and others. SM3 is the Chinese national standard hash algorithm. Its presence alongside the SHA family gives the project relevance for developers working with Chinese government or financial-sector systems that require SM3 in certain contexts. A concrete size limit is stated: the digest module handles files larger than 8Gi. That covers ISO images, database dumps and large archive files that overflow typical in-memory hash utilities. Multi-file processing is also supported for both hash and symmetric encryption operations. One inconsistency appears across the README. The hash section spells the algorithm whirlpool correctly, while the HMAC section lists the same algorithm as whirpool, missing the second l. Both entries refer to the same Whirlpool hash function. The hash section uses the correct spelling; the HMAC section uses whirpool. Anyone relying on HMAC-Whirlpool should confirm the tab label in the application matches the intended function. The dictionary hash mapping feature, described in the README as a crack function, supplies a word list to test against a given hash value. That is the same concept as the auto decode scanner in the encoding module, applied to hashes instead of encoded text. ## Block cipher configuration spans ten modes and eight padding schemes The symmetric block cipher section supports DES/3DES, AES, SM4, Blowfish, Twofish, RC2 and others. The mode list is broad: ECB, CBC, OFB(n), CFB(n), SIC (also known as CTR), CTS (equivalent to CBC/WithCTS), and four authenticated encryption modes: CCM, EAX, GCM and OCB. The padding choices are no padding, PKCS5/7, ISO10126/ISO10126-2, ISO7816-4/ISO9797-1, X9.23/X923, TBC, ZeroByte, and withCTS when used with ECB mode. A developer comparing an AES-GCM result against a reference system needs to match the exact mode, the padding scheme, and the encoding of the key and initialization vector. ToolsFx accepts keys and IVs in both base64 and hex form. Matching those parameters by hand across different implementations is where a GUI with explicit dropdowns for each setting earns its place. The AEAD modes (CCM, EAX, GCM, OCB) each carry authentication alongside encryption. The README does not document how to set the authentication tag length or the associated data field for any of them. That gap is worth checking against the project wiki before relying on those modes in a verification workflow, since an AEAD implementation with default or undocumented parameters may not match what a production library produces. ## RSA handles texts longer than the key size and the EdDSA entry names ED25192 The RSA module supports key sizes of 512, 1024, 2048, 3072 and 4096 bits. It reads pkcs1 and pkcs8 key formats along with openssl pkcs1/pkcs8 private key formats, PEM and pk8 formats, and certification cer files. The README states it supports plain text longer than the key size, which requires splitting the input across multiple RSA operations at the application level. The splitting method and the format of the resulting concatenated output are not documented. The digital signature section lists RSA serial, DSA, ECDSA, EC, EdDSA (ED448/ED25192) and SM2. ED25519 is the widely deployed Edwards-curve signature algorithm. ED25192 does not correspond to a recognized curve name in standard references or in the Bouncy Castle library that ToolsFx links to as its crypto backend specification. The discrepancy appears only in this one line of the README. To confirm whether the implementation is actually ED25519, the source files under app/ would need direct inspection. The README also mentions private key encrypt as an RSA operation. This is an unusual description. The standard RSA private-key operation on arbitrary data is signing, not encryption. Whether ToolsFx performs textbook private-key RSA or a signing operation under that label is not clarified in the README. ## Classical CTF ciphers: caesar through Hill, Bifid and RSA crack for weak keys The classical cipher section is the longest feature list in the README. It names caesar, rot5/rot13/rot18/rot47, affine, atbash, morse, polybius, bacon (two variants: 24 and 26), one time pad, ADFGX/ADFGVX, Auto Key, rail-fence (normal and w-type), playfair, brainfuck/troll/ook, Braille, alphabet index, 01248, BubbleBabble, Element Periodic Table, PawnShop Cipher, Handy code, Beaufort, Porta Cipher, Bifid/Trifid/FourSquare Cipher, Gronsfeld Cipher, Gray code, Buddha Says, Hill Cipher, rabbit, aaencode/jjencode and RSA crack. Three Chinese-community ciphers (including 新佛曜 and 兽音) are listed as online-only and require a network call to function. One spelling note: the README lists the Vigenere cipher as virgenene, which is not the standard spelling. Whether this affects the tab label in the running application is not stated. RSA crack handles two specific CTF scenarios: nec (insufficient ciphertext attacks) and pqec (attacks that recover a plaintext by factoring a weak RSA modulus). These are not techniques for attacking properly generated RSA keys. A key pair generated with standard parameters is not at risk from either. Socialist core value is a steganographic encoding used in a category of CTF challenges popular in China, where data is encoded into the 24 Chinese socialist core values. Its presence alongside international classics like caesar and Hill Cipher reflects the project's combined international and Chinese CTF focus. ## Downloads split by JRE bundle, and the JDK11+ path needs JavaFX configured separately The README describes four download paths on the GitHub releases page. Developers with a JDK already installed choose between two jar variants: jdk8-all-platform for JDK 8 environments and jdk17-no-jfx-all-platform for JDK 11 or later, which requires a separately configured JavaFX environment before launch. Windows users without a JDK get two bundled options: withjre-win-x64 packages the latest LTS JRE for 64-bit Windows, and jdk8-withjre-windows-x86 covers both 32-bit and 64-bit Windows with a JDK 8 runtime. A Gitee mirror is available for users in mainland China. Beta versions are described as jar files that you copy into the lib directory and use to replace the existing ToolsFx jar or app jar file. No build-from-source steps appear in the README. The repository root includes gradlew and build.gradle.kts, which shows a Gradle project structure, but no build command, no Gradle task name and no Java version requirement is documented for building from source. Anyone who wants to modify the code must reconstruct the build process from the Gradle files alone. The last push was on 2026-10-03 and the repository is not archived. ## The misc module adds network scanning and leaves its behavior undocumented Alongside the cryptography functions, ToolsFx includes a misc module containing timestamp-to-date and date-to-timestamp conversion, UUID generation, port scan, IP scan, ping and tcping. None of the network features are documented beyond their names. There is no explanation of the port range a scan accepts, how it handles timeouts, what output it returns, or what privilege level it requires on each platform. For a project described primarily as a cryptography toolbox, the presence of network scanning is an addition the README never explains. The README gives no scope for any of them: no port range, no timeout behaviour, no output format. The same module also groups QR code generation and OCR, string processing, a big integer calculator and an ECC calculator. These are supplementary to the main crypto functions. The README gives no usage notes for any of them. ToolsFx has no command-line interface and no scripting API. Every operation goes through the GUI. That makes it unsuitable for automated pipelines or any integration that calls crypto functions from code. The multi-file drop in the hash and symmetric encryption modules handles repetitive work, but a scripted or headless workflow needs a different tool. ## Conclusion ToolsFx suits CTF players who need a single GUI covering classical ciphers, encoding and modern crypto without writing code. Developers debugging a symmetric encryption result against a precise mode and padding combination will find the block cipher configuration useful. Avoid it when you need a CLI, a scripting API, or cross-platform packages that install without a separate JavaFX setup: JDK11+ builds require a JavaFX environment to be configured, and no macOS application bundle appears in the README. Before using it for anything beyond casual verification, check the EdDSA implementation in the app/ source against a reference library, because the README names ED25192 where the standard algorithm name is ED25519. ## FAQ ### What is ToolsFx? ToolsFx is a cross-platform desktop GUI application written in Kotlin that covers encoding, decoding, symmetric and asymmetric encryption, hashing, MAC, digital signatures, classical CTF ciphers, QR codes and big integer calculations in a single window. The README links its crypto backend to the Bouncy Castle specification. ### Does ToolsFx work on macOS and Linux? The project description calls it cross-platform. The README offers Windows-only packages that bundle a JRE, and separate all-platform jar files for JDK 8 and JDK 11+ environments. The JDK 11+ jar requires a separately configured JavaFX environment. The README documents no macOS or Linux application bundle. ### Does ToolsFx have a command-line interface? The README describes only a GUI application. No CLI, scripting API or headless mode is mentioned anywhere in the README or the repository file listing. ### What hashing algorithms does ToolsFx support? The digest module covers md serial, sha1, sha2, sha3, SM3, RIPEMD, whirlpool, Tiger and others. The README states it handles files larger than 8Gi and supports multi-file processing. A dictionary hash mapping feature lets you supply a word list to test against a given hash value. ### What is the RSA crack feature in ToolsFx? The README lists RSA crack under the CTF classical cipher section with two named scenarios: nec (insufficient ciphertext attacks) and pqec (attacks that recover a plaintext by factoring a weak RSA modulus). These apply to CTF challenges that use deliberately weakened RSA parameters, not to properly generated keys. ## Sources - [Leon406/ToolsFx on GitHub](https://github.com/Leon406/ToolsFx) - [License: ISC](https://github.com/Leon406/ToolsFx/blob/dev/LICENSE) - [Project website](https://github.com/Leon406/ToolsFx/wiki) - [README](https://github.com/Leon406/ToolsFx/blob/dev/README.md) - [Releases](https://github.com/Leon406/ToolsFx/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leon406-toolsfx