[Release] Point Blank v.3122/3123 BR server (source) *BATTLE(udpfixed)* + client Source

[EINNEJ]

edit 22-08-2026: added client v3.123 link, thanks @luxtown.
hi! in my 121 post i wrote this:

version 122 will also be public, but only when its much better than it is now

its much better. here it is.

same deal as always: full source, precompiled binaries, rebuild it yourself if you dont trust me (you shouldnt trust anyone, build your own binary).

it also runs against the 123 client, the wire is the same, just set ClientVersion in Data/ServerConfig.json. fair warning tho: 122 is the one we recommend, its where every fix in this drop got tested. 123 i barely touched. should work. expect surprises.
(this release is late, sorry!!! i had 3 very busy weeks, this release should come 3 weeks ago...)
the wall fell

the 121 post had a known issues list, and right at the top of the battle section, in caps-lock, was this:

[X] match start / loading <- big drift here

a server where you can buy a gun but cant shoot it is a shop simulator, not a game. so 122 is where that line dies. match start, loading, spawn, kill feed, death, respawn, round end, rewards, back to lobby.

what i actually tested: 2v2 with real players. bots from 121 still doing their thing in PvE. 8v8 untested, go find out and tell us.

how it got fixed (the fun part)

the 121 method: stare at bytes, guess, test, repeat. whack-a-mole. fix one field, the next one moves. i got tired of being wrong so i changed the question:

• before: "where do i think this field goes"
• now: "what does the 122 client actually read"

so the read order of every packet comes out of the client binary itself, and the server writer gets reconciled against it field by field, offset by offset. client is ground truth. server just has to agree.

slower per packet? yes. but done is done, and it cant silently regress, theres a drift gate over every mapped opcode that screams before a player ever sees it.

most of what was broken in this project was never missing code. it was the 3.68 base speaking a dialect the 122 client doesnt.

udp, and why it was the hard part

battle traffic is udp and none of it is documented anywhere, so all of this came out of the 122 binary:

