support viewing paired auditees by master-hax · Pull Request #318 · GrapheneOS/Auditor

master-hax · 2026-02-20T09:45:00Z

background

the web app (https://attestation.app) allows users to view all the paired auditees - this PR adds the same functionality to the mobile app

this is a prerequisite for fixing #51 as the pairings need to be identifiable & enumerable before they can be individually deleted or renamed.

changes

add a new activity InspectAuditeeActivity that allows a paired auditee to be viewed in detail (with selectable TextViews)
update AttestationProtocol.java to allow retrieving information about paired auditees
update AttestationActivity to include a list of fingerprints below the buttons
add new content layouts for auditee summary fields & the fingerprint list entities

screenshots

paired auditee list:
inspecting a single auditee pairing:
no paired auditees
horizontal layout (I have a camera cutout)
horizontal layout light mode
horizontal layout with navigation bar

cc @muhomorr @inthewaves

thestinger · 2026-02-23T07:03:20Z

Can you rebase this?

master-hax · 2026-02-23T07:14:27Z

Can you rebase this?

done, thanks for taking a look. looks to be passing the build now.

master-hax · 2026-02-23T07:17:44Z

the paired auditee list is not explicitly refreshed when a new auditee is added, but onCreate does seem to be called and refresh the list correctly in my testing.

also, my screenshot just shows the same fingerprint multiple times because i only have one auditable device for testing.

inthewaves · 2026-02-23T09:22:43Z

app/src/main/java/app/attestation/auditor/AttestationActivity.java

+        final TextView auditeeListLabel = findViewById(R.id.auditee_list_label);
+        final LinearLayout auditeesContainer = findViewById(R.id.auditee_list_values);
+        if (auditees.isEmpty()) {
+            auditeeListLabel.setText(R.string.paired_auditees_list_empty);
+            auditeesContainer.removeAllViews();
+            return;
+        }


I think it's better to use a RecyclerView here, since the app doesn't have a limit on the number of auditees

updated in 734502c - used androidx.core.widget.NestedScrollView to make the whole page scroll correctly.

i didn't implement this initially because i incorrectly thought this wouldn't provide value without the asynchronous file iterator - though i now realize we still get value from the recycled views.

though now, i'm realizing that the nested scroll view might negate the benefits of the recycler view...i think i may have to make the existing attestation content a header within the recycler view.

inthewaves · 2026-02-23T09:31:21Z

app/src/main/java/app/attestation/auditor/AttestationProtocol.java

+    }
+
+    static List<String> getAuditorFingerprints(final Context context) {
+        final File dir = new File(context.getFilesDir().getParent() + "/shared_prefs/");


might be better to use the same way how AOSP gets the preference directory:

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/ContextImpl.java;l=764

Suggested change

final File dir = new File(context.getFilesDir().getParent() + "/shared_prefs/");

final File dir = new File(context.getDataDir(), "shared_prefs");

but I did notice this was the code used elsewhere in the app already

given that this PR already has some significant changes, i think it would be good to limit the blast radius to make debugging / bisecting easier - could we make this change in a future PR?

though, i guess we may have to change this anyway to achieve the ask in #318 (comment)

Sure, I think issues like this could be handled later

are TODO comments acceptable? or shall i open an issue?

I think we should just open an issue for SharedPreference usage in general, and maybe make a TODO note that links to the issue

opened #321

inthewaves · 2026-02-23T09:35:08Z

app/src/main/java/app/attestation/auditor/AttestationActivity.java

            }
        });

+        final List<String> auditees = AttestationProtocol.getAuditorFingerprints(this);


This seems to do file system operations (listing files in a directory) on the main thread

good callout - fixed in 9396ebf, included an initial "loading paired auditees..." text for the label, & tested with a Thread.sleep(5000).

inthewaves · 2026-02-23T09:37:03Z

app/src/main/java/app/attestation/auditor/AttestationProtocol.java

