RF455-162 Target display and anti cheat password

BUG REPORT RF Online 4.55 (GoMMO) Target Level Display Corruption and Anti-Cheat Password Persistence Failure

Report ID: GOMMO-RFO455-2026-1113-01 Date: 13 November 2026 Product: RF Online 4.55 (GoMMO) Report type: Functional defect - client/UI data handling and account security Severity: High (BUG-01) / High (BUG-02) Priority: P1 - both defects reproduce on every attempt Status: Open - awaiting triage Language: English

1. EXECUTIVE SUMMARY

------------------------------------------------------------------------

Two independent, fully reproducible defects were found in RF Online 4.55 on GoMMO. Neither is cosmetic: the first corrupts the information a player uses to decide whether an engagement is survivable, and the second leaves an account-security feature permanently unconfigured while giving the user no indication that it failed.

BUG-01 - Target level display is corrupted for player characters and NPCs.

Monsters display the correct level. Player characters and NPCs do not.

• When a player character is targeted, the level shown in the target window changes on every acquisition and is a multi-digit garbage value. It is never the character's real level.

• When an NPC is targeted, the level shown is the level of the previously targeted entity (a monster or a player). The NPC's own level is never displayed.

The pattern indicates two distinct faults in the same target-information path: player targets read the level from a wrong or uninitialised source, and NPC targets never update the field at all, so stale data from the previous target is rendered.

BUG-02 - The anti-cheat password on a Play account cannot be set.

Any attempt to configure the anti-cheat password for a Play account silently fails. The value is never persisted and never enforced, regardless of password content, length, browser, session or relog. The account remains without the protection the feature is supposed to provide.

Both defects reproduced on every attempt during the test session and were observed on the live production realm.

2. TEST ENVIRONMENT

------------------------------------------------------------------------

Game client: RF Online 4.55 (GoMMO build) Server/realm: GoMMO production Account type: Play account (standard player account) Platform: Windows, 64-bit, full-screen client Reproducibility: Consistent - every attempt (both defects)

No special configuration, add-on or client modification is required to observe either defect; both appear on a standard client install.

3. BUG-01 - TARGET LEVEL DISPLAY CORRUPTION (PLAYER CHARACTERS AND NPCs)

------------------------------------------------------------------------

3.1 Summary

The level value rendered in the target information window is correct only for monsters. For player characters it is random multi-digit garbage that changes on every re-target; for NPCs it is the level of the previously targeted entity.

3.2 Severity and impact

Severity: High.

• The target window is the primary source of threat assessment in RF Online. A wrong level directly causes bad engagement decisions, avoidable deaths and lost EXP/items.
• The value is not merely wrong but unstable for players, so the player cannot even learn to compensate for a constant offset.
• For NPCs the display is actively misleading: it presents a monster's or a player's level as if it belonged to the NPC, which can make a harmless NPC look like a high-level threat, or a dangerous NPC look trivial.
• The defect is visible to every player in every session and is therefore also a credibility issue for the server.

3.3 Preconditions

• Character is logged in and able to target entities.
• At least one monster, one player character and one NPC are available in the current zone.

3.4 Steps to reproduce

Scenario A - Baseline: monster target (control)

