Help - Search - Members - Calendar
Full Version: Hacker's Despair
Dumpshock Forums > Discussion > Shadowrun
McAllister
Here's Matrix Perception, liberally snipped:
QUOTE
*snip*... basic Matrix perception is usually limited to a very narrow subset of things, such as the nodes and icons of users with which you are interacting, menus, AROs, and any display features you call up.
If you wish to specifically examine an ARO, users, programs, IC, nodes, files, etc., take a Simple Action to Analyze Icon/Node (p. 229). Make a Matrix Perception test using your Computer + Analyze program (rather than Perception + Intuition). *snip*
If your target is running a Stealth program, the Matrix Perception test becomes an Opposed Test, with the target rolling Hacking + Stealth (or Firewall + Stealth for programs or nodes) as the opposing dice pool. The hits from this test reduce your hits and consequently the amount of information you get. If you garner no net hits, the target is not invisible as such, but its icon has melded into the background of data traffic, escaping your notice.

Here's the Data Bomb program:
QUOTE
"Data Bomb programs create a specialized form of reactive executable in a file or node, called a data bomb (note the difference in capitalization: Data Bomb is the program, whereas a data bomb is the executable set by the program). A data bomb is attached to a specific file or node and set to activate if someone accesses the file or node without authorization. When triggered, a data bomb “explodes� and attempts to crash the icon that accessed the file or node. Data bombs may also be instructed to erase the file or crash the node, if the owner chooses. Data bombs are set with the Set Data Bomb action (p. 231). Only one data bomb may be attached to a particular file or device. You can detect a data bomb with a successful Matrix Perception Test. You can defuse a data bomb simply by entering the correct passcode. Without the passcode, you can only disable a detected data bomb with a successful Disarm Data Bomb action (p. 231). When it “detonates,� a data bomb inflicts a number of boxes of Matrix damage equal to (rating x 1D6), then the data bomb is deleted."

Here's the Stealth program:
QUOTE
"Stealth is a clever hacker program that attempts to hide the hacker from other system processes. While it cannot make an icon completely undetectable, it makes the hacker seem innocuous by obfuscating his activities, erasing system tracks, and mimicking authorized traffic. While it is not used for any action, Stealth hides the hacker from detection by the Firewall as he breaks into a system (p. 227), as well as from Matrix Perception tests (p. 228) and Trace User attempts (p. 232)."

Here's the definition of "Icon;"
QUOTE
"The virtual representation of a program, file or other virtual object in the Matrix."

Here's my thought: I have some paydata that I want to protect. I put a data bomb on it. A data bomb is a file (it's referred to as an executable, and executables are files), so I want to put a data bomb on my data bomb. This does not violate the one-bomb-per-file rule, because two files have bombs attached to them; the paydata, and the paydata's data bomb. Any good hacker looking to steal my data will examine it for a data bomb, but will they examine my data bomb for a data bomb? Maybe, maybe not. If they miss the second bomb and try to disarm the first one without disarming the second one, great; I'll blow them up. However, is it possible to give the second data bomb its own Stealth program? At some points the Stealth program says it hides "the hacker," but it also says "it cannot make an icon completely undetectable, etc. etc" implying that it will work on icons, and data bombs are icons.

Now, this is in no way an "easy" defensive set-up, because having three defensive programs constantly running (two data bombs and a dedicated Stealth) will eat up a commlink's resources, but does it follow all the rules? Because if so... hackers beware.
CodeBreaker
I think that depends on something very important. Is a Program considered a File by RAW? I would say no, they are talked about in the same sentence to refer to different things within the quotes you provide, and more times in the books. Databombs can only be applied to Files or Nodes. The Databomb is itself a Program, not a File. I would still say that the Databomb itself is still the Databomb program as well. Thus the Databomb cannot be applied to a Databomb.

However on Stealth hiding Databombs, yes they can. In fact Unwired says it can.

Your thoughts?
McAllister
I'll be able to live with a Stealthed-up data bomb (and I missed where Unwired said that was legal, thanks for pointing it out. I still haven't slogged through it cover-to-cover), but my thought is this; is a File the same as a file? The data bombs created by the Data Bomb Program as referred to as "executables," which means (according to real-life computer terminology) they are files. However, I agree that it's unclear whether or not they're Files.

