• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

security override

c_osborne

SOC-11
I'm curious as to how starship security would work in the minds of other players/gms. Let's say the PCs want to hack into another starship's computer. Can that be done from a distance, using some kind of wireless connection? Or would it require them to physically tap in to a direct line?

Now assuming they actually bypass security (extremely difficult, but an expert might be able to do it given enough time), what can they then do? Can they lock or unlock hatches? Can they open/close airlocks? Can they vent the entire ship? If so, what safety measures would be in place? Can they activate other systems (weapons, drives, etc.)?

And finally, how would you envision detection working? Would someone on the bridge almost automatically notice as soon as things started acting strange? Or if the hacker was able to bypass security, does that mean they are pretty much un-noticed until they set off something obvious?

I'm getting mixed signals from different rulesets and eras, and I'm trying to put together a logical system. Any advice would be greatly appreciated.

Chad
 
The short answer is "It Depends".

The longer answer is more involved.

First, if the target ship has all of it's functions handled by a single central controller, then it would be fairly easy to hack. Just set up a high-speed two-way radio link, tumble the passwords, and log in as "ROOT" or "ADMIN" or "GOD" or whatever the other system recognizes as it's highest level of command (the Captain, owner, or on-board compugeek). Sometimes, if all you want to do is shut down the drives, then you would only have to log in as the "CHENG" or whatever they call their Chief Engineer. Then if you want ot disable the Anti-Hijack protocols, log out and back in again as the Chief of Security.

Chances are that on a smaller ship these duties are carried out by only one person who does not want to mess with multiple usernames and passwords.

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Username: BOB
Password: BOB

Welcome aboard BOB.
You now have ROOT access.
Please choose a system:

A - Administration.
E - Engineering.
F - Fire Control.
N - Navigation.
S - Security.

E

You have chosen Engineering.
Please choose a function:

G - Gravity Control.
J - Jump Drive.
L - Life Support.
M - Manuever Drive.
P - Power Plant.

P

Power plant is running at 80% capacity.
Please choose an activity:

C - Connect Load(s).
D - Disconnect Load(s).
I - Increase Output Potential.
R - Reduce Output Potential.
S - Scram Power Plant.

S

You have chosen Emergency Power Plant Shut Down.
Once shut down, the power plant will require a 90- minute restart sequence.

Do you wish to continue?

Y

Are you sure?

Y

Positive?

Y

Power plant will shut down in 15 seconds.

14 ... 13 ... 12 ...</pre>[/QUOTE]This was an actual sequence of events that occurred when my players stole a yacht. They swapped out the storage core with their own software, which did not include any security programs.

Their programmer was named Bob. He had Computer-2 and INT-8 only.

The 'hacker' was an AI running at a high data rate. Imagine a text display running by at 14400 baud. This gives you an idea of how little time they had to react.

Hack Attempt:

Roll 2D for 8+

DMs:
Hacker's Computer skill level.
Hacker's computer model minus the target computer model.
+1 if hacker's computer is a 'bis' type.
-1 if target's computer is a 'bis' type.

You might add a defense point or two if the target computer is running it's own security programs, but those would depend on the program descriptions.

Some ships have one main computer for all the standard programs listed in the LBB's, and have dedicated 'dumb' controllers running those shipboard functions that do not require any 'LBB' software. For instance 'Gravity Control' and 'Life Support' may be simple feedback loops running through op-amps and user controls. Of course, if you cut power to everything, then these systems will fail too (emergency batteries notwithstanding...).
 
My circumstances are a little different. The PCs are trying to enter a secured ship, in space. They have reason to believe that there are threats inside, and they were considering venting the ship to kill any occupants. I won't go into all the particulars, but the ship in question is a 2500 ton J4 capable modular freighter with three 1000 dton cargo modules.

Here's what I was thinking. The first successful hacking roll gets them in, and would probably be enough to work around anti-hijack software (e.g. to open a hatch). Failed attempts would be logged, and could alert anyone using the system that there was an attempt.

However, to actually open both sides of an the airlock at the same time (venting) requires a safety override. This requires a separate password (or another computer skill check). If that succeeds, that single airlock will open, venting the connected areas (a local alarm will sound while it remains open, and there is no way to stop that). If it fails (or wrong password is entered several times), a security alert would be sounded.

