This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
Commands received the biggest change in this snapshot. With the help of the new Brigadier function and the advanced command execution implementation, commands were significantly enhanced.
Fabric API 0.90.1 was released, with no breaking changes.
There is no progress on last week's block codecs. This week, we instead saw a massive refactor in commands.
Date: 02.09.2022
Last Update: 24.12.2022
Author: Aizistral
In collaboration with: ejaussie, also known as British Empireball#3906
While I wish this could have been conducted sooner, this is the first verifiable ban case where I could contact the person banned. Some couple weeks ago I even purchased second Minecraft account with the sole intent of committing what would appear as bannable offense and being reported by one of my friends afterwards, which I sucessfully did; however, no action from moderation team followed. At the time this lead me to conclude that reports are not yet actioned on, which was perfectly explainable by unfixed exploits with chat reporting in 1.19.2. This case might indicate that reports are indeed actioned now, at least since the date of this research, but it is also possible that ban occured due to automated chat monitoring on Realms (see [Our Commitment to Player Safe
This gist intends on clearing up some of the misinformation surrounding signed chat/the reporting feature Mojang has added to Minecraft 1.19.1. Here you can find both technical information as well as a general explanation of how these work.
After joining a server, clients now send a profile key used for verifying a message's authenticity. This key and thus the whole signing process is optional, but by default, servers enforce secure profiles for clients to send chat messages. Whenever the player sends a chat message and has a key associated, the message will be signed using their own private key, which the server then verifies using the public key sent after join. Assuming signature, timestamp, and message contents line up, the message goes through.
On the other end, clients can also require all broadcasted player messages to be signed, disregarding the ones without sender verified signatures.
| // To compile: clang++ -arch x86_64 -arch arm64 -std=c++20 library_injector.cpp -lbsm -lEndpointSecurity -o library_injector, | |
| // then codesign with com.apple.developer.endpoint-security.client and run the | |
| // program as root. | |
| #include <EndpointSecurity/EndpointSecurity.h> | |
| #include <algorithm> | |
| #include <array> | |
| #include <bsm/libbsm.h> | |
| #include <cstddef> | |
| #include <cstdint> |
Discord timestamps can be useful for specifying a date/time across multiple users time zones. They work with the Unix Timestamp format and can be posted by regular users as well as bots and applications.
The Epoch Unix Time Stamp Converter is a good way to quickly generate a timestamp. For the examples below I will be using the Time Stamp of 1543392060, which represents November 28th, 2018 at 09:01:00 hours for my local time zone (GMT+0100 Central European Standard Time).
| Style | Input | Output (12-hour clock) | Output (24-hour clock) |
|---|---|---|---|
| Default | <t:1543392060> |
November 28, 2018 9:01 AM | 28 November 2018 09:01 |
| @import Darwin; | |
| @import ObjectiveC; | |
| @import CloudKit; | |
| extern bool GEOConfigGetBOOL(int feature, void* something); | |
| // Hooks feature flags in a resigned Maps.app to return true. | |
| // Usage: | |
| // clang -shared -fmodules -o libmaps_inject.dylib maps_inject.m \ | |
| // "$(xcrun |