Another Data Bomb question; how does a hacker go about disarming a data bomb attached to a node that he want to enter? Would a hacker need to A. examine the node to find it, B. disarm it and C. hack himself access, or would he need to 1. hack himself access, 2. examine the node from the inside and 3. disarm the bomb before subscribing to the node? For that matter, I'm not even 100% on what you're allowed to see with Analyze. I'd assume any node would only allow itself to be Analyzed by a subscribed user, but I couldn't prove it.

Also, thank you for your swift and useful response.
toolbox
QUOTE (McAllister @ Aug 9 2009, 08:25 PM) *
This does not violate the one-bomb-per-file rule, because two files have bombs attached to them; the paydata, and the paydata's data bomb.

That distinction is largely semantic, though. If a hacker was to access the paydata file without checking it for attached data bombs, how many bombs would go off? If a legitimate user entered the relevant passcodes to temporarily disarm the bombs and copied the paydata file to a new node, how many bombs would go along with it? I don't think the answer to these questions is allowed to be a number >1.
McAllister
I agree; if the paydata were accessed blindly, only bomb #1 would go off. Bomb #2 exists (or would exist) solely to ruin the day of anyone incautiously accessing bomb #1. It's like there's a trap protecting the data, and an extra-hidden trap that's triggered by anyone disarming the first trap.
otakusensei
Wait... but if you databomb a databomb that's attached to paydata, wouldn't the second bomb destroy the first bomb and leave the file intact? You could databomb that databomb, but then you still only have the original. It's like the Tracebuster-buster-buster-buster of data security, except it doesn't do anything other than either setting one bomb, or no bomb at all...
Aaron
QUOTE (McAllister @ Aug 9 2009, 11:25 PM) *
(it's referred to as an executable, and executables are files)

I think this is where the argument becomes spurious. I cannot find evidence that executables are treated like files in the Matrix rules. And while one could apply real-world logic to the term "file," (i.e. "executables are files"), I think one would have to do so selectively to come to the conclusion that data bombs are files. It would mean that programs are files, icons are files, System software is files, and so on. The book routinely lists files as being separate from icons (although files have icons), programs, agents, sprites, etc. Were we to accept the "executables are files" argument, it would mean that the Edit program can be used to destroy, say, a sprite or a Firewall.

That said, if you can convince your GM, I say go for it. Just be careful; GMs have a funny way of using your tricks against you.
McAllister
QUOTE (otakusensei @ Aug 10 2009, 11:24 AM) *
Wait... but if you databomb a databomb that's attached to paydata, wouldn't the second bomb destroy the first bomb and leave the file intact? You could databomb that databomb, but then you still only have the original. It's like the Tracebuster-buster-buster-buster of data security, except it doesn't do anything other than either setting one bomb, or no bomb at all...

A data bomb CAN be set to destroy the file it's attached to, but it's not necessary. I would, if possible, give both data bombs the Pavlov option and set them NOT to destroy any files, so that the trap would be reusable. Besides... if I also gave each of them the Biofeedback 6P option, it means that hackers who tripped them wouldn't be eager to come back, if they even survived; 6P from the data bomb and 5P from getting dumped (because 6d6 matrix damage WILL dump you) could certainly kill an unwary hacker.
McAllister
QUOTE (Aaron @ Aug 10 2009, 01:16 PM) *
I think this is where the argument becomes spurious. I cannot find evidence that executables are treated like files in the Matrix rules. And while one could apply real-world logic to the term "file," (i.e. "executables are files"), I think one would have to do so selectively to come to the conclusion that data bombs are files. It would mean that programs are files, icons are files, System software is files, and so on. The book routinely lists files as being separate from icons (although files have icons), programs, agents, sprites, etc. Were we to accept the "executables are files" argument, it would mean that the Edit program can be used to destroy, say, a sprite or a Firewall.

That said, if you can convince your GM, I say go for it. Just be careful; GMs have a funny way of using your tricks against you.

First of all, I don't have any particular plans for this set-up, so I could just as easily throw it as players as a GM instead of using it from a player's point of view. That said, I agree that "executables are files" is quite shaky. The only question I have, then, is if they aren't files, what are they?

Also, I have to think of a good reason that Edit isn't a magic wand. I can only think that you're only able to Edit programs you have access to, and deleting them with Edit is ineffective because they can be restored from back-ups. That's why the Corrupt program exists, right?
Orcus Blackweather
Regardless of whether you can stack bombs, the best defense for the paydata is turning the commlink off.

the only way to hack the file is to take physical possession of the commlink (probably over your dead body)

In fact this is the best security for anyone. Keep nothing of value on any system that is connected to any wireless device. You have to access credit accounts and such, and you need your fake id, but everything else, such as pay data should be stored in an offline storage of some sort (perhaps a second comm that is turned off except when needed)

All cyberware should be DNI only, with the exception of cybereyes connected to internal commlink(maybe, perhaps you should run the imagelink on glasses instead and leave the cybereyes as DNI as well).

This security scheme has the added benefit of being very cost effective.
PirateChef
A file is a collection of data. A program that is not running could count as a file, since it is just a collection of data that is ordered in a certain way. (.EXE Files, for a RL example)
Programs that are running are considered executables, not files, b/c they exist in RAM, and are constantly changing. If you try to delete a program that is not running, your OS allows it (assuming you have the proper security clearance). But if the program is running you get told that it cannot be deleted b/c it is currently in use (ie the program is in a state of flux so the system doesn't know exactly what data to delete). I see this applying to programs running in the matrix (Data Bomb included). They are constantly taking in data, analyzing data, whatever, so they are not the same as a simple file.
McAllister
It's true. If I could sit at home on my couch and nab all the paydata, they'd have to change the name to Shadowlounge.
otakusensei
The one big issue I have to loading up two data bombs with essentially the same purpose is that because the rules are representative and not absolute, the single data bomb that you can add represents every effort you can under go to do that action. That doesn't cover RAW, that's all RAI.

As for executables being files it isn't so cut and dried. In some files systems you can have a file that has all sorts of additional information attached to it. There could be many times the file's normal size in data locked up along with it and your OS might not even tell you. That's part of the discrepancy you see in File Size vs. Size on Disk in the real world.

In Shadowrun I can only assume that a file with another file attached will look inherently different, where as the "executable" data bomb left by the Data Bomb program is made to ride along with a file or node relatively undetected. Unfortunately there should have been a better definition of what an "executable" was, but it's pretty clearly not what we understand an executable to be in the real world (i.e. a file). If it was they wouldn't have had to call the data bomb something else, it would have been a "file inside of" or a "file with" another file. Because they didn't state that it was a file I can only assume that the executable is meant to be information added to an existing node or file, part of that file for all intents a purposes, and as such cannot have another data bomb added to it.
The Monk
Is this damage (rating Xd6) SR4A?
McAllister
It's SR4A, I dunno what kind of damage they did in SR4.

Kinda makes you want to keep your distance from the technomancer when he's hacking. 20+ damage delivered straight to his brain? You're probably going to get splattered with some chunks if that goes off.
Tymeaus Jalynsfein
QUOTE (Orcus Blackweather @ Aug 10 2009, 11:45 AM) *
Regardless of whether you can stack bombs, the best defense for the paydata is turning the commlink off.

the only way to hack the file is to take physical possession of the commlink (probably over your dead body)

In fact this is the best security for anyone. Keep nothing of value on any system that is connected to any wireless device. You have to access credit accounts and such, and you need your fake id, but everything else, such as pay data should be stored in an offline storage of some sort (perhaps a second comm that is turned off except when needed)

All cyberware should be DNI only, with the exception of cybereyes connected to internal commlink(maybe, perhaps you should run the imagelink on glasses instead and leave the cybereyes as DNI as well).

This security scheme has the added benefit of being very cost effective.


Except that Cybereyes with an Image Link connected to an Internal Comlink IS DNI...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Dumpshock Forums © 2001-2012