Does that seem logical?

Chad
 
Also add a modifier based on TL. If TL of PC computers (pun intended) is higher than the Starship's they would have an edge and vice versa if not. Also, breaking in from space ought to made slighter easier by virtue they could access sensitive avionics...
 
My computer/hacking rules (they use the UGM Task System, see my sig for details):

First of all, assume that most computers encountered in Traveller are similar in performance to the shipboard models, but, as their price and weight do not include a ship's sensor suits (which are most of the so-called "ship computer), they weight/displace and cost 5% of the ship computer's size and cost, but have the same computer performance. A Hand Copmputer is equivalent to a Model/1 in performance; Computer Fire Control Systems (LBB4 p.42) are equivalent to the most advanced computer at their TL; A battlefield Computer is equivalent to one model below its TL most advanced computer. A robot's brain is equivalent to a computer model of half it's Apparent Intelligence, rounded up (so a robot with an Apparent Intelligence of 10 will be the equivalent of a Model/5 computer; however, (semi-)intelligent robots (that is, robots having, for the very least, High Autonomous Fundamental Logic, Full Command and atleast 20% Synaptic CPUs) use their FULL Apparent Intelligence as their "model" (maximum 9).

Field-repairing a ship computer requires one Computer/EDU/-2 task throw per level (i.e. when the computer was hit).

A hacker needs either to have a computer of his own (if he's remotely accessing a computer) or directly use the hacked computer.

Hacking a computer requires, first of all, establishing a communication link with it. Anyone using a terminal hooked into a computer or directly interfacing with the computer is "in communication" with it; coming into communication with a computer hooked to a planetary network requires a Computer/INT/+4 task.

Contacting a ship's computer from outside the ship is somewhat more difficult, as most ships have basic ECM systems to prevent outside interferance; it is a Communications/INT/-2 task; the same goes for trying to establish an unauthorised communication link with a robot with basic ECM. Establishing a link with a robot protected by Extensive ECM is a Communications/INT/-6 task.

Establishing a link with a ship's computer from any location but the bridge or engineering is a Computer/INT/0 task if no Anti-Hijack program is running or a Computer/INT/-4 task if it is running. Assume that all HG models above 2bis always have an Anti-Hijack program running.

Once communications have been established, the hacker needs to penetrate the computer's Firewall. A Firewall is rated as a UGM task difficulty DM, from +2 to -10, which is the difficulty to gain Admin-level access to this computer without authorization. The system's baseline Firewall (I'll think about upgrade costs later on) is given on the following table:

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Model Firewall
1 +2
2 +2
3 +0
4 +0
5 -2
6 -4
7 -4
8 -6
9 -6</pre>[/QUOTE]For example, hacking through the firewall of a Model/3 computer is a Computer/INT/0 task. A Spectacular Failure activates an intrusion alert (see below); a Spectacular Success creates a Backdoor, which will mean that the hacker will be able to loging to the computer again without hacking through the firewall. The backdoor will be detected and blocked after 1d6x10 days on a civilian computer or 1d6 days on a military or other secured computer.

Intrusion Alerts: If an intrusion alert is triggered, the hacker will be automatically dumped off-system. In addition, the system will try to pinpoint the hacker's location; he'll have to succeeed in a Computer/INT/-2 task to evade the trace.

Once inside, the hacker could do as he pleases; however, all computer of Model/3 or better have ICE (Intrusion Countermeasures) equal to their Model number. If ANY task throw done inside the hacked computer (data search, manipulation etc) has a "natural roll" of less than equal to the ICE number, an intrusion alert is triggered.

Finding a datafile in a computer is a Computer/INT/+2 task if the file isn't hidden or a Computer/INT/-2 task if care has been taken to hide the file.

Disabling or manipulating a specifit device linked to the computer (such as a security camera or an iris valve) is a Computer/INT/+2 task.

Ofcourse, a hacker could avoid all of the above mess by getting the user name and password of a legitimate user (called "social engineering" by RL hackers). To obtain this information from their owner is typically either a Carousing/SOC/-2 task or an Interrogation/INT/-2 task. Getting such information from underworld sources (if it is available from these sources at all) is a Streetwise/INT/-4 task.
 
Simple Vilani style airlock design.

The venting safety is a mechanical switch. When engaged the following occurs.

Pressurized airlock/depressurized exterior. The mechanical switch automatically locks the exterior door’s mechanism.

Depressurized airlock/depressurized exterior.
A similar mechanical switch prevents the interior door from opening.

The device can be disengaged by physically opening the access panel, and removing a small linkage. Total operation time about 1.5 min per door. Of course you need to deactivate the alarms first.
Heheheh…

Perhaps some functions are controlled by an electro-mechanical switch?

Does the ship have a robot brain monitoring access and requests to the main computer?

Make them cut through every bulkhead. Set booby traps that burn out hacking gear. Send little security robots after them. Spacecraft are not easy to steal.

Seal up an area and pressurize it to 10 atmospheres, then drop it back down to 1 quickly.
Even in a vacc suit they may still get the bends.
 
My players were trying to take over a Destroyer. They'd got aboard and were desperately trying to get control of the computer before the Marines arrived. Their hacker made his roll...

Hacker: Yes! Computer, ignore all further commands.

Computer: Okay.

Hacker: ...er, except mine, obviously. Hello? Computer? Oh, bugger..
 
KG, you're not nice.
file_23.gif

Andrew, that is wonderful! Did they reboot in time?

Chad, airlocks would involve mostly manual/electric lockouts (I agree with KG, here). All airlocks IMTU involve individual locks on each hatch, as well - you have to open one, get in, then open the other from inside the lock. I also wouldn't have ANY computer access from outside the ship. Why would you ever need it? And, there's no reason for a computer to be talking remotely with other ships. Maybe a library feed, and the transponder (which is not normally hooked to the computer).

As far as venting a ship, if this thing is 2500dT its going to have automatic pressure hatches throughout the ship. You drop the pressure in the section with the hatch, and all the adjacent pressure doors will seal immediately.

The only proper way to vent a ship is to hole it with a large enough weapon to gut several decks at once.
 
Pulse lasers make excellent venting tools.
Anyway. Messing with the AG depends how it works in YTU.
IMTU (CT) artificial gravity is real fickle. It is more likely to go out than go up. Inertial damping is done by some black box in the M-Drives.

Personally I like over pressurization followed by a rapid decompression (not explosive).

How about a solvent that eats through typical vaccsuit material? Then start decompressing the section. Switch off inertial damping and just make a sharp turn.
 
The best approach may be to attack the computer with a higher TL machine. I am thinking that a TL-15 computer will give that TL-12 a run for it’s money.
Hmmm so is a TL-12 Mod 6 better than a TL15 Mod 2?
 
IMTU starship computer systems are slightly different from most other computer systems. First, as described in SOM (DGP) there is not one big computer running everything but a network of smaller computers, one for each subsystem. Second, the O/S and standard operating programs are hardwired (the Book 2 software comes as ROM cartridges the size of an 8-track cassette and work like the old Atari game cartidges). Volitile memory is for logs, library data, entertainment files, and command sequences (a command sequence is basically a limited ability macro). With two exceptions (mentioned below) data can only pass from a sub-computer to the central computer, not the other way around.

For security most shipboard operations have to be autheticated at the point of action (its part of the hardware design). For example: an airlock cannot be operated remotely, someone has to be physically present. Authetication is via keycode produced by a strong encryption algorithm and stored on the user's ident chip (chip is in dog tags and includes user's retina scan and DNA profile, a checksum of this identity is then used in the generation of the keycode). For key operations the ident chip must be verified against a scan of the user and against a security file stored in the security computer (adjacent to the central computer). Changes to the central security file and accesses of it are stored on a WORM drive, providing an audit trail. To amend the central security file requires direct physical access.

Apart from security validation the only other data flow (called a "stream") from the central computer to a sub-computer is j-drive course settings. There is, however, a data stream from the sensor system to the nav computer, and from the nav computer to the m-drive. But in all cases network data streams are standard format data only (command sequences cannot be transferred) flowing on predefined routes ("channels").

Of course no system is foolproof. The purpose is to eliminate the risk of computer viruses and to make it difficult to quietly hijack a ship through its computer system. To summarise: the computer architecture is designed around principles of compartmentalisation (both physically and regarding data and instructions). If PCs manage to compromise one computer subsystem it shouldn't give them any advantage over the rest of the ship.


Recently in my campaign the PCs are recovering a derilict (actually they were its frozen watch) and even with full physical access to the ship it still took significant time and direct access to the security computer to create captian level security permissions and download them into the lead PC's ident chip. (Admittedly a lot of time was wasted because even with two of them working on it they still blew their task rolls ... twice.)

(Note to self: must update campign log.)


Regards PLST
 
Originally posted by Andrew Boulton:

No, they resorted to good old Plan B: blow everything up... [/QB]
IIRC After I messed up the computer hacking, I did get back into the computer but the delay caused us some serious problems, as I was meant to be on point for the assault and we took a hit from another ship before we could get the jump engines working.
Blowing everthing up was our plan A most of the time but we had to capture this ship as the planet was a little hot for us after nuking their research facility.
 
Originally posted by Chad Osborne:
I'm curious as to how starship security would work in the minds of other players/gms. Let's say the PCs want to hack into another starship's computer. Can that be done from a distance, using some kind of wireless connection? Or would it require them to physically tap in to a direct line?

In our T20/Tne campaign my co_Gm Mr Adkins & I, as well as several prominent players worked out that the Task of Hacking was controlled by the three feats:

* Hacker
--or the one engaged in “Hacking” as we have seen in countless movies, allows the user of such (or level of expertise), to “bypass, circumvent, or defeat computer or communication security systems”, and access data information they are seeking to gain, view, or retrieve from another restricted computer, communication, or data system. “As a feat this adds +2 to all T/Computer and T/Communications skill checks.”

* Gearhead
--(As a feat), is a person who is quite skilled at tinkering and working with mechanical and electronic equipment and systems such that they gain a “+2 to all T/Mechanical and T/Electronics skill checks when attempting to repair, construct or sabotage a piece of equipment." This would appropriately apply to attempts to hardwire non-standard connections to a system or communications link.

* EW Specialist
--(As a feat), is a person who has an amazing level of electronic warfare expertise such that they gain a “+2 to all T/Communications and T/Sensors skill checks when attempting to detect, defeat, or establish a communications, or sensor lock; or when trying to descramble a garbled or encrypted encoded comm. signal.”

Skills in Review:
* T/Computer
, is used when hacking over from computer-to-computer data systems.

* T/Communications
, is used when hacking via wireless comms or personal communicator device into a data system.

* T/Electronics
, is used when hacking via a hardwire connection, i.e. “splicing” into the data system itself from outside directly into it.

Hacking thus is boiled down to a 3-step process:

1. Connection
The Connection phase refers to the process of establishing a link to another system by which data, commands or information will be exchanged. Whether sitting down to a directly wired terminal, using a modem or other device to carry data over common communication systems or plugging the cable from your personal computer into a data jack; or at the other end of the spectrum, it might also includes the extremes of scraping away the covering from a cable and clipping in your own bootleg connection, or removing panel covers from a computer and plugging in your own wires directly into the heart of the system itself.

It is the act of making contact, what happens to allow that exchange of information to happen, and under normal circumstances, those who live and work with computers perform this action daily. Most computer systems are actually designed to make access easier, and will often apply the DM as a bonus toward making this step easier for the potential user. For those attempting to connect to a system in ways not originally intended, or for which the system is attempting to guard against, the DM will almost always be applied as a penalty to the attempt.

For Example: A TL-9 (+5) public access information terminal in an arcology is intended to assist the residents and visitors in obtaining information, it's modifier is (thankfully) set to help those attempting to connect to it, in this case with a basic voice help system. John Random, from the planet Dustball in the Backwater System who wishes to access the terminal steps up and listens to the instructions, which provides use instructions on how to use it's touch-screen maps. John then attempts to access the device (Easy task, T/Comp DC-10) and receives a +5DM, giving him a high probability of success. Not satisfied with this, several local shopkeepers pool their funds and pay for the installation of a model, which has voice recognition, and can respond to questions from passers by, as well as provide touch-screen maps of the local shops and restaurants. TL-12 (+10)

Applicable Skills :
The skill used to handle this is dependent on the situation and method of connection. A player sitting down directly at a terminal or connecting across a data link or computer network would likely use T/Computer. Establishing a connection by way of a modem, radio or other Communications link (Perscomm, Meson Communicator, what have you,) would likely be making use of the T/Communications skill. A player attempting to wire in their own connection (including almost anything involving 'splicing in', or accessing a computer's internal parts would likely be using T/Electronics.

Success or Failure :
Success at this task results in an established, stable link to the target system, and permits the exchange of data. Failure to connect by conventional means typically means an error or shortcoming in the connection method. Failure to connect to a hostile system may result in the target's connection device or channel being blocked, fire walled or taken offline.

System TL Mod
TL5 - TL6 0
TL7 - TL8 +2
TL9 - TL10 +5
TL11 - TL12 +10
TL13 - TL14 +15
TL15 - TL16 +20
TL17+ +25


2. Access
The Access phase is where authentication takes place, such as entering usernames and passwords or electronic systems exchanging cryptographic keys or data to verify the identity of the system on the other end. If the Access phase is walking into the lobby of the bank, this is the point where you enter the combination to the Vault (or crack the combination!).

Many systems permit unrestricted access and thereby may not require authentication (as in our example above) or may apply up to their TL-based DM as a bonus to a legitimate attempt, using such technology as voice recognition, face recognition, thumbprint readers, DNA scanners, et-al to make skill checks unnecessary when accessing the system by way of it's intended means. These degrees of sophistication also make it more difficult for those who would attempt to bypass or fool those authentication methods or devices, causing those DMs to be applied as penalties in those cases.

Example: Our intrepid J. Random has decided to attempt to access the office computer inside of the local Rent-A-Raft office. He has been watching the office for two days, and has identified that the Assistant Manager of the office, Delores Cluck, always eats lunch at the Food Extruders kiosk across the street, and always sits at the same table. He positions himself ahead of time, and when she sits down, he swipes the ID badge from the pocket of her coat and takes a quick walk around the block before going to be back door of the office. There, he Connects to the security system (in this case by walking up to it Simple Task DC-0), and holds out the card. Accessing the system (Very Easy Task DC-5) assisted by the TL-11 card reader (DM +10) means that the door simply unlatches and allows him into the back office. Inside the office, our man is presented with a TL-8 desktop computer, a keyboard, and a prompt that says Login:

Presented with this, the cycle begins again, sitting down at the keyboard and screen (Simple Task DC-0, TL-8 DM+2) a skill check is unnecessary to connect to this system. Accessing the system is a different matter, and our would-be Hacker (T/Computer 6, Hacker feat for +2) tries a series of usernames and passwords based on permutations of Delores' names and other obvious data from her ID badge, such as her age, date of birth, employee number, etc). NOT knowing the correct data to access the system, the TL modifier is applied as a penalty. This is a Break System Security task rated by the GM as (Average DC15) and requiring 5 minutes. A D20 roll of 3, +6 (T/Comp) +2 (Hacker) -2 (TL DM) results in 9, 6 shy of success. 5 minutes are spent attempting to access the system, resulting in a failed access attempt and a terminal now in security lockout from too many failed log-on attempts.


Applicable Skills :
The skill used to handle this is T/Computer. If our man had spent some more time prior to the attempt using skills like Gather Information he might have had a better chance of guessing the password, or perhaps a call to the office phone and the judicious use of Bluff might have convinced an unwitting employee to provide their user ID and password over the phone.

Success or Failure :
Success at this task results some degree of Access to the system (or perhaps just part of it), it's functions and it's data. Failure typically results (sooner or later) in that connection being locked out or taken offline, and the system's firewall or administrator being notified of the attempt. Failure to connect to a hostile system may result in the target's connection device or channel being blocked, firewalled or taken offline.


System TL Mod
TL5 - TL6 0
TL7 - TL8 +2
TL9 - TL10 +5
TL11 - TL12 +10
TL13 - TL14 +15
TL15 - TL16 +20
TL17+ +25

Margin of Success / Access Result / Effect / Detection
Failure by 6 or more / Access Denied / Access Locked Out / Alarm Activated
Failure by 1-5 / Access Denied / Disconnected / Access Logged
Success DC to DC+9 / Basic Access / Basic Privileges / Access Logged
Great Success DC +10 / Full Access / Unrestricted Privileges / Access Logged
Extraordinary success DC+20 / Full access / Unrestricted Privileges / Access Undetected

A result of 'Alarm Activated' results in immediate notification of the system operators, activation of additional security measures (if any available) and usually investigation (or retaliation/flight/disconnection/escape in the case of Sophont/AI/Viral targets).
A result of 'Access Logged' results in the access attempt (or success) being noted in the system's on-line access records. The time until that access is discovered may vary with the circumstances. Such records might be erased or altered as a separate task once access is established.

3. Execution
The Execution phase. Now that you've gotten access, what do you do with it? This is the point at which most actual tasks are performed. Indeed in most cases of normal everyday access, this is the only phase which most characters even make use of, as under ordinary circumstances, the prior two phases are no-check/Simple tasks where the technology level of the system actually assists the user.

Again, as in the previous phases, most computer systems are actually designed to make the execution phase easier, and will often apply the DM as a bonus for the user. For those attempting to operate the system in ways not originally intended, or for which the system is attempting to guard against, the DM will almost always be applied as a penalty to the attempt.

For Example:

Applicable Skills :
The skill used to handle this is T/Computer, possibly modified by the EW Specialist (encryption) or Hacker feats, depending on the task.

Success or Failure :
Success results in achieving the desired result. Great Success (DC+10) or Extraordinary Success (DC+20) may result in results of higher quality/effect, or in reduced time, at the GM's Discretion.


(Very) General Guidelines for
Typical allowed Tasks -
Privilege Levels: Guest / Basic / Unrestricted
Interact with the system: some / most / any
Unencoded Data: view / edit or save / any
Encoded data: none / view own / any
System Data (Log Files): none / some / any
Create Files: no / yes / any
Edit Files: no / some / any
Delete Files: no / own / any
Operate Devices Attached to System: no / most / any
Connect to other Systems: some / yes / any
Write or Install Programs: no / some / any
Run programs: some / most / any
Change System Security & Settings: no / settings / any
Encrypt Files: no / own / any
Decrypt Files: no / own / any

New Hacking Specific Tasks / DC / Time / Privilege
Escalate Privileges: * / 10 minutes / Any
Erase Evidence & Clean Logs: 15 / 1 hour / Unrestricted
Install Trojan Programs: 10 / 30 minutes / Unrestricted


"Escalate Privileges" increases the privilege level by 1 step (typically guest to Basic, or Basic to Unrestricted. Success or failure is treated as another Access phase performed from within the system, and has the appropriate success or failure results as outlined in the Access section above.

"Erase Evidence / Clean Logs" is a task to scrub the system to remove evidence of the Hacker's presence. Failure of the skill check for this task does *not* provide the character with knowledge of the failure, or what that failure is, GMs may want to make this roll in secret.

"Install Trojan Programs" is the task of installing programs that look like one thing, but do another. Examples include programs to covertly capture passwords and send them elsewhere, to monitor data being sent to/from the system, programs intended to lie in wait and then execute at a later time, etc. This task may be reversed, becoming "Remove Trojan Programs", permitting the safe removal of such software, identification of it's intended function, and possibly identification of the destination of any information sent elsewhere by the Trojan. This also permits the removal of Spyware and Windows Viruses... (Okay, just kidding!)

Chad Osborne:
Now assuming they actually bypass security (extremely difficult, but an expert might be able to do it given enough time), what can they then do? Can they lock or unlock hatches? Can they open/close airlocks? Can they vent the entire ship? If so, what safety measures would be in place? Can they activate other systems (weapons, drives, etc.)?


In our T20TneTU rules expansion above, a successful penetration must be presumed, and step three "Execution" has begun. As one can surmise from our version of this tasking set, the "Unrestricted privilege" would be the preferrable target zone of access, and in your example, at least "Basic Privilege" level of access for airlocks etc. that any crewman would have.
Specific areas of the ship like Life support (your venting query) may require the higher access of the Captain & Chief Engineer (again, Unrestricted access level of privileges).

Of course, due to the era of AI-Virus in which we play, such things as the Ship's gravitics, Lifesupport, are generally mechanical 'dead-man' switched to prevent the worst of what a hostile AI-Cym can do upon infecting a Ship's computer.

In pre-Virus era Traveller play, they could gain access to the ship via the airlocks, and even via the connection method applied at the airlock or cargo hatch, attempt to penetrate the Ship's computer itself.

Chad Osborne:
And finally, how would you envision detection working? Would someone on the bridge almost automatically notice as soon as things started acting strange? Or if the hacker was able to bypass security, does that mean they are pretty much un-noticed until they set off something obvious?


Physical detection & electronic detection is covered under our 'margin of success' table in step #2 "Access". Of course, having a crewman, or even a Ship's robot (pre-Virus Traveller eras) on the bridge watch to alert the crew can't be a bad thing.

I'm getting mixed signals from different rulesets and eras, and I'm trying to put together a logical system. Any advice would be greatly appreciated.

Chad
Hope this is of some use to you idea wise. Mr. George Adkins, btw, does fulltime computer work in the real world, and was immensely helpful with my original idea for T20 when I set out to describe in our campaign the ways and means available in a Non-Reformation Coalition campaign of detecting/ defeating an AI-Virally infected computer--which led to this co-operative work above.

Further DC's can be added, such as the T20 Handbook's DC 15 for the basic Anti-Hijack Program/ 1 PP, which is a Security Level 1 program. We have an optional table that takes SL to DC 35 (Security Level 5), which I did not include above.

Sorry for the long answer, Chad, gentlemen..
enjoyed it.

Game On!
 
Originally posted by Sir Dameon Toth:
</font><blockquote>quote:</font><hr /> Switch off inertial damping and just make a sharp turn.
That was a great mental image... </font>[/QUOTE]A standard anti-hijack technique is "long fore/aft corridor + acceleration - inertial dampers". A variation is to have an airlock at the aft end.
 
Originally posted by Andrew Boulton:
</font><blockquote>quote:</font><hr />Originally posted by Sir Dameon Toth:
</font><blockquote>quote:</font><hr /> Switch off inertial damping and just make a sharp turn.
That was a great mental image... </font>[/QUOTE]A standard anti-hijack technique is "long fore/aft corridor + acceleration - inertial dampers". A variation is to have an airlock at the aft end. </font>[/QUOTE]Now add in the rolling block floors of a cargo bay for and say "roller-blades/skates not needed", and watch 'em slide right out the airlock!
 
Liam Devlin, thank you for that!! Those look like a GREAT way to streamline the hacking system rather than always winging it, and I have some players that just recently started trying to hack into every computer system they get their grubby little paws on.
 
Originally posted by Chad Osborne:
My circumstances are a little different. The PCs are trying to enter a secured ship, in space. They have reason to believe that there are threats inside, and they were considering venting the ship to kill any occupants. I won't go into all the particulars, but the ship in question is a 2500 ton J4 capable modular freighter with three 1000 dton cargo modules.

Here's what I was thinking. The first successful hacking roll gets them in, and would probably be enough to work around anti-hijack software (e.g. to open a hatch). Failed attempts would be logged, and could alert anyone using the system that there was an attempt.


With you so far <nods>. Failed attempts and ones of non-registered access would be logged unless successfully reaching unrestricted access level of privilege. ;)

However, to actually open both sides of an the airlock at the same time (venting) requires a safety override. This requires a separate password (or another computer skill check). If that succeeds, that single airlock will open, venting the connected areas (a local alarm will sound while it remains open, and there is no way to stop that). If it fails (or wrong password is entered several times), a security alert would be sounded.

Does that seem logical? Chad
Sounds like a standard mechanical safety feature that must be manually over ridden/disabled [IF they think of it]. Now under an automated Traveller universe, yes, it woul require a separate task under the step 3 execution phase.

All quite logical to me, Chad. Good idea!

Game on!
 
Back
Top