DisNCord Community Wiki - User contributions [en]

Blackstar

2024-09-11T14:38:21Z

JennyWakeman: gug

This project is an attempt to boot a custom kernel on the Dish Network ViP222k series satellite receivers. So far, we have achieved a buffer overflow which could potentially result in remote code execution.

== Project Goals ==
We'd like to boot a custom kernel (either Linux or NetBSD) via kexec upon gaining code execution on the target, purely over the network without plugging anything into the receiver itself. (Outside of potentially a USB stick?)

== UPnP ==
On startup, the ViP units expose a UPnP server with a surprising (alarming?) amount of functions. Some examples:

* Increment/decrement channel
* Force redownload program guide
* Lock/unlock front panel controls and remote
* Remote reboot
* Test satellite switch (annoying, takes a very long time!)

(Among various other things.)

Currently, a Python script has been written (and will eventually be released) that can detect ViP units on a wireless network (via UPnP) and execute exposed actions.

=== Exploit ===
Though the firmware on the test unit was last updated in 2019, the version of <code>libupnp</code> present on the system is version 1.6.6, which is susceptible to [https://nvd.nist.gov/vuln/detail/CVE-2012-5958 CVE-2012-5958], a buffer overflow capable of remote code execution. Using Metasploit's module for this CVE, we were able to trigger the overflow, although without a proper payload, the UPnP server simply crashed (after two attempts).

The potential for this exploit is that we can remotely boot a modified NetBSD or Linux kernel on affected boxes over the network, discovering and exploiting boxes via UPnP.
[[Category:Projects]]

EchoStomp PLUS

2024-09-11T14:33:05Z

JennyWakeman: JennyWakeman moved page EchoStomp PLUS to Blackstar: cooler name

#REDIRECT [[Blackstar]]

Blackstar

2024-09-11T14:33:05Z

JennyWakeman: JennyWakeman moved page EchoStomp PLUS to Blackstar: cooler name

This is a project to (hopefully) achieve remote code execution on the Dish Network ViP line of set-top boxes. The unit used for testing is a Dish Network ViP222k.

I wouldn't place bets on this project's success. I do not have a background in cybersecurity or pentesting. It'd be funny though.

== Goals ==

* Framebuffer access (for funniest image I'll ever take)
* Boot NetBSD (someday, somehow)
* Run Doom (maybe)

== UPnP ==
On startup, the ViP units expose a UPnP server with a surprising (alarming?) amount of functions. Some examples:

* Increment/decrement channel
* Force redownload program guide
* Lock/unlock front panel controls and remote
* Remote reboot
* Test satellite switch (annoying, takes a very long time!)

(Among various other things.)

Currently, a Python script has been written (and will eventually be released) that can detect ViP units on a wireless network (via UPnP) and execute exposed actions.

=== Exploit ===
Though the firmware on the test unit was last updated in 2019, the version of <code>libupnp</code> present on the system is version 1.6.6, which is susceptible to [https://nvd.nist.gov/vuln/detail/CVE-2012-5958 CVE-2012-5958], a buffer overflow capable of remote code execution. Using Metasploit's module for this CVE, we were able to trigger the overflow, although without a proper payload, the UPnP server simply crashed (after two attempts).

The potential for this exploit is that we can remotely boot a modified NetBSD or Linux kernel on affected boxes over the network, discovering and exploiting boxes via UPnP.
[[Category:Projects]]

Blackstar

2024-09-11T14:32:24Z

JennyWakeman: add section on cve

Blackstar

2024-09-10T14:31:22Z

JennyWakeman: What? Help me!

This is a project to (hopefully) achieve remote code execution on the Dish Network ViP line of set-top boxes. The unit used for testing is a Dish Network ViP222k.

I wouldn't place bets on this project's success. I do not have a background in cybersecurity or pentesting. It'd be funny though.

== Goals ==

* Framebuffer access (for funniest image I'll ever take)
* Boot NetBSD (someday, somehow)
* Run Doom (maybe)

== UPnP ==
On startup, the ViP units expose a UPnP server with a surprising (alarming?) amount of functions. Some examples:

* Increment/decrement channel
* Force redownload program guide
* Lock/unlock front panel controls and remote
* Remote reboot
* Test satellite switch (annoying, takes a very long time!)

(Among various other things.)

Currently, a Python script has been written (and will eventually be released) that can detect ViP units on a wireless network (via UPnP) and execute exposed actions. This has the added advantage of being able to quickly detect model information and grab the unit's IP (for port scanning, which will be done Soon<sup>ᚾᛖ</sup>.)
[[Category:Projects]]

Blackstar

2024-09-10T14:14:25Z

JennyWakeman: jcnjkndjknaskjnckjndsakjfbdfbjhbdhfwboechwfoexuiofaonucfoiunuipqnoirunsoiufcnoiafuoinuciodsnauopibeiqubwrcrberyrwehwrnehuidxfjneoqjrjbijausodjfcobuiewcjneuweqirbqiudhboxnqyuiybduyauiybauiefonjeqpxiqefournqceuroiquriupxueoqxunuqexuehmmnqdpznjafhdfhbehcqoonuiwhmefixuefuzhbeuiqseyuefnhxnhfiuhninhewqioybffgryweiueyzbfyxgexweybfgqixbyefgigeqnxgfeyfqgenxygwehqjggdhgafshfgiexqbeytvieytewvytftewvfiqwvtvyetwgfnyyifbysfubiabduyfboefyeborybiubwufbyeoufybyasybidosafybfucknyndxiuyebifvuebxnqnyszehbyezuyiybiu

Quotes

2024-09-08T18:42:14Z

JennyWakeman: /* The most normal sentence said in DisNCord */

[[Category:Fluff]]
Add new quotes at the bottom (at least for now, can discuss what's better).

== The most normal sentence said in DisNCord ==
[[File:Sunrise_720p.png|200px|thumb|right|the SUN rises]]

<pre>
aquamarine: Sunrise
Restless Yankee: I also want to post that to /r/minecraft
aquamarine: wait, lemme flip the sun back around
</pre>

== The gift that keeps giving ==
NCommander: I really keep @YAGPDB.xyz because the thank you counter is always hilarious when it goes off
YAGPDB.xyz: Gave +1 Rep to @YAGPDB.xyz
NCommander: ...
NCommander: you know, kinda like that

== On N's Life ==
<pre>
volatilefluid: We're all just files mounted into your namespace, presumably Plan 9-style.
</pre>

== On Bad Ideas ==
<pre>
NCommander: ... why is that a normal sentence ...
pJowok: it's not a normal sentence, it's a coherent sentence that is grammatically valid
</pre>

== NCommander on Stream ==
<pre>
NCommander: We're only using 32GB of ram! I can open 2 more chrome tabs!
''long pause and quieter''
I'm going to hell for that...
</pre>

== Really puts stuff in perspective ==
<pre>
NCommander: you know, the Queen outlasted PAL broadcasting
</pre>
== Ah yes, IBM dynasty ==
<pre>
vmlemon: OS/2 is kinda like a Ming vase, or something - fragile, opaque, and awkward to repair, when it breaks
</pre>

== Probably one of the less insane things ever said here ==
<pre>
mineman: is it bad that "cross compiling bash for iOS" is a completely normal sentence here?
</pre>

== How Inoichi 2D was started ==
<pre>
Luna the Foxgirl: But yeah, it started as a subsystem for my lesbian foxgirl mahjong game engine
</pre>

== NCommander being on fire ==
<pre>
NCommander: Maybe if the fire asked me out to dinner first
Mineman and sadmac: *bursts out into laughter*
</pre>

== The Simple Truth ==
<pre>
NCommander: The saying in rehab circles is "fake it til you make it"
NCommander: but by and large, the difference between online you and real life you is more confidence
</pre>

== Limits ==
<pre>
Waterpear — Today at 12:46 AM
>open os/2 stream vod
>see comment talking about visual j++
>close os/2 stream vod
</pre>

== The Software Lifecycle ==
<pre>
FreeFull: Oh boy, it's time to build perl
Lunathir: Ran into a bit of software gore
</pre>

== When The Void Stares Back ==
On occasion, the eldritch lore makes itself known ...

<pre>
Dr. Shuppet: As of the MDOS4 toolchain thing, I tried MASM 4.0, and it produced an object file that is accepted by LINK4
S: However, LINK4 wants an automatic data segment, and I'm not sure how to make one
S: MASM certainly supports it, since it's needed for any NE binary, including Windows 1.0
Restless Yankee: You usually need a DEF file
RY: ... I suffered through this in Watcom/wasm/wlink, and I got a cold shiver trying to figure it out with what little survives of early Microsoft documentation
S: Ah, I didn't think of that, since I'm neither building a DLL nor I'm importing any symbols
RY: 16-bit EXEs have a DEF file
RY: There's a default, but I think I even had one for FLAGGEN
RY: https://github.com/NCommander/progress-pride-win16/blob/main/source/flaggen.def
RY: ... how is it I have the cold shiver, and then immediately produce a link written by my own hand that is the probable answer ...
RY: ... fuck it, that one is going on the quotes page ...
</pre>

== Paint Drying, Some Assembly Required ==
<pre>
sadmac356: At this point my "paint drying" is more "if you want to make an apple pie from scratch, you must first create the universe"
</pre>

== Tickle Current ==
<pre>
kraaabs: It’s charging in the way that condensation on a window is flooding your house
</pre>

== Additional Quotes ==
[https://github.com/TwoPizza9621536/ncommander-quotes Unofficial NCommander quotes file]

Homebrew OS Development

2024-09-08T18:36:06Z

JennyWakeman: /* Open Computing Kit (OCK) */

[[Category:Projects]]
This is a general summary of what OSes are being developed on DisNCord.

=== Open Computing Kit (OCK) ===
A joint project between Velleda, Sadmac356, Griffin, Europa, and others, [https://github.com/open-computing-kit Open Computing Kit] is an operating system that aims to be as GNU-independent as possible, including a [https://github.com/open-computing-kit/ockernel kernel written in Rust] and its [https://github.com/open-computing-kit/OCKcore own set of coreutils]. It is presently in the very early stages of active development.
[[File:SeshOS3.png|thumb|SeshOS as of August 6th, 2024]]

=== SeshOS ===
Written by Mineman, SeshOS is one of the more esoteric OSes on DisNCord. As of 10/15/2022 it has a working malloc thanks to Krabs and Mathewnd.

SeshOS has support for one filesystem: tar ramfs.

Has very basic SMP setup, and has support for the PC Speaker.

Its source code is located at https://github.com/mine-man3000/SeshOS.

Techflash also rewrote the entire thing in C and ported bits of his OS to this.
=== Pics Of Bread Awful scRipting Interpreter System for Neat Architectures (POBARISNA) ===
Written by Krabs, POBARISNA is an operating system with a JavaScript-based microkernel design that currently only runs on PowerPC macs. There are prospective plans for ports to other "Neat Architectures" (which Krabs defines as "not a PC/BIOS/UEFI x86 system"), such as SPARC variants and ARM.

The project can be found on [https://gitlab.com/sarahcrowle/pobarisna GitLab].

The JavaScript interpreter used in POBARISNA is [https://duktape.org/ Duktape], an easily embeddable interpreter with a nice API. However, Duktape 2.x has some awkward tooling and a lack of solid control over execution. Therefore, there are plans to replace it with [https://gitlab.com/sarahcrowle/dorktape Dorktape], which will hopefully serve as a modernized fork of the engine.

Being that PowerPC OpenFirmware is a slightly under-documented platform, [[PowerPC OpenFirmware Implementation Details]] should serve as helpful to anyone looking to do something similar.
[[File:POBARISNA running duktape on bare metal.jpg|alt=An early screenshot of POBARISNA running Duktape in OpenFirmware|thumb|An early screenshot of POBARISNA running Duktape in OpenFirmware]]

=== picotalk ===
Written by Waterpear, picotalk is a Smalltalk interpreter that aims to be a bare-metal system for embedded use.

An early attempt to implement a system from scratch in C existed, but has been abandoned. Instead, the plan is to recreate the original Smalltalk-80 system, build an RPC layer to allow the development tools to operate over a serial link, and strip out features not needed for embedded systems such as the GUI. A "zeroth prototype" written in Python is in progress, and can run some of the Smalltalk development tools.

=== Rotom OS ===
Written by SED, [https://github.com/SED4906/rotomos Rotom OS] is an operating system with little information to glean from anything except for its code and a few images. It attempts to be as simple as possible, with ring 3 not yet being implemented.
[[File:RotomOS.png|thumb|Rotom OS]]

=== styx ===
Written by Sirocyl and others, styx is an operating system with many ideas, some of which will be listed here:
* Applications will be double-click to run, much like Windows or macOS.
* Libraries should live with their application in packaging, similar to Windows.
* Installation will be done through drag-and-drop, taken from macOS.
* The system will be as (trans)portable as possible, similar to Classic macOS.
* The word "styx" is not an acronym, nor will the operating system's governing body ever be comprised of one member.
* The system will be consent-first, something that flies in the face of traditional operating systems like Windows and macOS.
There are many more than are stated here in their Discord server, due to there being too many to list here effectively.

=== Astral ===
Written by Mathewnd, [https://github.com/Mathewnd/Astral Astral] is a monolithic kernel written in C. It is still at its early stages of development and has the beginnings of a userland.

It has a growing port collection with a few examples being Bash, Doom, Binutils, Coreutils and NASM.

Its current main goal is to have a usable command line interface while also having fun developing the system.
[[File:Astral neofetch.png|alt=Astral running Neofetch on Oct 11, 2022|thumb|Astral running Neofetch on Oct 11, 2022]]

=== Techflash OS (TFOS) ===
Written by Techflash, [https://github.com/techflashYT/Techflash-OS Techflash OS] is an operating system that is still very early in development.

It current has very little implemented except for the following:

* A basic boot procedure
* Enabling a few CPU features
* Support of a few basic interrupts, such as the [[wikipedia:Intel_8253|PIT]] and keyboard.
* A very basic framebuffer console
* Starts of an ELF loader
* Serial and Parallel support for logging

Jax Archive

2024-09-07T03:24:58Z

JennyWakeman: /* Magic Number */ whoops

'''Jax''' (or '''J'''enny's '''A'''rchive e'''X'''change) is an awful backronym and a simple archive format intended to be easy and cheap (processing power-wise) to parse. Structurally, it is similar to <code>tar</code>, while not being nearly as wasteful. Instead of fixed-length fields, it uses Pascal-style strings for archive names and descriptions, as well as an additional 'descriptor' field. The 'descriptor' is a simple key/value style field for additional metadata.

==Magic Number==
Jax-format archives all begin with the bytes <code>5E 6A 61 78</code> (<code>^jax</code> in ASCII.)

==Records==
Jax archives are structured as follows:

*Magic number
*Record for File 1
*Data for File 1
*Record for File 2
*Data for File 2
*...

Records are not aligned to any particular byte boundary and neither are the files within the archive, in the interest of creating smaller archives without the need for compression.

Records are structured as follows. Note that a <code>char</code> is an 8-bit unsigned integer, a <code>long</code> is a 64-bit signed integer, a <code>ulong</code> is a 64-bit unsigned integer, and a <code>ushort</code> is a 16-bit unsigned integer.

{| class="wikitable"
|+Jax archive record structure
|-
!Type!!Name!!Details
|-
|<code>char</code> || Record Type || <code>d</code> for directory, <code>s</code> for symbolic link, and <code>r</code> for a regular file.
|-
|<code>string</code> || Record Name || Pascal-style, see [[#Strings|Strings]]
|-
|<code>string</code> || Description || Also Pascal-style, see [[#Descriptors|Descriptors]] for parsing information
|-
|<code>ulong</code> || Timestamp || UNIX timestamp of last change, seconds since 12:00 AM or 00:00 on January 1st, 1970
|-
|<code>ushort</code> || File Mode || UNIX file mode, `644` by default
|-
|<code>ushort</code> || File Owner || UNIX file owner ID, `0` by default
|-
|<code>ushort</code> || File Group || UNIX file group ID, `0` by default
|-
|<code>long</code> || Size || File size, in bytes.
|}

After the record, the file's content begins. If you just want to read the next record, you can skip `Size` bytes ahead and begin reading from there. Note that the archive's magic number is only seen once at the very beginning and does not repeat per-record.

===Strings===
Strings are encoded in Pascal-style, meaning they are prefaced by their length. The length is encoded as an unsigned 16-bit integer (`ushort`). Strings must be encoded as UTF-8.

===Descriptors===
Descriptors are stored as Pascal-style strings, but they have a strict format. Thankfully, the format is fairly easy to both assemble and parse.

Descriptors are an extensible key/value format for extra file metadata. They look like this:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false
</syntaxhighlight>

All keys and values are strings. Key/value pairs are separated by the semicolon (<code>;</code>, <code>U+003B</code>). The end of a key and the beginning of a value is denoted by the equals sign (<code>=</code>, <code>U+003E</code>).

Key/value pairs may be missing the value (see `bool1` above). In this case, it must be assumed that the value is <code>true</code>. A pair '''must''' contain at least the key.

A trailing semicolon is not required. All of the following are valid:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false;
key1=value1;key2=value2;bool1=true;bool2=false;
key1=value1;key2=value2;bool1;bool2=false
key1=value1;key2=value2;bool1=true;bool2=false
</syntaxhighlight>

Storing a semicolon (<code>;</code>) or equals sign (<code>=</code>) in a key or value is done by encoding it as a URL entity (<code>%3b</code> for semicolons, <code>%3e</code> for equals signs. This is case sensitive.) Note that no other URL entities are to be parsed or encoded.

The following is an example of an encoded equals sign in a value:

<syntaxhighlight line="1">
einstein-relativity=e%3emc^2;
</syntaxhighlight>

By storing information in a simple dictionary, the Jax archive format is extensible with up to 65,536 bytes of additional metadata. Take the following representation
of a partial Jax entry (in pseudocode):

<syntaxhighlight line="1">
[ type = 'r',
name = 'Test File.001',
description = ['nextFile': 'Test File.002',
'ownerName': 'John Doe',
'groupName': 'wheel' ],
size = 512000,
uid = 6756,
group = 12 ]
</syntaxhighlight>

This example is by no means part of the Jax standard, but it demonstrates a potential use case for the extensible key/value store.

==Utilities==

There is no official implementation of Jax yet. The cenix project contains a Jax implementation and utility capable of reading and writing Jax archives. It is available on [https://github.com/notvelleda/cenix/tree/main/jax GitHub].

Jax Archive

2024-09-07T02:56:47Z

JennyWakeman: /* Utilities */ new implementation :) thanks moff

'''Jax''' (or '''J'''enny's '''A'''rchive e'''X'''change) is an awful backronym and a simple archive format intended to be easy and cheap (processing power-wise) to parse. Structurally, it is similar to <code>tar</code>, while not being nearly as wasteful. Instead of fixed-length fields, it uses Pascal-style strings for archive names and descriptions, as well as an additional 'descriptor' field. The 'descriptor' is a simple key/value style field for additional metadata.

==Magic Number==
Jax archive formats all begin with the bytes <code>5E 6A 61 78</code> (<code>^jax</code> in ASCII.)

==Records==
Jax archives are structured as follows:

*Magic number
*Record for File 1
*Data for File 1
*Record for File 2
*Data for File 2
*...

Records are not aligned to any particular byte boundary and neither are the files within the archive, in the interest of creating smaller archives without the need for compression.

Records are structured as follows. Note that a <code>char</code> is an 8-bit unsigned integer, a <code>long</code> is a 64-bit signed integer, a <code>ulong</code> is a 64-bit unsigned integer, and a <code>ushort</code> is a 16-bit unsigned integer.

{| class="wikitable"
|+Jax archive record structure
|-
!Type!!Name!!Details
|-
|<code>char</code> || Record Type || <code>d</code> for directory, <code>s</code> for symbolic link, and <code>r</code> for a regular file.
|-
|<code>string</code> || Record Name || Pascal-style, see [[#Strings|Strings]]
|-
|<code>string</code> || Description || Also Pascal-style, see [[#Descriptors|Descriptors]] for parsing information
|-
|<code>ulong</code> || Timestamp || UNIX timestamp of last change, seconds since 12:00 AM or 00:00 on January 1st, 1970
|-
|<code>ushort</code> || File Mode || UNIX file mode, `644` by default
|-
|<code>ushort</code> || File Owner || UNIX file owner ID, `0` by default
|-
|<code>ushort</code> || File Group || UNIX file group ID, `0` by default
|-
|<code>long</code> || Size || File size, in bytes.
|}

After the record, the file's content begins. If you just want to read the next record, you can skip `Size` bytes ahead and begin reading from there. Note that the archive's magic number is only seen once at the very beginning and does not repeat per-record.

===Strings===
Strings are encoded in Pascal-style, meaning they are prefaced by their length. The length is encoded as an unsigned 16-bit integer (`ushort`). Strings must be encoded as UTF-8.

===Descriptors===
Descriptors are stored as Pascal-style strings, but they have a strict format. Thankfully, the format is fairly easy to both assemble and parse.

Descriptors are an extensible key/value format for extra file metadata. They look like this:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false
</syntaxhighlight>

All keys and values are strings. Key/value pairs are separated by the semicolon (<code>;</code>, <code>U+003B</code>). The end of a key and the beginning of a value is denoted by the equals sign (<code>=</code>, <code>U+003E</code>).

Key/value pairs may be missing the value (see `bool1` above). In this case, it must be assumed that the value is <code>true</code>. A pair '''must''' contain at least the key.

A trailing semicolon is not required. All of the following are valid:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false;
key1=value1;key2=value2;bool1=true;bool2=false;
key1=value1;key2=value2;bool1;bool2=false
key1=value1;key2=value2;bool1=true;bool2=false
</syntaxhighlight>

Storing a semicolon (<code>;</code>) or equals sign (<code>=</code>) in a key or value is done by encoding it as a URL entity (<code>%3b</code> for semicolons, <code>%3e</code> for equals signs. This is case sensitive.) Note that no other URL entities are to be parsed or encoded.

The following is an example of an encoded equals sign in a value:

<syntaxhighlight line="1">
einstein-relativity=e%3emc^2;
</syntaxhighlight>

By storing information in a simple dictionary, the Jax archive format is extensible with up to 65,536 bytes of additional metadata. Take the following representation
of a partial Jax entry (in pseudocode):

<syntaxhighlight line="1">
[ type = 'r',
name = 'Test File.001',
description = ['nextFile': 'Test File.002',
'ownerName': 'John Doe',
'groupName': 'wheel' ],
size = 512000,
uid = 6756,
group = 12 ]
</syntaxhighlight>

This example is by no means part of the Jax standard, but it demonstrates a potential use case for the extensible key/value store.

==Utilities==

There is no official implementation of Jax yet. The cenix project contains a Jax implementation and utility capable of reading and writing Jax archives. It is available on [https://github.com/notvelleda/cenix/tree/main/jax GitHub].

Jax Archive

2024-09-06T23:44:01Z

JennyWakeman: fix record types

'''Jax''' (or '''J'''enny's '''A'''rchive e'''X'''change) is an awful backronym and a simple archive format intended to be easy and cheap (processing power-wise) to parse. Structurally, it is similar to <code>tar</code>, while not being nearly as wasteful. Instead of fixed-length fields, it uses Pascal-style strings for archive names and descriptions, as well as an additional 'descriptor' field. The 'descriptor' is a simple key/value style field for additional metadata.

==Magic Number==
Jax archive formats all begin with the bytes <code>5E 6A 61 78</code> (<code>^jax</code> in ASCII.)

==Records==
Jax archives are structured as follows:

*Magic number
*Record for File 1
*Data for File 1
*Record for File 2
*Data for File 2
*...

Records are not aligned to any particular byte boundary and neither are the files within the archive, in the interest of creating smaller archives without the need for compression.

Records are structured as follows. Note that a <code>char</code> is an 8-bit unsigned integer, a <code>long</code> is a 64-bit signed integer, a <code>ulong</code> is a 64-bit unsigned integer, and a <code>ushort</code> is a 16-bit unsigned integer.

{| class="wikitable"
|+Jax archive record structure
|-
!Type!!Name!!Details
|-
|<code>char</code> || Record Type || <code>d</code> for directory, <code>s</code> for symbolic link, and <code>r</code> for a regular file.
|-
|<code>string</code> || Record Name || Pascal-style, see [[#Strings|Strings]]
|-
|<code>string</code> || Description || Also Pascal-style, see [[#Descriptors|Descriptors]] for parsing information
|-
|<code>ulong</code> || Timestamp || UNIX timestamp of last change, seconds since 12:00 AM or 00:00 on January 1st, 1970
|-
|<code>ushort</code> || File Mode || UNIX file mode, `644` by default
|-
|<code>ushort</code> || File Owner || UNIX file owner ID, `0` by default
|-
|<code>ushort</code> || File Group || UNIX file group ID, `0` by default
|-
|<code>long</code> || Size || File size, in bytes.
|}

After the record, the file's content begins. If you just want to read the next record, you can skip `Size` bytes ahead and begin reading from there. Note that the archive's magic number is only seen once at the very beginning and does not repeat per-record.

===Strings===
Strings are encoded in Pascal-style, meaning they are prefaced by their length. The length is encoded as an unsigned 16-bit integer (`ushort`). Strings must be encoded as UTF-8.

===Descriptors===
Descriptors are stored as Pascal-style strings, but they have a strict format. Thankfully, the format is fairly easy to both assemble and parse.

Descriptors are an extensible key/value format for extra file metadata. They look like this:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false
</syntaxhighlight>

All keys and values are strings. Key/value pairs are separated by the semicolon (<code>;</code>, <code>U+003B</code>). The end of a key and the beginning of a value is denoted by the equals sign (<code>=</code>, <code>U+003E</code>).

Key/value pairs may be missing the value (see `bool1` above). In this case, it must be assumed that the value is <code>true</code>. A pair '''must''' contain at least the key.

A trailing semicolon is not required. All of the following are valid:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false;
key1=value1;key2=value2;bool1=true;bool2=false;
key1=value1;key2=value2;bool1;bool2=false
key1=value1;key2=value2;bool1=true;bool2=false
</syntaxhighlight>

Storing a semicolon (<code>;</code>) or equals sign (<code>=</code>) in a key or value is done by encoding it as a URL entity (<code>%3b</code> for semicolons, <code>%3e</code> for equals signs. This is case sensitive.) Note that no other URL entities are to be parsed or encoded.

The following is an example of an encoded equals sign in a value:

<syntaxhighlight line="1">
einstein-relativity=e%3emc^2;
</syntaxhighlight>

By storing information in a simple dictionary, the Jax archive format is extensible with up to 65,536 bytes of additional metadata. Take the following representation
of a partial Jax entry (in pseudocode):

<syntaxhighlight line="1">
[ type = 'r',
name = 'Test File.001',
description = ['nextFile': 'Test File.002',
'ownerName': 'John Doe',
'groupName': 'wheel' ],
size = 512000,
uid = 6756,
group = 12 ]
</syntaxhighlight>

This example is by no means part of the Jax standard, but it demonstrates a potential use case for the extensible key/value store.

==Utilities==

None are officially released (as of September 6th, 2024) but several are in the works. The "reference implementation" (in a way) is Jenny's, written in Crystal. It is still a work in progress.

Jax Archive

2024-09-06T23:43:18Z

JennyWakeman: create page (feedback welcome!)

'''Jax''' (or '''J'''enny's '''A'''rchive e'''X'''change) is an awful backronym and a simple archive format intended to be easy and cheap (processing power-wise) to parse. Structurally, it is similar to <code>tar</code>, while not being nearly as wasteful. Instead of fixed-length fields, it uses Pascal-style strings for archive names and descriptions, as well as an additional 'descriptor' field. The 'descriptor' is a simple key/value style field for additional metadata.

==Magic Number==
Jax archive formats all begin with the bytes <code>5E 6A 61 78</code> (<code>^jax</code> in ASCII.)

==Records==
Jax archives are structured as follows:

*Magic number
*Record for File 1
*Data for File 1
*Record for File 2
*Data for File 2
*...

Records are not aligned to any particular byte boundary and neither are the files within the archive, in the interest of creating smaller archives without the need for compression.

Records are structured as follows. Note that a <code>char</code> is an 8-bit unsigned integer, a <code>long</code> is a 64-bit signed integer, a <code>ulong</code> is a 64-bit unsigned integer, and a <code>ushort</code> is a 16-bit unsigned integer.

{| class="wikitable"
|+Jax archive record structure
|-
!Type!!Name!!Details
|-
|<code>char</code> || Record Type || `d` for directory, `s` for symbolic link, and `r` for a regular file.
|-
|<code>string</code> || Record Name || Pascal-style, see [[#Strings|Strings]]
|-
|<code>string</code> || Description || Also Pascal-style, see [[#Descriptors|Descriptors]] for parsing information
|-
|<code>ulong</code> || Timestamp || UNIX timestamp of last change, seconds since 12:00 AM or 00:00 on January 1st, 1970
|-
|<code>ushort</code> || File Mode || UNIX file mode, `644` by default
|-
|<code>ushort</code> || File Owner || UNIX file owner ID, `0` by default
|-
|<code>ushort</code> || File Group || UNIX file group ID, `0` by default
|-
|<code>long</code> || Size || File size, in bytes.
|}

After the record, the file's content begins. If you just want to read the next record, you can skip `Size` bytes ahead and begin reading from there. Note that the archive's magic number is only seen once at the very beginning and does not repeat per-record.

===Strings===
Strings are encoded in Pascal-style, meaning they are prefaced by their length. The length is encoded as an unsigned 16-bit integer (`ushort`). Strings must be encoded as UTF-8.

===Descriptors===
Descriptors are stored as Pascal-style strings, but they have a strict format. Thankfully, the format is fairly easy to both assemble and parse.

Descriptors are an extensible key/value format for extra file metadata. They look like this:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false
</syntaxhighlight>

All keys and values are strings. Key/value pairs are separated by the semicolon (<code>;</code>, <code>U+003B</code>). The end of a key and the beginning of a value is denoted by the equals sign (<code>=</code>, <code>U+003E</code>).

Key/value pairs may be missing the value (see `bool1` above). In this case, it must be assumed that the value is <code>true</code>. A pair '''must''' contain at least the key.

A trailing semicolon is not required. All of the following are valid:

<syntaxhighlight line="1">
key1=value1;key2=value2;bool1;bool2=false;
key1=value1;key2=value2;bool1=true;bool2=false;
key1=value1;key2=value2;bool1;bool2=false
key1=value1;key2=value2;bool1=true;bool2=false
</syntaxhighlight>

Storing a semicolon (<code>;</code>) or equals sign (<code>=</code>) in a key or value is done by encoding it as a URL entity (<code>%3b</code> for semicolons, <code>%3e</code> for equals signs. This is case sensitive.) Note that no other URL entities are to be parsed or encoded.

The following is an example of an encoded equals sign in a value:

<syntaxhighlight line="1">
einstein-relativity=e%3emc^2;
</syntaxhighlight>

By storing information in a simple dictionary, the Jax archive format is extensible with up to 65,536 bytes of additional metadata. Take the following representation
of a partial Jax entry (in pseudocode):

<syntaxhighlight line="1">
[ type = 'r',
name = 'Test File.001',
description = ['nextFile': 'Test File.002',
'ownerName': 'John Doe',
'groupName': 'wheel' ],
size = 512000,
uid = 6756,
group = 12 ]
</syntaxhighlight>

This example is by no means part of the Jax standard, but it demonstrates a potential use case for the extensible key/value store.

==Utilities==

None are officially released (as of September 6th, 2024) but several are in the works. The "reference implementation" (in a way) is Jenny's, written in Crystal. It is still a work in progress.

User:JennyWakeman

2024-09-06T22:54:03Z

JennyWakeman: Created page with "daisy, daisy, give me your answer true"

daisy, daisy, give me your answer true