View source for Classic registration and security system

Galactic Empire 3.2e contains a board-specific registration system, a time-limited test-drive system, protected [[Btrieve]] database handling, and a second concealed system check. These mechanisms are separate from <code>PLAYKEY</code> and <code>SYSKEY</code>, which control user access and administrative privileges.

The released source contains two largely independent layers. The documented registration and test-drive system is implemented by <code>SECURE.C</code> and was introduced in release 3.0d so GE could be distributed generally. The concealed <code>c4angle()</code> account check has no visible connection to that system and may have an older origin.

== <code>SECURE.C</code> registration system ==
=== Security state ===
The shared <code>secure</code> structure records three states:

{| class="wikitable"
! <code>open_stat</code> !! Meaning
|-
| <code>1</code> || The configured registration number is valid for this BBS
|-
| <code>-1</code> || The registration number is invalid or absent, but the test drive remains active
|-
| <code>0</code> || Security validation failed or the test drive has expired; GE is disabled
|}

<code>days_run</code> holds the test-drive startup-day count and <code>days_tot</code> holds its permitted length. At startup, classic reports the registration number, the current test-drive day, or that the unregistered game is disabled.

When disabled, GE does not schedule ship, NPC, planet, or automatic-update callbacks. Login, cleanup, deletion, hangup, and ordinary command entry also contain guards against operating on the protected databases. A player who enters the module receives the trial-expired notice instead of the game. The records are not erased: entering a valid registration number allows the game to continue where it stopped.

=== Original registration number ===
Classic's <code>REGNO</code> configuration option accepts an eight-character registration number tied to the host BBS registration number. The internal registration utility identifies Galactic Empire as using seed <code>10094056</code> and method 1. These are also the values actually selected by <code>GEMAIN.H</code>.

The standalone <code>SECURE.H</code> contains generic example values (including a different seed and method 0). They are not Galactic Empire's effective values: <code>sec_opnbtv()</code> receives GE's values as arguments from <code>GEMAIN.C</code>.

==== Generation algorithm ====
The publisher's <code>REGISTER</code> utility asks for the product seed, method, and customer's eight-digit MajorBBS or Worldgroup registration number. For GE it generates the key as follows:

# Convert the seed and BBS registration number to integers.
# XOR the two integer values.
# Represent the result as an eight-position, right-aligned decimal value.
# For method 1, add the corresponding seed digit to each position and retain only the last decimal digit.

In compact form, the final operation for each position is:

<syntaxhighlight lang="text">
registration_digit[i] = (xor_digit[i] + seed_digit[i]) % 10
</syntaxhighlight>

The runtime <code>protect()</code> routine independently derives the same value from MajorBBS's <code>bturno</code> and compares it with <code>REGNO</code>. Consequently, a key generated for one registered BBS does not register another.

<code>REGISTER.EXE</code> was the utility specified for Galactic Empire and [[The Legend of Elyth Gor]]. The accompanying <code>REG2</code> and <code>REG3</code> algorithms were intended for other M.B. Murdock products and are not used by GE.

=== Protected databases ===
The ship and mail databases are opened normally. The planet and user databases are opened through <code>sec_opnbtv()</code>.

The routine derives the correct board-specific registration value even while the game is running as an unregistered test drive. It supplies that value to the Btrieve open path and invokes Btrieve operation 29 (Set Owner), binding the protected files to the board-specific value.

Each protected database also receives a concealed record whose first key is a high-valued byte string defined by <code>KEY</code>. The remaining bytes hold four encoded fields:

* the first test-drive date;
* the last date on which the module was started;
* the number of distinct startup dates; and
* a second copy of the first date tied to the BBS registration number.

The stored bytes are additionally offset by their positions in the record. This is obfuscation and tamper detection, not encryption in the modern sense. On each new calendar date, the run counter and last-run date are updated.

For the original GE seed, characters 1 and 7 are combined to produce a 15-day test-drive limit. The test drive is rejected if its initial date is in the future, elapsed calendar time exceeds the limit, the startup-day count exceeds the limit, or the redundant board-bound date does not agree. This means both clock rollback and simply avoiding daily use are accounted for: elapsed calendar time is checked independently of the number of days on which GE started.

Because the security information is stored as an otherwise valid database record, code that walks the user database must recognize and skip the <code>KEY</code> record. Classic's midnight cleanup does this explicitly. A port or database tool that treats every record as a player can expose the security record in a roster or, worse, rewrite it as player data.

==== Startup cross-check ====
<code>GEMAIN.C</code> first opens the planet database and saves its resulting security state. It then opens the user database and requires both databases to agree on <code>open_stat</code> and <code>days_tot</code>. A disagreement causes a fatal <code>Secure Stat Open failure</code> or <code>Secure Days Open failure</code>. This prevents the game from quietly combining protected files with incompatible security state.

=== <code>FAKESECURE</code> ===
<code>GEMAIN.C</code> contains a commented build-time <code>FAKESECURE</code> switch. When enabled, the planet and user files use ordinary <code>opnbtv()</code>, and a dummy <code>secure</code> structure reports a registered state. It bypasses the protected open, trial counter, and cross-database registration checks.

