From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
The format implementation is at [ Github Implementation]
The format implementation is at [ Github Implementation]
The github repository is at [ The Repo]
The github repository is at [ The Repo]
This page was written by the developer, who is in dire need of formatting improvement to this page because they are not experienced in Wikimedia and have no Wiki experience of any kind. The troll user known as STgiga on Wikipedia is unrelated to myself as I do not have a Wikipedia account at this moment, and that particular troll user was doing weird stuff before I had some degree of any meaningful internet presence, and my email was not the one said troll used because I didn't know about that user at all until I googled myself. Also, I never spell my name STgiga. I only spell it as stgiga, or St. GIGA, but NEVER with a capital T. If other people refer to me with neither of those two handles, that is what they refer to me as, and them alone.

Revision as of 19:50, 24 January 2020

File Format
Name BWTC32Key
Extension(s) .B3K
Magic Bytes 0xFEFF4D00
Released 2019

This format is a single-file compression tool with optional encryption, that also is text-armored. The code is based upon specific JavaScript implementations of Base32768 AES, SHA-256, and a spiritual successor to the original bzip format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the HTML frontend as a single monolithic program. The output of the encoder is a text string. B3K files are always UTF16BE text documents bearing the Byte Order Mark. The output string is a version of Base32768 which uses Hangul Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the output string is essentially a Korean message but in an abnormal style. The file starts with 0xFEFF4D00 and ends with 0x4D01. The file can be concatenated, but to reverse it one must use a text editor to extract the portion you need due to the way the original program works. All of the code is stream compatible, and this includes the AES256 implementation which uses the Counter mode. The password field only accepts 8 bit ASCII to minimize headaches, but due to there being no length limit, UTF7 or punycode can be used to allow non-Latin passwords. Also, the encryption can be blanked, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format. The format was written in pure JS and is purely FOSS. The format was written by the author starting at age 16. This does show. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of PackIt, which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key. The Base32768 final step is essentially the antithesis of the original BinHex, because instead of using an algorithm that doubles the binary input size via base 16, the base32768 step makes the AES256-CTR encrypted BWTC archive only 16/15 of the original size assuming the UTF16BE with BOM output is the encoding to be fed into the text output file with B3K extension. It should be noted that since BWTC is very simple compared to even the original bzip, and that the 256bit AES variety used is the counter mode which needs zero padding, the format is very slim and subtle. As a text based format that closely resembles human text, it can be used where text is required, and due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number isn't present in the compressed data due to corruption or the wrong key, or if the base32768 has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the text data itself, it also fails. This ensures that corrupted files will not be created by the decoder, which can help stop damage to your system if something like a firmware blob was affected. This format does not care about file information. Hence why it can be used as a chunk format in cases where files aren't needed. The format implementation is at Github Implementation The github repository is at The Repo

Personal tools