1. Log in and move to a zone containing monsters.
2. Target a monster whose level is known (for example from the monster's name/con colour or a database reference).
3. Read the level shown in the target window.

Result: the monster's level is displayed correctly and remains stable while the target is held.

Scenario B - Player character target

1. Target another player character whose level is known (confirmed via party window, character sheet, or the player themselves).
2. Read the level in the target window.
3. Clear the target, re-target the same character, and read the level again. Repeat at least five times.
4. Repeat with two or three different player characters.

Result: every acquisition shows a different multi-digit number. None of the values equals the character's true level.

Scenario C - NPC target

1. Target a monster or a player character and note the level shown.
2. Without clearing the target first, target an NPC.
3. Read the level shown for the NPC.

Result: the NPC displays the level of the previously targeted monster or player, not its own level.

Scenario D - Target switching sequence

1. Target monster, then player, then NPC, then monster, then NPC, reading the level after each acquisition.
2. Note which acquisitions update the value and which retain the previous one.

Result: monster acquisitions update the value correctly; player acquisitions replace it with a new garbage value; NPC acquisitions retain whatever was displayed before.

3.5 Expected vs. actual

Monster target Expected: correct, stable level Actual: correct, stable level (passes - this is the control case)

Player character target Expected: correct, stable level, identical to the character's real level Actual: random multi-digit value, different on every acquisition, never correct

NPC target Expected: the NPC's own level Actual: level of the previously targeted entity (stale value)

3.6 Observed value pattern

Monster (control) Displayed value equals the monster's real level, and does not change when the same monster is re-targeted repeatedly.

Player character Displayed value does not equal the character's real level. It is a multi-digit value well outside the plausible level range, and it changes on every acquisition of the same character.

NPC Displayed value equals the level of whichever entity was targeted immediately before the NPC. It does not change when the NPC itself is acquired.

The distinguishing detail is the direction of the error: the player value changes even when the target does not, while the NPC value never changes when the target does. Publish the exact captured numbers alongside the screenshots if they are available; they are the strongest evidence that the player-character value is uninitialised or misread data rather than a valid level belonging to another entity.

3.7 Preliminary technical analysis (unconfirmed - for the development team)

The three behaviours together are diagnostic.

1. Monsters are correct. The target-information pipeline, the UI binding and the level formatting all work. The fault is therefore in the source data selected per entity type, not in the renderer.

2. Player characters vary per acquisition and are multi-digit. A value that changes every time the same target is re-acquired is characteristic of reading memory that is not initialised for that entity type: for example a level field taken from the wrong offset in a different structure, an uninitialised local buffer, or a field that is only populated for monster entities. It is not a constant offset error, and it is not a stale-cache error, because the value would then be stable.

3. NPCs retain the previous target's level. This is the signature of a missing write: the NPC branch of the target-update path never assigns the level field, so the UI keeps rendering the last value written by a monster or player target. It also explains why the NPC value looks plausible - it is a real level, just belonging to someone else.

Taken together, the most likely shape of the defect is a single target-information update routine with per-entity-type branches, in which (a) the player-character branch reads the level from the wrong source and (b) the NPC branch omits the assignment entirely. The monster branch is the only correct one.

3.8 Suggested remediation

• Audit the target-information update path and enumerate every entity type it handles (monster, player character, NPC, summon/animus, siege unit). Confirm that each branch explicitly writes the level field.

• Zero-initialise the target-information structure on every target change, so a missing assignment degrades to 0/unknown instead of leaking the previous target's data.

• Verify the field offset and type used for player characters against the actual character structure. If the level is not transmitted for player targets, transmit it rather than deriving it from adjacent memory.

• Add a sanity clamp on display (valid level range for the build) and render a neutral placeholder (for example "Lv. -" or "Lv. ?") when the value is out of range, so a future regression is visible instead of plausible-looking.

• Add a regression test that targets monster -> player -> NPC -> monster in sequence and asserts that each displayed level matches the entity's true level.

3.9 Acceptance criteria

[ ] Targeting any player character shows that character's true level, and the value is identical across 20 consecutive re-targets and after a relog. [ ] Targeting any NPC shows that NPC's own level, never the previous target's level. [ ] Monster levels remain correct (no regression). [ ] The sequence monster -> player -> NPC -> monster -> player updates the displayed level on every single acquisition. [ ] No out-of-range or multi-digit implausible level can be displayed for any target type.

4. BUG-02 - ANTI-CHEAT PASSWORD CANNOT BE SET ON A PLAY ACCOUNT

------------------------------------------------------------------------

4.1 Summary

The anti-cheat password for a Play account cannot be configured. The setup flow completes without a usable result: the password is never persisted, is never requested afterwards, and the account therefore never has the protection enabled.

4.2 Severity and impact

Severity: High.

• A security control that appears configurable but silently does nothing is worse than an absent control, because the user believes the account is protected.
• Anyone who gains access to the Play account (shared machine, leaked credentials, credential stuffing) is not stopped by the second factor the feature is meant to provide.
• If the anti-cheat password is also used to authorise the anti-cheat or guard client, the failure may additionally weaken enforcement and complicate ban appeals.

4.3 Steps to reproduce

1. Log in to the GoMMO account/launcher portal with the Play account.
2. Open the account security page containing the anti-cheat password setting.
3. Enter a new anti-cheat password in the password field and the matching confirmation field.
4. Submit/save.
5. Observe the on-screen response.
6. Log out completely, close the client and launcher, reopen, and log in again.
7. Return to the same settings page and inspect the anti-cheat password state.
8. Launch the game and observe whether the anti-cheat password is ever requested.

Result: the operation produces no error and no confirmation that a value was stored; after a full relog the setting is still unset, and the game never asks for the anti-cheat password.

4.4 Expected vs. actual

Save a valid anti-cheat password Expected: success confirmation; value stored against the Play account Actual: no meaningful feedback

Reopen the settings page Expected: masked value / "configured" state Actual: still unconfigured

Relog and launch the game Expected: anti-cheat password requested Actual: never requested

Enter a wrong password at the prompt Expected: access denied Actual: no prompt exists to test

Enter an invalid/too-short password Expected: validation error Actual: no validation feedback observed

4.5 Test matrix

1. 8-character alphanumeric password - not persisted
2. 16+ characters, mixed case, digits, symbols - not persisted
3. Password identical to the login password - not persisted
4. Leading/trailing spaces - not persisted
5. Different browser / incognito window - not persisted
6. Different Play account - not persisted
7. After full logout and client restart - setting absent
8. After server/channel change - setting absent

Complete the results with what was actually observed, including the exact wording of any message. If every variation fails identically, state that explicitly: it is strong evidence that the write never reaches the backend rather than a password-policy problem.

4.6 Preliminary technical analysis (unconfirmed - for the development team)

The failure is silent and total, which narrows the likely causes.

1. Client-side only. The form validates and closes without issuing a request, or the request is issued to an endpoint that is a stub.

2. Swallowed server error. The save request reaches the backend but fails (unknown account scope, missing table/column, permission, feature flag) and the error is not surfaced to the user.

3. Wrong account scope. The value is written against the master/login account while the game verifies it against the Play account (or vice versa), so it is stored but never found.

4. Hash/format mismatch. The value is stored but the verification path hashes or truncates it differently, so the stored value can never validate.

5. Cache. The write succeeds but a cached account profile is served afterwards.

Discriminating between these requires the server-side log for the save request and a database read of the Play account row.

4.7 Suggested remediation

• Add explicit success and failure responses to the save endpoint and surface them in the UI; never close the form silently.
• Log the request server-side with account id, Play account id, timestamp, HTTP status and the resulting database write count.
• Verify the read/write account scope matches the scope used by the in-game anti-cheat check.
• Verify the hash algorithm and truncation are identical on the set and verify paths.
• Invalidate any cached account profile after a successful write.
• Confirm the feature flag is enabled for the tested realm.

4.8 Acceptance criteria

[ ] A valid anti-cheat password can be set and produces an explicit success message. [ ] After a full logout, client restart and relog, the settings page shows the password as configured. [ ] The game requests the anti-cheat password at the expected point and accepts the correct value. [ ] A wrong password is rejected with a clear message. [ ] An invalid password is rejected at save time with a specific validation message. [ ] Server logs show one successful write per save attempt, against the correct Play account.

5. IMPACT ASSESSMENT

------------------------------------------------------------------------

BUG-01 Player experience: every target acquisition shows wrong information. Fair play: wrong threat assessment causes avoidable deaths and losses. Support load: repeated reports of "target level bug". Trust: visible, permanent UI corruption. Exploit potential: possibly usable to disguise a target's strength.

BUG-02 Player experience: the security setting cannot be used at all. Fair play: account protection is absent while appearing available. Support load: repeated reports of "cannot set anti-cheat password", plus account recovery cases. Trust: perceived broken or insecure account system. Exploit potential: weakens accountability if the anti-cheat password is part of the enforcement chain.

6. EVIDENCE TO ATTACH

------------------------------------------------------------------------

Please attach the following. The report is much stronger with artefacts than with prose alone.

BUG-01

• Screenshot or short clip of a monster target with the correct level (control).
• Three or more screenshots of the same player character re-targeted, showing different level values.
• Screenshot of a monster/player target immediately followed by the NPC target showing the inherited level.
• Screenshots covering the three cases in section 3.6.

BUG-02

• Screenshot of the anti-cheat password form before and after saving.
• Screenshot of the settings page after a full relog.
• Screen recording of the complete attempt, including the absence of any confirmation.
• Browser network trace (F12 -> Network) of the save request and its response, if accessible.

Logs

• Client crash/error log for the session, if any.
• Server-side timestamp window so the developers can correlate.

7. QUESTIONS FOR THE DEVELOPMENT TEAM

------------------------------------------------------------------------

1. Is the level shown in the target window transmitted by the server per entity type, or derived client-side? This determines whether BUG-01 is a packet/field defect or a UI-cache defect.

2. Which entity types share the target-information update path? Do summons, animus, siege units and pets also show the defect?

3. Is the anti-cheat password stored per Play account or per master account, and which service verifies it at game start?

4. Is the anti-cheat password feature currently enabled on the production realm, or gated behind a flag that is off?

5. What is the expected user-visible behaviour when the anti-cheat password is not configured: is the player prompted, blocked, or silently allowed?

8. APPENDIX - REPRODUCTION LOG TEMPLATE

------------------------------------------------------------------------

BUG-01 entries

Entry 1 Date/time: Character: Target name: Target type (monster / player / NPC): True level: Displayed level: Notes:

Entry 2 Date/time: Character: Target name: Target type (monster / player / NPC): True level: Displayed level: Notes:

BUG-02 entries

Entry 1 Date/time: Account: Password variant: Save response: State after relog: In-game prompt (yes/no):

Entry 2 Date/time: Account: Password variant: Save response: State after relog: In-game prompt (yes/no):

End of report.