The switch is disabled in the released source. It is also not a complete removal of all security-related code: the separate <code>c4angle()</code> check remains compiled and callable.

== Common online 3.2e build ==
A 3.2e package commonly distributed with MBBSEmu differs from the released source configuration. Its <code>REGIST.TXT</code> instructs the sysop to "Use your activation code for MBBS" rather than obtain the derived GE registration number.

Running the DLL with the default <code>REGNO</code> produces GE's trial-expired message. It also creates and evaluates the concealed records in both protected databases. It therefore is '''not''' a <code>FAKESECURE</code> build.

Decoding a newly created security record shows that its date is stored without the XOR transformation that the original <code>10094056</code> seed would produce. The DLL contains no <code>10094056</code> string and instead has a second <code>00000000</code> string consistent with a replaced seed. Its effective security seed is <code>00000000</code>.

That change has two consequences:

* XOR with zero leaves <code>bturno</code> unchanged, and method-1 digit addition with zero changes no digits. The valid <code>REGNO</code> is therefore the BBS's own eight-digit registration number.
* The test-drive length is derived from positions 1 and 7 of the seed. A zero seed produces a zero-day allowance, so an incorrect or absent <code>REGNO</code> is disabled immediately.

This exactly matches the package's instructions and observed behavior. The change could have been made by rebuilding after changing the source constant, or by replacing the eight ASCII bytes <code>10094056</code> with <code>00000000</code> directly in the DLL. The resulting binary alone cannot distinguish between those methods.

== The concealed <code>c4angle()</code> check ==
<code>GELIB.C</code> describes <code>c4angle()</code> only as "Verify system." Its name does not describe its operation. On its first call, it constructs the otherwise unobvious account key <code>Glperr</code>, selects MajorBBS's account database, and searches key 0. If that account record exists, GE terminates with <code>GE SYSTEM FAULT</code>. If it does not exist, a static flag prevents the test from running again during that module load.

The released GE source contains no routine that creates the <code>Glperr</code> account, so the intended path by which that marker would be placed cannot be established from GE's source alone.

Rather than calling this check visibly during initialization, classic places it inside <code>absol()</code>, GE's floating-point absolute-value helper. Normal navigation and combat mathematics eventually call <code>absol()</code>, which makes the security test occur indirectly. The function also changes the current Btrieve context to the account database and does not restore the prior context; ports should understand that as an implementation side effect, not as part of absolute-value behavior.

=== Possible earlier origin ===
Before version 3, GE was distributed for MajorBBS 5.x as source that became part of the compiled BBS rather than as a drop-in module DLL. The release notes specifically identify the <code>SECURE.C</code>-style registration protection as a new 3.0d feature. By contrast, <code>c4angle()</code> is independent of that system, survives the <code>FAKESECURE</code> bypass, and checks for a marker that no surviving 3.2e routine creates.

These facts make it plausible that <code>c4angle()</code> is a remnant of an earlier source-distribution-era protection scheme, perhaps paired with an old installer, build procedure, or security component that created <code>Glperr</code>. No pre-3.x implementation or marker-creation utility is present in the available archive, however, so this remains a historical hypothesis rather than an established fact.

== Source integration ==
The classic implementation is distributed across several locations:

{| class="wikitable"
! Location !! Role
|-
| <code>SECURE.C</code> || Protected Btrieve open, owner setup, registration comparison, trial record, counters, and tamper checks
|-
| <code>SECURE.H</code> || Generic declarations and sample defaults; not the authoritative GE constants
|-
| <code>GEMAIN.H</code> || GE's actual method, seed, high-key value, structure declaration, and prototype
|-
| <code>GEMAIN.C</code> || Protected database opens, cross-checks, scheduler and entry guards, status messages, and <code>FAKESECURE</code>
|-
| <code>GELIB.C</code> || Concealed <code>c4angle()</code> account check through <code>absol()</code>
|-
| <code>GECMDS.C</code> || Implementation of the diagnostic <code>RG#</code> display
|-
| <code>MBMGEMP.LNK</code> || Links the separately compiled security object into the module
|-
| <code>register/REGISTER.CPP</code> || Publisher-side method-1 registration-number generator
|}

The installation manual documents <code>RG#</code> as a technical-support command that reports the configured registration number, security state, and test-drive day. Its command-table entry is commented out in 3.2e, although the handler remains in the source; see [[Commands#Administration and diagnostics]]. The classic [[Who command|<code>WHO</code>]] terminal-support command likewise exposes the BBS registration number in PHARLAP/MajorBBS 6.x builds.

== ge-next ==
ge-next does not enforce classic's commercial registration or test-drive system and does not place security records in its databases. Its <code>REGNO</code> setting is only an optional installation identifier, not an unlock key. Since version 0.3.2, a blank or zero value produces no registration line at startup; a configured value is shown there and can distinguish multiple installations. <code>REGNO</code> is not player authentication or a frontend pairing code: the separate <code>FRONTEND</code> option controls [[Data command|DATA]] access.

{{GE navigation}}
[[Category:Sysop documentation]]
[[Category:Development]]