• handshake. before any udp, the client opens the match channel with opcode 2417 carrying its client id, RSA-encrypted. server answers with the per-session udp key, client binds an ephemeral udp socket.
• in the client's connection state machine state 3 is IN_BATTLE, and that handler only knows udp. the datagrams ARE the battle.
• crypto. aes-256 with the per-session key + hmac-sha256 over a per-packet sequence number (integrity + anti-replay). same sequence feeds the next encrypt. bit 14 in the header marks ciphered vs plain, so the early handshake stays readable while actions dont.
• framing. fixed 14-byte sub-package header on every payload (client's state-3 handler, byte_1635665 in the 122 idb), then a type byte: CONNECT, GAME_INFO, or battle actions. inside, actions are sub-packets with their own opcode space. completely separate from the tcp one.
• the action cipher. movement/fire/positions get an extra layer: 18 ops (add/sub/xor/rotate) keyed by a base key, ported instruction by instruction from raw x86, not from decompiled pseudocode. get one rotation wrong and the desync is silent. nobody crashes, the models just slide through walls.
• relay. match service relays validated datagrams to the other slots. server holds every session key so it can decrypt, sanity-check and re-encrypt per destination. thats also how the rcon live room snapshot reads positions without touching any client.

the whole flow:

credits

'If I have seen further, it is by standing on the shoulders of giants'. this server is built upon:

• 'server-dev-v3-cmess' (saw it on gh), thanks DeleteUser2465, whoever you are.
• 'PointBlank 3.68 Server for Development (OSM-Monitor)' (i know the drama, i still dont care), thanks empireb, pavel, garry and the others.
• luxtown, without you none of this happens.
• imchui, your resources here on ragezone made my life easier.
• and more people i dont know (except julianoramos01 and ekofab, ekobuf, ebufko something like that i dont remember).

I will never sell anything. All I do will be public; any fool can know. the point is to understand

whats inside

• full C# source, now on .NET 8: Plugin.Core, Server.Auth, Server.Game, Server.Match, Server.Host, OSM-Monitor, CryptoLib (not used, we did the correct udp fix without need a patch), DEV-Team.sln
• precompiled build in binary/, runs as is (not scanning it on virustotal, you can, but building your own is better)
• linux support (WIP, expect some issues): net8 console host, docker-compose, wsl scripts. the WinForms monitor stays windows-only, on linux you run PRISMBLEED.Server. (this way we can deploy on a headless linux vps, without needing a windows machine with visual interface, that means boring expensive)
• database dump + migrations
• NO client this time. bring your own 122/123 BR client and point the .sif at localhost

what else moved since 121

• login grew up: no more fixed testbr accounts, the server looks your account up by the token (details below)
• quests and mission cards are a real slot-based system now, presets loaded, buy/active/delete per slot
• battle pass: seasons from db, premium buy, level up, claim
• clan war rewired to the 122 contract, mercenary stats (not 100%)
• the usable/consumable item zoo got a full audit: fake nick, fake rank, name color, nick border, muzzle color, crosshair color, ammo+, respawn coupons, quick change... they do what the description says now (or it should... i didnt test *all* but there one works)
• inventory expansion
• flash sale, shop ribbons, capsule reward indices
• rank up rewards + panel
• almost all config moved from xml files to postgres (use dbeaver if you need, navicat is ), with live reload (edit data, no restart)
• multi-process split with a supervisor, zero-downtime reloads
• and a stupid amount of packet drift fixed everywhere: auth, lobby, community, clan, event portal...

what works

• login into lobby, nick, gold, rank, nick color/border/card
• battle, the whole loop (see above; validated 2v2, 8v8 untested)
• shop: grid, gold, cash, periods/variants, flash sale
• quests, mission cards, battle pass
• item effects, inventory expansion, rank up rewards
• a lot of other things

known issues

• observer/spectator slots still partial
• random boxes open and grant (DB driven now, much saner than 121), capsule popup partial
• gift shop / repair / plus point / delete item: never tested
• competitive/ranking, redeem code, webshop, ticket: never tested
• no auto account creation: one insert in the db and youre in, read the login part

whatowrkswhatdoesntlistfulloralmostfullidk:

Spoiler

legend:

[V] works, validated live
[P] partial (works but incomplete/rough) (P complains bytedrift and opcode problems too!)
[D] byte drift (packet fields moved, wrong layout)
[X] broken
[?] dont know / never tested

auth + entry
[V] login (token lookup, see below)
[X] auto account creation (create the account in the db, its one insert) (its also easy 'fix', its not a bug)
[V] channel / server select screen
[V] character select / channel screen basic info
[?] real web launcher auth (the launcher is not in this drop)(but works)

lobby
[V] lobby enter (nick, gold, rank)
[V] MyInfo / record panel (season tabs included)
[V] lobby user list
[V] toolbar / top menu
[V] lobby chat

shop
[V] shop grid / display (DB push)
[V] buy with gold / cash, periods / variants
[V] flash sale (DB driven)
[V] in-session buy display refresh
[P] random box open + grant (now DB driven, much saner than 121)
[P] capsule popup
[?] gift shop / repair / plus point
[P] mission card shop

inventory + equip
[V] inventory list, equip weapon / character, persists on relog
[V] name card / nick color / fake nick / fake rank / nick border / muzzle / crosshair
[V] use item (coupon effects audited against the client)
[V] inventory expansion
[?] delete item

room
[V] create / join / list / slot change / team balance
[P] observer / spectator slots
[P] ready / start gating, kick vote (i forget to test xD), room invite

battle / match
[V] match start / loading
[V] spawn (real players)
[V] death / kill feed / frag sync
[V] respawn
[V] round end / endbattle / rewards
[V] back to lobby post-match
[V] PvP (validated 2v2; we believe more works, 8v8 untested)
[V] bots / PvE AI deathmatch
[V] UDP action relay (aes-256 + hmac-sha256 + sequence anti-replay; action cipher ported from the idb)

clan
[V] clan detail / medal info
[P] clan war (rewired to 122, mercenary stats; hard to guess how much is done but i did a lot from scratch since this feature has 0 things done in server)
[V] clan create / list / filter (i forget to fix the 'not found' message popup the first time you open the clan ui when u dont have a clan)

progression
[V] quests (slot based, presets loaded)
[V] mission cards
[V] battle pass (buy, level up, claim)
[P] season challenge
[?] competitive / ranking
[V] titles

social + misc
[V] friends / messenger
[V] rcon (plus new admin commands: balance teams, end battle, flash sale, kick, live room snapshot)
[V] event portal (configurable background/subtitle)
[?] redeem code / webshop / gift / ticket

about login:

Spoiler

the 122 BR client logs in through a web launcher with a token, not a normal user/password. that launcher is not in this drop.

what the server does now: real token lookup. every row in the accounts table has a token column. whatever base64 token you pass on the command line is the account you log into. no password check, no auto creation.

so: insert an account with a token set, launch with that token, done. (the old user/password path is still in the login file, commented, if you want to wire a real launcher)

launch.bat, same ritual as 121:

@echo off
cd /d "%~dp0"
start "" "PointBlank.exe" /token AAECAwQFBgcICQoLDA0OMg== /launcher PBLauncher

(replace the token with the one on the account row, obviously)

things that must match or the client gets kicked:

• ClientVersion in Data/ServerConfig.json = your client version
• password salt in Settings.ini = the one your db was hashed with
• client locale/region allowed
• AccessUFL stays false unless you know your file list matches

requirements

• windows, or linux via docker (WIP, expect some issues)
• .NET 8 SDK if you build it yourself
• PostgreSQL
• a 122/123 BR client (not included, sorry)
• Visual Studio 2022 only if you want to compile (build-debug.bat also works)

whats next

the tooling. what fixed battle wasnt luck, it was a pipeline, and i plan to release it once its standalone. how it works:

• contract extraction. the client's parse function for each opcode gets lifted out of the binary (the __Parse_*/vtable read sequence). so the spec of a packet is the read order the client executes, not what someone guessed in 2019.
• that becomes a schema, and a drift gate (pcdiff) replays the server's real emitted bytes through it and pins the first offset where the two disagree. you fix the field's owner, the gate tells you if you broke a sibling.
• unicorn harness. a CPU emulator runs the client's REAL read code against crafted packets. no game launch, no anti-cheat. feed bytes, watch which registers/offsets the parser touches, the layout falls out.
• thats how the mission/quest block got pinned, with golden vectors so a regression fails a test instead of a player (this is pretty cool, you definitely should take a look at it:
  To view the content, you need to sign in or register
  )
• headless testbot. a bot client does login -> lobby -> equip (and more) against the live server and reports which acks came back wrong. so a packet edit gets validated end to end without a human in a match.
• agent-driven. an agent drives all of it: extract -> reconcile -> fix the owner -> gate -> live retest. the "use an AI" joke at the bottom isnt a joke, mine closes packet contracts by itself.
• a pretty good web panel. with a ton of functions to make your (and mine) life easier xD.

how the cpu emulator works related to pbdev:

Spoiler

1. the sandbox. unpacked client dump, mapped section by section at its own ImageBase. plus a stack, a heap, and a scratch region for the crafted packets.
nothing in the client is patched, the bytes executing are the bytes the game shipped. the return address pushed before the call is never mapped on purpose: the run has to stop exactly there or it doesnt count.

2. the execution loop. five hooks on every instruction of the real client function. one counts instructions and fakes the callees, one records every read landing inside the packet buffer, one records the writes, one catches access to unmapped memory.
out comes a list of (offset, size) reads in execution order. that IS the wire layout.

3. verdict discipline. the part that keeps it honest. a run that stops in the wrong place, or faults, or was missing a piece of its fixture is not an answer. its "inconclusive" or "environment-incomplete", and it produces nothing.
only a clean run whose decode matches the crafted input becomes a schema, a golden test and a signed report (sha256 of the dump + of the function's own bytes, so the result expires when the binary changes).

4. the whole loop. day to day: symptom -> find the client's parser -> emulate it -> verdict -> schema -> reconcile the server field by field -> drift gate over every mapped opcode -> testbot -> live client.
and the last box is why its a loop and not a treadmill: every closed packet leaves behind the command that proved it, the evidence, and the explicit limit of what was proven. next bug in that area doesnt start from zero.

no date (but soon!!). it ships when its useful to someone who isnt me.
a random video showing move sync fix (kill/death was bugged, also respawn, kill list, kill cam,..., but doesnt matter because its fixed now xD)

Screenshots:

Spoiler

finally - download:
server source:

To view the content, you need to sign in or register

client v3123

To view the content, you need to sign in or register

(thanks luxtown)
database:

To view the content, you need to sign in or register

please add to git and host elsewhere so it keep alive if any link get down

appendix: the client-side surgery (multi-client, debugger, remote control)

everything above is the server. but to even TEST the server against the real 122 client i had to break the client open first.

out of the box it fights you on three fronts: it refuses to run twice, it refuses to be debugged, and it refuses to be driven by anything that isnt a human hand.

heres how each wall came down. all of it lives in the client binary, found via the idb. none of it is a server change.

the client is 32-bit (PointBlank.exe), VMProtect-wrapped, and the anti-cheat loader is xigncode3_loader.exe. keep that in mind, it shapes everything below.

1. running multiple clients on one machine

two things make this hard. the client refuses to start twice, and the code that refuses does not exist yet when the process is created: it is VMProtect-packed, so the branch is materialized during unpack.

the exe has no ASLR, so the VAs are stable across launches. you never patch the file, you patch the live process, and you patch each site the moment it appears. three sites:

• 0x432254, the single-instance branch: 75 6E -> 90 90. the jump that bails when a sibling is already running becomes two nops, so the second client keeps going.
• 0x11FAC52, the CEF cache path: 46 -> 32. one byte in the path string, which sends the second instance to its own CEF base directory (a junction, so ~0 disk). two clients sharing one cache is its own class of failure.
• 0x87AF5D, the FileList integrity initializer: B8 58 4C -> B0 01 C3 (mov al,1 / ret). with two instances racing on the same listed file it fails and you get the "arquivo de dados corrompido" dialog. forced to return 1.

two operational rules learned the hard way. each instance needs its own parent process: launching both from one powershell gave Initialization error 2. and stagger them, 60s in my launcher, so the second one isnt unpacking while the first is still initializing.

with that you get 2, 3, 4 clients side by side on one desktop, all pointed at the same server. thats the only reason the 2v2 PvP tests were possible without a rack of VMs.

2. making the client debuggable (x64dbg / x32dbg)

this is the one people ask about. attach normally and the client dies before you set a breakpoint. the useful part is WHY, because the popular answer (an anti-debug check kills you) is not what happens here.

during init, CB calls NtSetInformationThread(CurrentThread, 0x11), ThreadHideFromDebugger. a hidden thread stops delivering debug events to the debugger.

so your int3 is never reported to x32dbg. it surfaces inside the process as an unhandled STATUS_WX86_BREAKPOINT and the client takes itself down. nothing detected you, the exception just had nowhere to go.

so you get ahead of it instead of fighting it:

• launch suspended. CreateProcess with CREATE_SUSPENDED. zero game instructions have run and only ntdll is mapped, which is exactly the window you need.
• detour the syscall, selectively. patch the prologue of ntdll!NtSetInformationThread and ZwSetInformationThread with E9 rel32 into a code cave. the cave checks the info class: only 0x11 returns STATUS_SUCCESS and does nothing, every other class falls through to the real syscall.
• resume, then attach. CB's hide call now succeeds and changes nothing. the main thread stays visible, so debug events arrive normally.

the "selectively" is load-bearing. i first neutered thread hiding globally and CEF stopped bootstrapping, BC.log stalling right after "Required files check". Themida uses those same thread ops for its own work, so you cannot blanket-block the export, you filter one class.

once inside: HARDWARE breakpoints only, the 4 debug registers. validated, not assumed: HW BP at 0x519abe fired, x32dbg paused, i inspected, removed it, resumed, the client free-ran 68s+, reproduced 3 times, no CrashTrace, no crashdata.dmp, no WER.

and this is how the live PvP kill-credit bug got pinned. i set a hardware WRITE breakpoint on the per-slot kill counter, the field at +0x24 that SendDeath @0xA03F6C reads to decide whether to broadcast a kill.

in a bot match the breakpoint trapped, the counter went 0->1, the kill feed fired.

in a 2-human PvP match the same breakpoint on the same field NEVER fired for a human victim. the counter stayed 0, no kill feed, no respawn.

that one observation, the write happens for a bot and not for a human, is what proved the bug was a client-side state gate and not the server dropping a packet.

no amount of server logging shows you that. you had to watch the client's own memory refuse to change.

3. driving the client from memory (WIP, build your own)

still a work in progress, so read this as a recipe, not a shipped tool.

the goal: make a client perform lobby actions (enter a room, ready up, leave, navigate menus) without a mouse, so an agent can run multi-client scenarios end to end against the live server. im not releasing my driver, but here is how to build your own.

the naive approach is to post window messages or fake input. it fails: the client reads input through DirectInput with DISCL_FOREGROUND, so if the window isnt focused (and with 4 clients, 3 of them arent) the messages are swallowed.

so instead of simulating input, you drive the UI from inside the process. four pieces:

• read memory, dont write it. open the process with PROCESS_VM_READ and use ReadProcessMemory. no injection, no WriteProcessMemory, no debugger.
• that matters: the guard from section 2 watches for debuggers and code tampering, but a read-only observer doesnt trip it. you get to look without touching.
• walk the widget tree. the UI is a tree of widgets rooted at the UI manager global (g_pUIManager, 0x15D25B4 in the 122 build).
• each node keeps its child list pointer at +0x38, the child count at +0x3C, the screen rect at +0xDC, its hit-test flag at +0xE8, and a disabled marker at +0xFD.
• that last byte is the useful one: the client sets it on everything behind a modal, which is how you know a popup is up. walk the tree and you know which screen is showing and which buttons exist, read from the real text buffers.
• hit-test the way the client does. before invoking anything, replay the client's own hit-test (the i3UIManager walk at 0x527E50) over the live tree.
• it answers what a posted message cant: a click the UI discards looks exactly like one that worked, so you check first whether the point is reachable or swallowed by an overlay.
• invoke the handler directly. every button resolves to a handler function. instead of faking a click, write the arguments into the client's stack/registers and call the handler the same way a real click would.
• its the difference between "simulate a mouse" and "press the button from inside the process".

whats proven so far: reading the live tree, hit-testing against it, and invoking a lobby button's handler so the client actually joins / readies / leaves a room.

with an agent in the loop reading the tree, deciding the next action, firing the handler, and reading the tree again.

whats NOT done: in-battle aim and fire still read the DirectInput device created with DISCL_FOREGROUND, so the window-message route cant reach them, so i need to inject ''actions'' direct in memory (walk to XYZ, , shot, jump, etc... its not hard after you attach the debugger)

lobby automation works, battle automation too but still not 100%. when it does, the testbot stops being a separate headless client and starts driving REAL clients through REAL matches, which closes the loop on everything in the "whats next" section above.

one honest note: the offsets above (0x15D25B4, 0x527E50, +0x38/+0x3C/+0xDC/+0xE8/+0xFD) are for the 122 build.

they move between versions, so on a different client you re-derive them from your own idb: find the UI manager global, walk one widget, and the rest of the offsets fall out of the struct.

also, stopping selling this source.... lmao the code is bad how dare you sell something like that... also i have fun reading the 121 thread, a lot of drama but i miss some people that are the drama-queens of the pbdev scene, at least we have ekobaff with his 40 iq

 

[MentaL]

MMORPG Server Files

Download MMORPG server files, Android MMORPG server files, private server files, Linux MMORPG server files, source codes, tools and development resources. Explore RaGEZONE for MMORPG development.

forum.ragezone.com

you can host the files here since its under the 100mb limit.

 

[D3ATHLY]

Thank you so much dude, great job! Could you share compatible client of English BR version?

 

[Sicily94]

Thank you a lot bro, good job!

Thank you so much dude, great job! Could you share compatible client of English BR version?

hi bro if i have time i share it for you (and for others that need).

Hello, i want to share with you, the db but for users that use Navicat and PostgreSQL (version older). It's the same db without errors. Enjoy!

 

[mitos]

so what is compatible EN client to download, so we can use for this server?

 

[xiaolongdada666]

Thank you a lot bro, good job!


hi bro if i have time i share it for you (and for others that need).

Hello, i want to share with you, the db but for users that use Navicat and PostgreSQL (version older). It's the same db without errors. Enjoy!

bro, can i have your discord?

 

[ekoqafar]

[13:07:58] system [LOGIN] PARSE FAILED: [LOGIN] Cannot find locale marker in packet
[13:07:58] system [LOGIN] Cannot find locale marker in packet

 

[cauuthp]

NO SOURCE CLIENT BRO ?

 

[ekoqafar]

NO SOURCE CLIENT BRO ?

client :

To view the content, you need to sign in or register

 

[Jmandupree]

Please update download links to something more stable. so, we can download or just make the git and send us link?

 

[Yusqa]

 

[joaowars776]

thank you for this incredible content, i'll put this on my Point Blank Portable tutorial as a update for users that don't know too much, any news about this i'll post here too

 

[joaowars776]

I managed to get it working; I just had to change the emulator version to run it (Data/ServerConfig.json):

"ClientVersion": "122.0"
to
"ClientVersion": "123.0"

(Using the client provided in the post—which is version 3123; the post recommends client 3122, but I couldn't find that one, if someone have it and want to share, please send here).

Also, you need the specific .NET runtime to launch it:
windowsdesktop-runtime-8.0.30-win-x64.exe

Everything seems fine, but the bots (offline play) are attacking me with knives and moving super fast. I’d like to know if it's possible to switch them to standard shooting, like on other servers.

After all, my setup was intended for offline play—even if online works too—so that specific aspect is really important to me. If anyone has any ideas, I’d love to hear them.

That's the only problem i saw here; i can't equip characters too (the one that already comes, didn't try buying anothers, maybe its the 3123 version, i don't know)

anything i would love, thank you

 

[Felp96]

Login always fails with "Invalid username or password" — token field getting corrupted with garbage bytes


Hi, first of all thanks for the release, really impressive work on the battle packet reconciliation.


I've got the server running fine (all modules load, DB connected via Postgres, no errors on startup), and I created a test account manually following the DB README instructions:



INSERT INTO accounts (username, password, token) VALUES ('player1', 'player1', 'AAECAwQFBgcICQoLDA0OMg==');

I'm launching with the provided !START GAME 1.bat syntax (start "" "PointBlank.exe" /token <base64> /launcher PBLauncher), just swapping in my own token. Client is version 3122.


Every attempt fails with:



[LOGIN] Invalid username or password []

I decoded the token= value the server actually receives/logs on each attempt, and it's never the token I passed via /token. Instead I'm getting different garbage each time — sometimes it contains readable ASCII fragments like player1, and in one attempt I got a fragment that looks like part of a locale/country string (...DONESIA_...). It also always starts with the same leading byte (0x32), which matches the corrupted ver=50.102 I'm seeing in the login log line, even though my configured ClientVersion is 122.0.


This looks like a packet offset/read misalignment in PROTOCOL_BASE_LOGIN_REQ.Read() for the 3122 client specifically — not a DB/config issue on my end, since AccountManager.GetAccountDB(_token, ...) is failing before any config validation even runs.


Has anyone else hit this specific issue and found a fix? I noticed ekoqafar reported something similar ("Cannot find locale marker in packet") — could be related. Happy to share full decoded token dumps if useful for debugging.

 

[rabritino]

Thank you a lot bro, good job!


hi bro if i have time i share it for you (and for others that need).

Hello, i want to share with you, the db but for users that use Navicat and PostgreSQL (version older). It's the same db without errors. Enjoy!

Hello, I restored your database and found accounts like acc2, acc5, and acc6; what steps should I follow to log in?

username password
acc2 acc2
acc5 acc5
acc6 acc6

Hi, I've managed to get to the point where you select the channels, but then it freezes and I get disconnected.

 

[Sicily94]

Hello, I restored your database and found accounts like acc2, acc5, and acc6; what steps should I follow to log in?

username password
acc2 acc2
acc5 acc5
acc6 acc6

Hi, I've managed to get to the point where you select the channels, but then it freezes and I get disconnected.
View attachment 309979

Hi, maybe can be for player equipment or some else... can try to di this:

select only all tables player_* (player_equipments, player_missions, player_battlepass, ecc..) and try to do Empy and Truncate and retry to login after do that. See if change something or have same crash.

 

[tornadoo]

is there a client source code?

 

[tbs1108]

Please help; I've encountered a few issues:
1. Regarding titles: I selected all of them and successfully obtained them, but after logging out and logging back in, the list is empty. Ribbons and similar items show as 0 because they were already claimed initially.
2. An issue regarding Points and Cash on the client side: the data sometimes gets swapped when making purchases in the shop, though it reverts to normal when in the channel room. This occurs specifically when buying items.
3. Issue involving the use of any black beret in the game: the game will crash if the player logs out and logs back in.

Note: I Use Client V3.123 Sea

 

[Cuppim]

Mirror client?

 

[tbs1108]

Mirror client?

I user client in threads https://forum.ragezone.com/threads/point-blank-client-sea-v3-123.1271306/