tera-arise / arise Goto Github PK

https://github.com/tera-arise/arise/tree/master/src/tools/mapper

Lots of research to be done here still.

• Randomization of packet codes.
• Patching-in of data center key/IV.
• Removal of game protection in server-side modules.
• Patching of module validity duration checks.
• Time-based module rotation.
• Random module selection for game connections.

https://www.nuget.org/packages/Serilog.AspNetCore

• Some basic styling.
• Background image and logo matching the launcher.
• Some paragraphs describing the project.
• Ability to list and view Markdown-based news articles.
• Download page that grabs the latest release on arise-release by querying the GitHub API.

• https://en.wikipedia.org/wiki/Argon2
• https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id

There are third-party implementations on NuGet but I don't particularly trust their correctness or performance. Would rather wait for native .NET support.

Blocked on:

• dotnet/runtime#19933
• openssl/openssl#12256

This is a very, very long term project that will require a lot of experimentation.

The idea is to completely rip out the ancient, slow, and ugly Scaleform GFx UI from the game. We would replace it with a new UI, written from scratch, using Avalonia.

Here's what I think we would roughly have to do:

• Remove all calls to Scaleform GFx in the client.
• Hook any functions necessary to get game notifications relevant to the UI subsystem.
• Figure out how to forward relevant keyboard/mouse/controller input events to the UI subsystem.
• Write an Avalonia platform backend that hooks into the game's rendering.
• Actually implement the entire game UI. 😰

For the Avalonia backend, I think we would basically just do a classic IDXISwapChain::Present() hook. In the hook, we make Avalonia render using Direct2D or Win2D, which should be fairly easy since Avalonia already has an official Direct2D backend that we can learn from. Using Direct2D is advantageous because it can interoperate with Direct3D.

Note: TERA only works with DirectX 11.0+ since the 64-bit upgrade. However, Direct2D/Direct3D interop will require Direct3D feature level 11.1. Unfortunately, the client currently hardcodes feature level 11.0 when calling D3D11CreateDevice(), so we will need to patch that.

This is only used for deploying the client, so we should just generate it as part of the normal build.

Need to test and verify that this doesn't cause security crashes.

See: https://github.com/JasperFx/marten/milestone/82

There needs to be a way to point the build system to a 'vendor project' that can control a few things:

• The certificate authority for mTLS.
• The data center key and IV.
• The game revision number.
• The path to grab news articles from.

Usage should look something like ./cake -c Release --vendor path/to/vendor.proj. The build system will build that project (if necessary) and then grab whatever it needs from it using well-known target names. If --vendor is not specified, the defaults in this repository will be used, which should be fine for development/contribution purposes.

As part of this effort, also make sure that we remove stuff like this from the repository:

• References to official URLs, e.g. this.
• Official news articles.
• Official staging and production configuration files.
• Official deployment workflows.
• Official Systemd unit files.

Blocked on:

• https://gitlab.com/gnutls/gnutls/-/issues/1441

• Simplified abstractions around QUIC connections and streams.
• mTLS with strict verification based on the certificates we generate.
• Automatic packet serialization system based on dynamic code generation.
• Operation code mappings directed by the bridge module.
• Handler dispatch system based on reflection?

This will be needed by the launcher. We don't want to have to open a game connection just to fetch articles.