+    static List<String> getAuditorFingerprints(final Context context) {
+        final File dir = new File(context.getFilesDir().getParent() + "/shared_prefs/");
+        ArrayList<String> auditees = new ArrayList<>();
+        final String[] sharedPreferenceFiles = dir.list();


Using a directory stream might be more efficient here, since all we need here is iteration over the files. Doc comments for java.io.File#list says:

Note that the java.nio.file.Files class defines the newDirectoryStream method to open a directory and iterate over the names of the files in the directory. This may use less resources when working with very large directories, and may be more responsive when working with remote directories.

Though again, I did notice this was how the app was doing this initially

this was my initial thought - to return an iterator from AttestationProtocol rather than a list. There were a few reasons why I didn't implement this initially:

keep in line with the existing code, reduce blast radius of this PR

inconsistent ordering of auditee pairings - currently I have the auditee list sorted consistently based on lexicographic comparison of hex representation of their fingerprints. however by using the iterator, the list ordering is not guaranteed to be the same every time the list is loaded - it is unclear what ordering the OS will use and whether it will be the same when called twice.

using an iterator does not provide random access to the filenames - e.g. if someone scrolls up, we can't go back to ask the iterator "hey could you remind me what the 5th filename was?" - meaning we will have to keep the entire list in memory as it loads. the iterator is still an efficiency win, but consumes the same amount of memory in the worst case scenario (when someone scrolls to the bottom of the list)

we are loading only a very small amount of data per pairing - each fingerprint string takes up only ~64 bytes iiuc (+ a pointer or whatever java does internally)

so i think using the iterator definitely does provide greater efficiency, but might not be worth these drawbacks + increased complexity. what do you think? i'm happy to implement this either way.

I see the reasoning and I agree, this should be fine then

re: the discussion on matrix - using sqlite solves problems 2 & 3 + also allows fancier ordering (like ordering by first or last verified time)

inthewaves · 2026-02-23T09:42:47Z

app/src/main/java/app/attestation/auditor/AttestationProtocol.java

+            final String deviceName = decapitatedFilename.substring(0, decapitatedFilename.length() - ".xml".length());
+            if (deviceName.isBlank()) {
+                continue;
+            }
+            auditees.add(deviceName);


deviceName variable seems to be a fingerprint

updated in 04c9314

inthewaves · 2026-02-23T09:44:59Z

app/src/main/res/layout/activity_inspectauditee.xml

+        <com.google.android.material.appbar.MaterialToolbar
+            android:id="@+id/toolbar"
+            android:layout_width="match_parent"
+            android:layout_height="?attr/actionBarSize" />


I think the toolbar in the new activity should show a back button, and the title in the toolbar should be something descriptive like "Viewing auditee"

added back button in 13975e1 - will update screenshots after other changes are done

added title in 3c92624

inthewaves · 2026-02-23T09:45:46Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+        if (fingerprint_hex == null || fingerprint_hex.isBlank()) {
+            Log.e(TAG, "auditee fingerprint not provided");
+            return;
+        }


Activity should finish and/or show some error message

given that we don't expect this case to happen regularly (if at all) - i think using the snackbar might be overkill - do you think a toast is reasonable?

Toast seems fine, and yeah, I think this would only happen through programming error anyway

there is a different issue, where any random string can be passed as the fingerprint, which will cause the activity to display default values.

i think it is technically possible for a user to click the "clear auditor pairings" menu button, then click on an auditee before the clearing code is completely run.

we could temporarily disable the auditees list or do some locking to prevent this - but someone using adb or system settings to clear the app data while the app is running could still cause this.

added toast & activity finishing behavior in f5a9eca

inthewaves · 2026-02-23T09:56:48Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+        addSummaryField("fingerprint", fingerprint_hex);
+        addSummaryField("first verified", new Date(summary.verifiedTimeFirst()).toString());
+        addSummaryField("last verified", new Date(summary.verifiedTimeLast()).toString());
+        addSummaryField("verified boot key", summary.verifiedBootKey());
+        addSummaryField("pinned OS version", String.valueOf(summary.pinnedOsVersion()));
+        addSummaryField("pinned OS patch level", String.valueOf(summary.pinnedOsPatchLevel()));
+        addSummaryField("pinned vendor patch level", String.valueOf(summary.pinnedVendorPatchLevel()));
+        addSummaryField("pinned boot patch level", String.valueOf(summary.pinnedBootPatchLevel()));
+        addSummaryField("pinned app version", String.valueOf(summary.pinnedAppVersion()));
+        addSummaryField("pinned app variant", String.valueOf(summary.pinnedAppVariant()));
+        addSummaryField("pinned security level", String.valueOf(summary.pinnedSecurityLevel()));


I think we should use the strings for these labels in res/values/strings.xml, though they might need to be adapted here, since they have new line chars in them

The "Information provided by the verified OS" section should probably be here, but I don't think the app is currently storing that info (unlike the server), so we can leave that for now

For consistency, I think we should have sections here like the web app. The "first verified" and "last verified" should be under an "Attestation history" section, and the other fields should be under a "Hardware verified information" section.

for 1, the existing strings in strings.xml have control characters + format placeholders in them, so i don't think it is viable to use them. i can add these to strings.xml though.

fixed 2 & 3 in 4aac0f3 based on the web app + updated the screenshot in the PR description

fixed 1 in 3d4d301

master-hax · 2026-02-24T10:21:11Z

the paired auditee list is not explicitly refreshed when a new auditee is added, but onCreate does seem to be called and refresh the list correctly in my testing.

also, my screenshot just shows the same fingerprint multiple times because i only have one auditable device for testing.

realized this was from the recreate() call when the back button is pressed. might need to be updated when delete or rename functionality is added.

inthewaves

Just some UI changes

inthewaves · 2026-02-24T19:57:00Z

app/src/main/res/layout/content_attestation.xml

+                <androidx.recyclerview.widget.RecyclerView
+                    android:id="@+id/auditee_list_recycler"
+                    android:layout_width="match_parent"
+                    android:layout_height="0dp"
+                    android:layout_weight="1"
+                    android:clipToPadding="false"
+                    android:scrollbars="vertical"
+                    android:nestedScrollingEnabled="true"/>


After thinking about it, I believe we should apply the same left and right margins as everything else (buttons, auditee_list_label, introduction text, etc.)

updated in 5f75e68

inthewaves · 2026-02-24T19:58:01Z

app/src/main/res/values/strings.xml

+    <string name="inspect_auditee_title">inspect auditee</string>
+    <string name="inspect_auditee_os_provided_info">information from the verified OS</string>
+    <string name="inspect_auditee_hardware_verified">hardware verified information</string>
+    <string name="inspect_auditee_attestation_history">attestation history</string>
+    <string name="inspect_auditee_error_message_missing_fingerprint">auditee fingerprint was not provided</string>
+
+    <string name="inspect_auditee_field_name_fingerprint">fingerprint</string>
+    <string name="inspect_auditee_field_name_pinned_security_level">security level</string>
+    <string name="inspect_auditee_field_name_pinned_os_version">OS version</string>
+    <string name="inspect_auditee_field_name_pinned_os_patch_level">OS patch level</string>
+    <string name="inspect_auditee_field_name_pinned_vendor_patch_level">vendor patch level</string>
+    <string name="inspect_auditee_field_name_pinned_boot_patch_level">boot patch level</string>
+    <string name="inspect_auditee_field_name_verified_boot_key">verified boot key</string>
+    <string name="inspect_auditee_field_name_pinned_app_version">app version</string>
+    <string name="inspect_auditee_field_name_pinned_app_variant">app variant</string>
+    <string name="inspect_auditee_field_name_first_verified">first verified</string>
+    <string name="inspect_auditee_field_name_last_verified">last verified</string>


Think we should capitalize the first words for consistency

do you mean consistency with the web app or the rest of this app?

i personally feel that non-capitalized strings look better in the UI, especially in a table - are there project wide design guidelines for this kind of thing? happy to update it either way.

I don't personally have an issue with non-capitalized strings, but I'd say we want to have consistency with the web app/rest of the app

I don't think we have explicit guidelines for design (we do loosely follow Material Design when possible), but the rest of our standalone apps also keep things capitalized. e.g., PdfViewer also has a "table" (constrained by dialog window) of properties:

updated in b5cdf9b

inthewaves · 2026-02-24T19:59:18Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+            runOnUiThread(() -> {
+                Toast.makeText(
+                        this,
+                        R.string.inspect_auditee_error_message_missing_fingerprint,
+                        Toast.LENGTH_SHORT
+                ).show();


I believe this should be unnecessary; onCreate already runs on the UI/main thread

fixed in bdd0634

inthewaves · 2026-02-24T20:56:57Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_fingerprint, fingerprint_hex);
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_pinned_security_level, String.valueOf(summary.pinnedSecurityLevel()));
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_pinned_os_version, String.valueOf(summary.pinnedOsVersion()));
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_pinned_os_patch_level, String.valueOf(summary.pinnedOsPatchLevel()));
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_pinned_vendor_patch_level, String.valueOf(summary.pinnedVendorPatchLevel()));
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_pinned_boot_patch_level, String.valueOf(summary.pinnedBootPatchLevel()));
+        addSummaryFieldToTable(R.id.summary_hardware, R.string.inspect_auditee_field_name_verified_boot_key, summary.verifiedBootKey());
+
+        addSummaryFieldToTable(R.id.summary_os, R.string.inspect_auditee_field_name_pinned_app_version, String.valueOf(summary.pinnedAppVersion()));
+        addSummaryFieldToTable(R.id.summary_os, R.string.inspect_auditee_field_name_pinned_app_variant, String.valueOf(summary.pinnedAppVariant()));
+
+        addSummaryFieldToTable(R.id.summary_history, R.string.inspect_auditee_field_name_first_verified, new Date(summary.verifiedTimeFirst()).toString());
+        addSummaryFieldToTable(R.id.summary_history, R.string.inspect_auditee_field_name_last_verified, new Date(summary.verifiedTimeLast()).toString());


