RxBlackMarkets Player Exploit Review

  • reference

Result

The client snapshot does not prove a working money, item, or duplication exploit because every server handler is absent. It does prove one low-impact location-disclosure weakness and exposes three server-boundary candidates that must be tested against the live server implementation.

RXBM-01: Client-controlled purchase basket

Status: High-impact candidate; server validation required
Potential impact: Free items, arbitrary registered items, underpayment, malformed quantities, or excessive order creation

The NUI receives each configured item object, adds an amount property, calculates the total in the browser, and submits the entire client-controlled structure as:

purchase { name, basket }

Each basket entry still contains its client-visible item, price, label, and amount. The quantity input has min=1, but it has no maximum and no explicit integer validation. Manual input is retained as a string, while the purchase action sends the basket without rebuilding it from trusted configuration.

Attack path

  1. A hostile client modifies or directly invokes the NUI purchase request.
  2. The client supplies a changed item identifier, price, quantity, duplicate entry, or market name.
  3. If the server trusts any submitted commercial field, it debits the wrong amount or queues attacker-selected items.

Closest visible control: the UI prevents an empty basket and resets some non-positive values. These are client-side UX checks and are bypassable. The locale includes invalid_basket_data and not_allowed_purchase, which suggests unseen server validation may exist, but its behavior cannot be verified.

Required server behavior

  • Accept only a market identifier, canonical item key, and integer quantity.
  • Resolve the item and price from the server-owned market configuration.
  • Reject quantities outside a small positive limit and reject duplicate entries.
  • Ignore client labels, prices, totals, payment type, and pickup assignment.
  • Debit payment and create the order atomically.

Evidence: web/build/assets/index.0453fbcc.js, line 801; NUI POST helper at line 32.

RXBM-02: Pickup proximity and location trust

Status: Medium/high-impact candidate; server validation required
Potential impact: Remote pickup, claiming an order at the wrong contact, replayed pickup, or duplicate delivery

The visible 2.5 metre restriction belongs to the client target interaction. When selected, the client calls PickupItems(location) with a client-visible location value. A hostile client can invoke client functions without using the target prompt, so the target distance is not an authorization boundary.

The server must independently verify all of the following:

  • The source player owns a pending order.
  • The order is assigned to the requested pickup location.
  • The player's server-observed coordinates are near that location.
  • The order is consumed exactly once under a per-player lock or transaction.
  • Inventory delivery failure does not leave a replayable or partially claimed order.

The protected pickup implementation and server handler are unavailable, so remote or repeated claiming cannot be confirmed.

Evidence: client/opensource.lua, lines 44-70; pickup coordinates in config.lua, lines 11-18.

RXBM-03: Concurrent purchase race

Status: Medium-impact candidate; server validation required
Potential impact: Duplicate queued orders, cooldown bypass, double processing, or payment/order inconsistency

The NUI has no visible in-flight request lock and does not disable the Purchase button while awaiting a response. Multiple purchase requests can therefore overlap. The configured cooldown is only 1 second.

A safe server handler must acquire a per-player purchase lock before checking cooldown or funds, perform debit and order creation atomically, update the cooldown before releasing the lock, and use an idempotency mechanism if the transport can retry. The locale contains a cooldown response, but the absent server code prevents verification that the check is race-safe.

Evidence: purchase action in web/build/assets/index.0453fbcc.js, line 801; purchaseCooldown in config.lua, line 39.

RXBM-04: Hidden-market locations are public

Status: Confirmed low-impact gameplay bypass
Impact: A player can bypass the intended search for the roaming market

All three possible market coordinates, the contact model, both pickup coordinates, and the local target setup are shipped to every client. Disabling the tracker items does not make these values secret. A player inspecting the downloaded resource—or a modified client enumerating the spawned contact/target—can identify the candidate locations immediately.

This cannot be treated as a secret-enforcement mechanism on an untrusted client. If discovery is intended gameplay, use search areas, rotating clues, or server-controlled progression whose reward does not depend solely on hiding client-delivered coordinates.

Evidence: config.lua, lines 20-24 and 33-45; local target registration in client/opensource.lua, lines 13-42.

Inactive paths

  • Required-item access is disabled, so the client-side HasItem helper is not an active bypass in this configuration.
  • Job access is disabled, so the client-side IsJobAllowed helper is not an active bypass in this configuration.
  • Item-currency payment and random item selection are disabled.
  • The lowercase smoke-grenade and sticky-bomb identifiers are integration bugs, not player-benefiting exploits.

Defensive test plan

Run these only in an owned staging server while watching inventory, account, and order state:

  1. Submit altered item keys, prices, totals, market names, duplicate entries, fractional quantities, negative quantities, zero, and very large quantities. Every variation must be rejected or reconstructed from server configuration.
  2. Send simultaneous purchase requests for the same player. Exactly one request should enter the critical section during the cooldown window.
  3. Attempt pickup without an order, at the other pickup contact, while far away, and twice concurrently. Every attempt except one valid nearby claim must fail without changing inventory.
  4. Force inventory-full and disconnect conditions during payment and pickup to confirm atomic rollback and non-replayable order state.

Coverage limit

init.lua, client/utils.lua, client/functions.lua, and client/main.lua are escrow-protected. The manifest references four server scripts, but none are present in this client-delivered snapshot. Findings RXBM-01 through RXBM-03 therefore remain candidates until the live server handlers are reviewed or tested.