As with geometry (#48 (comment)), we will use a separate repository for data center sheets, namely arise-data. This will allow us to keep it as a shallow submodule.

After we load the client into memory and perform our modifications, we should checksum the client's code segment periodically.

• Update global.json.
• Update all packages in Directory.Packages.props.
• Update all tools in dotnet-tools.json.
• Update diagnostic rules in .globalconfig.
• Maybe other stuff I'm forgetting.

Should also add a call to AssertDatabaseMatchesConfigurationOnStartup() after ApplyAllDatabaseChangesOnStartup().

Blocked on:

• JasperFx/marten#2414

In particular for actions that send emails.

Files: https://github.com/tera-arise/arise/tree/9fdf9bbab65fa14c3404d5e0292f290676d88cae/src/client/launcher/Assets

The vendor project should be able to provide these for the launcher and website. We should still include some default assets in this repository.

• Main window with background image, logo, music, and news articles.
• Gateway and world server URI input (for non-vendored builds only).
• Account creation, authentication, email/password change, password recovery, and deletion flows.
• Account status display (unverified, incomplete email change, deletion countdown, ban reason/countdown).
• Installation, update, and repair flows for TERA.
• Update and repair flows for TERA Arise.
• Game launch flow.

See: https://github.com/AvaloniaUI/Avalonia/milestone/13

Using this library: https://github.com/Lachee/discord-rpc-csharp

The application ID should be configurable from the vendor project. Ours is 1145819827861196880.

This was put in place by f83ff17. We will need to get rid of this.

Hopefully "getting rid of it" means that this bug is fixed:

• dotnet/runtime#3828

We need to be able to strip server-side data from the data center to reduce download size. This will require build changes to perform the XSLT transformations, but also to produce different Arise.Data.dll assemblies for client and server.

• https://github.blog/2024-01-03-our-move-to-generated-sdks
• https://www.nuget.org/packages/Octokit.NET.SDK

This should be configurable in the regular configuration files. It should be implemented as a bot rather than using webhooks, so we're less likely to run into rate limiting.

We'll use this library: https://github.com/discord-net/Discord.Net

• Remove support for the damage meter named pipe.
• Make S1DataDB::Initialize crash unless we've hooked it appropriately.
• Make S1Connection::{Connect,Disconnect}, S1ConnectionManager::SendPacket, and S1CommandQueue::RunCommands crash unless we've hooked it appropriately.
• Make isCompanyDomain and isDevDomain always return false without even checking network configuration.

Maybe other stuff?

Can't actually deploy arised at all without it.

Blocked on:

• microsoft/msquic#3296

Right now, the LowPriority/NormalPriority/HighPriority split for conduits only has the effect of letting packets get received/sent in each concurrently. We need the .NET QUIC APIs to get support for stream priorities so that the underlying QUIC implementation will also prioritize sends.

Depends on:

• jstedfast/EmailValidation#41

See: vezel-dev/novadrop#86

All of our interop bindings need to be moved to Novadrop at some point.

We should probably use this library to make life easier: https://github.com/reactiveui/refit

I'm thinking that we could keep a Dictionary<(int ZoneX, int ZoneY), SoftReference<SpatialZone>> or similar (SoftReference<T>). This would let the geometry data get unloaded when there are no strong references to it. This only works well if we hand out SpatialZone references to callers, which we might not want to do. 🤔

An alternative would be to use a MemoryCache with custom eviction logic. For example, we could say that a SpatialZone that hasn't been queried in a while is probably fine to unload.

Task.Delay() has around ~15 ms of overhead on Windows and ~10 ms on Linux. This is likely to be too much for some combat simulation tasks in the world server.

On Windows, we can implement a custom timer queue backed by CreateWaitableTimerExW (with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag) and SetWaitableTimer (with negative lpDueTime to avoid clock skew).

On Linux, we can use clock_nanosleep (with CLOCK_MONOTONIC_RAW to avoid clock skew) in a dedicated thread. We would need to send the thread a signal with pthread_kill when the due time needs to be updated.

.NET 8 already has SHA-3 support in the previews, so we can make this switch.

However, it's not clear what our iteration count should be, and OWASP does not yet cover SHA-3: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2

c9afc56 removed trimming from the build system. While full trimming is impractical for us, we could explore partial trimming. I think we only do reflection on our own assemblies, so there should be no issue with trimming any third-party assemblies that declare themselves trimmable.

Right now, a client release archive with maximum compression is around 171 MB, which seems rather excessive.

Just needs some basic logging so we get a sense of how long the loading takes.

This will be needed by the launcher. As with articles (#8), we don't want to have to open a game connection to create an account. The same should probably be the case for changing password, and similar tasks.

This is the only part of the workflow that litters untracked files in the source tree. We should generate these files as part of the regular build and grab them from the output directory.

We need to know exactly which parts we actually need to keep around. Parts of the data center that are leftovers from removed features or are only used on the server side can be excluded.