I think these fields should have user-readable strings where possible, e.g. security level has various strings handled at appendVerifiedInformation (

Auditor/app/src/main/java/app/attestation/auditor/AttestationProtocol.java

Lines 845 to 900 in 6483efc

private static void appendVerifiedInformation(final Context context,

final StringBuilder builder, final Verified verified, final String fingerprint,

final boolean attestKeyMigration) {

final StringBuilder splitFingerprint = new StringBuilder();

for (int i = 0; i < fingerprint.length(); i += FINGERPRINT_SPLIT_INTERVAL) {

splitFingerprint.append(fingerprint.substring(i,

Math.min(fingerprint.length(), i + FINGERPRINT_SPLIT_INTERVAL)));

if (i + FINGERPRINT_SPLIT_INTERVAL < fingerprint.length()) {

splitFingerprint.append("-");

}

}

builder.append(context.getString(R.string.identity, splitFingerprint.toString()));

final String securityLevel;

if (verified.securityLevel == ParsedAttestationRecord.securityLevelToInt(ParsedAttestationRecord.SecurityLevel.STRONG_BOX)) {

if (verified.attestKey && !attestKeyMigration) {

securityLevel = context.getString(R.string.security_level_strongbox_attest_key);

} else {

securityLevel = context.getString(R.string.security_level_strongbox);

}

} else {

if (verified.attestKey && !attestKeyMigration) {

securityLevel = context.getString(R.string.security_level_tee_attest_key);

} else {

securityLevel = context.getString(R.string.security_level_tee);

}

}

builder.append(context.getString(R.string.security_level, securityLevel));

builder.append(context.getString(R.string.device, context.getString(verified.device)));

builder.append(context.getString(R.string.os, context.getString(verified.osName)));

final String osVersion = String.format(Locale.US, "%06d", verified.osVersion);

builder.append(context.getString(R.string.os_version,

Integer.parseInt(osVersion.substring(0, 2)) + "." +

Integer.parseInt(osVersion.substring(2, 4)) + "." +

Integer.parseInt(osVersion.substring(4, 6))));

builder.append(context.getString(R.string.os_patch_level, formatPatchLevel(verified.osPatchLevel)));

if (verified.vendorPatchLevel != 0) {

builder.append(context.getString(R.string.vendor_patch_level, formatPatchLevel(verified.vendorPatchLevel)));

}

if (verified.bootPatchLevel != 0) {

builder.append(context.getString(R.string.boot_patch_level, formatPatchLevel(verified.bootPatchLevel)));

}

builder.append(context.getString(R.string.verified_boot_key_hash,

verified.verifiedBootKey));

if (verified.verifiedBootHash != null) {

builder.append(context.getString(R.string.verified_boot_hash,

BaseEncoding.base16().encode(verified.verifiedBootHash)));

}

}

), variant is converted to strings at https://github.com/GrapheneOS/Auditor/blob/main/app/src/main/java/app/attestation/auditor/AttestationProtocol.java#L1072-L1115, formatPatchLevel, etc.

Some of these methods for user-readable strings fortunately have static methods for use, but others are embedded in the AttestationProtocol methods and could be refactored for use here

agree that it is ideal to show the human readable strings - however given that:

we have many other existing display differences with the web app (different fingerprint display format, missing fields not stored in mobile, display of certificate info, etc.)

the current numbers are still useful despite not being fully human readable

we have to fix the history strings to remove the control characters & format specifiers before they can be easily repurposed

is this something we can implement in a future PR? happy to implement it either way.

Yes, I agree that cleaning up the rest of the UI code to make it reusable elsewhere/making it consistent can be done in a future PR

inthewaves · 2026-02-24T20:57:29Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+        final String fingerprint_hex = getIntent().getStringExtra(INTENT_KEY_FINGERPRINT);
+        if (fingerprint_hex == null || fingerprint_hex.isBlank()) {


nit: let's use camelCase

fixed in e8739cd

inthewaves · 2026-02-24T21:22:36Z

app/src/main/java/app/attestation/auditor/InspectAuditeeActivity.java

+    protected void onCreate(Bundle savedInstanceState) {
+        super.onCreate(savedInstanceState);
+        setContentView(R.layout.activity_inspectauditee);


Some issues with this activity:

Navigation bar can display over the contents

Status bar text such as clock, notification icons are not visible in light theme

AttestationActivity should have code that handles this, as this doesn't occur on AttestationActivity

Interesting - good catch. I'm able to reproduce the color issue but not able to reproduce the layout issue on my SM-S928U1 - see screenshots. I think you're right, I missed some compatibility code from AttestationActivity.

EDIT: nm it does avoid my camera cutout & navigation bar after the fix

color issue is fixed with EdgeToEdge.enable(this); in d33414d

fixed insets in 9cb9a12 & e219aaa - it did stop the text from overlaying the camera cutout + buttons simultaneously (when i turned off gestures) do you mind verifying the fix on your side?

umm for some reason my phone fails to take a screenshot in landscape mode now...

the auto inset fix method in general seems a little hacky but is probably unavoidable to get good backwards compatibility i guess. i can't deny that it works effectively.

updated the screenshots in the PR description

do you mind verifying the fix on your side?

Looks good now

master-hax · 2026-03-17T02:48:40Z

cc @inthewaves can we merge this?

master-hax marked this pull request as ready for review February 20, 2026 10:25

This was referenced Feb 21, 2026

add interface for browsing pairings with support for deleting them like the web interface for the remote attestation service, replacing the clear options in the menu #51

Open

update gradle verification metadata #319

Merged

thestinger force-pushed the main branch from 2f36402 to 6483efc Compare February 23, 2026 07:03

master-hax added 3 commits February 23, 2026 07:13

inspect paired auditees

4c1852e

reduce column weight

50e0d93

make onClick area larger + nits

e584d3d

master-hax force-pushed the inspect_auditees branch from 8eadd43 to e584d3d Compare February 23, 2026 07:13

rename layout

80a79de

inthewaves suggested changes Feb 23, 2026

View reviewed changes

master-hax added 8 commits February 24, 2026 06:25

rename variables

04c9314

add back button

13975e1

add title to inspect auditee activity

3c92624

add separate summary sections

4aac0f3

get auditor fingerprints on background thread

9396ebf

rename layout

1311129

show toast & finish activity on missing fingerprint

f5a9eca

use RecyclerView for auditee list

734502c

master-hax requested a review from inthewaves February 24, 2026 10:13

visibility nit

b3cbc25

master-hax added 4 commits February 24, 2026 10:30

move strings to strings.xml

3d4d301

naming nit

e2e13e7

layout nit

ebd6828

string + visual nits

455fc37

inthewaves suggested changes Feb 24, 2026

View reviewed changes

already in UI thread

bdd0634

master-hax added 5 commits February 25, 2026 04:56

naming + nits

e8739cd

fix status bar color issue

d33414d

fix insets

9cb9a12

scrollbar should also be inside the margin

e219aaa

use predefined padding dimensions

5f75e68

master-hax requested a review from inthewaves February 25, 2026 05:57

capitalize strings

b5cdf9b

master-hax force-pushed the inspect_auditees branch from f0bdc04 to b5cdf9b Compare February 26, 2026 04:51

thestinger force-pushed the main branch from 8e99620 to 0de6ca8 Compare March 24, 2026 17:53

	final File dir = new File(context.getFilesDir().getParent() + "/shared_prefs/");
	final File dir = new File(context.getDataDir(), "shared_prefs");

	private static void appendVerifiedInformation(final Context context,
	final StringBuilder builder, final Verified verified, final String fingerprint,
	final boolean attestKeyMigration) {
	final StringBuilder splitFingerprint = new StringBuilder();
	for (int i = 0; i < fingerprint.length(); i += FINGERPRINT_SPLIT_INTERVAL) {
	splitFingerprint.append(fingerprint.substring(i,
	Math.min(fingerprint.length(), i + FINGERPRINT_SPLIT_INTERVAL)));
	if (i + FINGERPRINT_SPLIT_INTERVAL < fingerprint.length()) {
	splitFingerprint.append("-");
	}
	}
	builder.append(context.getString(R.string.identity, splitFingerprint.toString()));

	final String securityLevel;
	if (verified.securityLevel == ParsedAttestationRecord.securityLevelToInt(ParsedAttestationRecord.SecurityLevel.STRONG_BOX)) {
	if (verified.attestKey && !attestKeyMigration) {
	securityLevel = context.getString(R.string.security_level_strongbox_attest_key);
	} else {
	securityLevel = context.getString(R.string.security_level_strongbox);
	}
	} else {
	if (verified.attestKey && !attestKeyMigration) {
	securityLevel = context.getString(R.string.security_level_tee_attest_key);
	} else {
	securityLevel = context.getString(R.string.security_level_tee);
	}
	}
	builder.append(context.getString(R.string.security_level, securityLevel));

	builder.append(context.getString(R.string.device, context.getString(verified.device)));
	builder.append(context.getString(R.string.os, context.getString(verified.osName)));

	final String osVersion = String.format(Locale.US, "%06d", verified.osVersion);
	builder.append(context.getString(R.string.os_version,
	Integer.parseInt(osVersion.substring(0, 2)) + "." +
	Integer.parseInt(osVersion.substring(2, 4)) + "." +
	Integer.parseInt(osVersion.substring(4, 6))));

	builder.append(context.getString(R.string.os_patch_level, formatPatchLevel(verified.osPatchLevel)));

	if (verified.vendorPatchLevel != 0) {
	builder.append(context.getString(R.string.vendor_patch_level, formatPatchLevel(verified.vendorPatchLevel)));
	}

	if (verified.bootPatchLevel != 0) {
	builder.append(context.getString(R.string.boot_patch_level, formatPatchLevel(verified.bootPatchLevel)));
	}

	builder.append(context.getString(R.string.verified_boot_key_hash,
	verified.verifiedBootKey));

	if (verified.verifiedBootHash != null) {
	builder.append(context.getString(R.string.verified_boot_hash,
	BaseEncoding.base16().encode(verified.verifiedBootHash)));
	}
	}

		final String fingerprint_hex = getIntent().getStringExtra(INTENT_KEY_FINGERPRINT);
		if (fingerprint_hex == null \|\| fingerprint_hex.isBlank()) {

Uh oh!

Conversation

master-hax commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

background

changes

screenshots

Uh oh!

thestinger commented Feb 23, 2026

Uh oh!

master-hax commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

master-hax commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

master-hax commented Feb 20, 2026 •

edited

Loading

master-hax commented Feb 23, 2026 •

edited

Loading

master-hax commented Feb 23, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 24, 2026 •

edited

Loading

master-hax Feb 25, 2026 •

edited

Loading

inthewaves Feb 25, 2026 •

edited

Loading