It's easy to blame other for being passive.

No, you are looking for iconography.
The procedure is just a pulse.

Doesnt look like anything fluff at all. Especially the "how do you play out.." "What do you do . . ." part. Seems like I was asking for actions.

But maybe Rotbart will correct me in this . . . And I know that it is not his intention to participate in a good discussion. 90% of his posts are 1 line corrections or useless comments (do a search, youll find its true). But one learns to live with it.

More importantly, what is happening on the backend, i.e. the real programs running is always the same.
The only difference between VR and AR is the frontend, thus, the interface.

Patrolling IC is a pulse, nothing more, nothing less:
Either it's active or not, and the only things that metters is how long and how often.

Either that or you're still not getting it. Someone's offered a good example of how hide and seek (as you call it) in AR could be represented from a hacker's perspective, but it could even be represented as a simple text interface saying:

"Stealth program active...."
"Host system IC program activity detected... "
"Stealth program successful"

That is exactly the same as hiding behind the tree or shelf in VR, or "holding his breath so the hopping vampire can't see him", or "breaking a rice cake into six pieces so that the number of objects in the room would still be divisible by seven" in Frank's example.

In both cases what actually happened was the commlink successfully detected the IC scanning the system and Stealthed the tell-tales of your presence into the systems background traffic/activity/whatever. The host node, or the IC itself, detected some sort of inconsistency and sent a pulse your way/is checking your log register/verifying credentials/whatever and you've disguised/concealed them with a program that is designed to do just that. There was an Opposed Test between the IC and the hacker, which the hacker one. The dice roll/Test that you are on about was the same. The way you describe what happened (ie. the iconography, whether VR or AR , is irrelevant to the mechanics) - and it has no real bearing on the issue which you're really complaining about which is the apparently arbitrary rate those Tests are made (ie. whenever the GM decides the guard is looking in your direction/IC scans your particular memory space of the node).

Strangely enough I agree with both their explanations too. Neither contradicts what I've said before or what I've said above.

Frank goes on to say he's not taken with the current mechanic for IC, but that's neither here nor there regarding how the current mechanic functions nor whether the current mechanic is applicable above.

Nope. See above. We're actually talking about two issues here which have gotten confused because we've lumped the two together by using the guard on patrol metaphor for issue 1 (iconographic representation of the same process in AR/VR) and issue 2 (arbitrary IC scanning cycles in nodes).

Issue 1: everyone seems pretty much agreed (with the exception of cetiah). VR (a) is a representation, it is an interface, it doesn't "mean" anything, it is a translation of whatever process into whatever you (and not the host computer) want it to look like. AR (b) is ultimately the same thing, a different way of representing the process to the user. As regards the example at hand in both cases everyone seems agreed there is no hope of actually "hiding behind anything" - what you are actually doing is using a stealth program to conceal your presence and that is translated to (a) hiding behind something (or turning invisible, pulling a jedi mind trick on the IC/guard, breaking the rice cake into seven pieces, etc) or (b) having the messages above pop up on your AR interface (or the two joined circles and moving dots method some suggested before, etc).

In cases (a) and (b) the dice roll/Test involved is exactly the same. You may not like the mechanic or think it could be trimmed down and made faster, but it is not essentially flawed and more to the point its not the focus of your gripe.

Issue 2 (the one that is the focus of your gripe): is the (arbitrary) IC detection cycle and how IC in general operate—which, for the record, is what Rob actually likened to guards on patrol (and not the iconography-AR/VR representation). What he was suggesting was is that you don't need a hard and fast rule that the IC "looks your way" constantly, or every X Turns, or at points in your "Security Tally" (ie. you need to make the Test above). Instead he suggested the GM handle it like he would handle security on a meat world facility/guards on patrol (i.e you'd have more potential run ins with guards - and have to stealth your way past them - in a high-sec Mitsuhama lab than in a typical dock warehouse in the Everett. You know this going in because you've done your legwork and you might even know something of the security arrangement. Same with a Matrix system. You hit Evo's new genelab system and you know security/IC will be higher the backroom computer at the mom and pop deli on the corner.)



And yes cetiah, in the dark dystopian future where greedy, powerful, evil megacorps strive for world domination and market monopoly, I do envision several Windows-analogs as the market mainstays. Also, this balkanization of computer power and nature of the market leaders also explains why a uniform, cohesive approach to the Matrix would not come about.

The problem with that suggestion is that the way the rules are written, it's fairly simple to have an IC agent running scans over the whole of the node, constantly, without causing much of a performance hit.

So the question then becomes a matter of why a "patrol cycle" even exists in the first place, something that has yet to be explained, from what I've seen. It's not like IC can only look at a part of a node at a time: Matrix Perception Tests are node-wide. It's not like IC has to take a coffee break or visit the crapper. Sure, you have the overhead from the Analyze program running constantly as the IC looks for unauthorized personas, but the benefits of constant surveillance would make this a "no-brainer" choice for all but the lowest-end nodes.

Because there are rules for trying again.

Good point in breaking it down into the two isissuesThat make things much clearer (at least for me).
Ok, then we are down to this isissue

What we have so far now is:
Scanning IC is working just with an opposed perception/stealth test.
You do not have to play out hide and seek. You dont have to roleplay it, if you dont have time and the roleplaying part is in no way influencing the outcome by any means. It is just a representation. And the test will susucceedith the same probability in a VR desert like in a VR maze, once it is called.

I thought you where arguing against this because of statements like:

I thought you meant the process of being detected being like a physical intrusion, because you placed such a great emphasis on the "VR being real" part. If you only meant the frequency of test, I agree that is something you can do.

The issue at hand is:
The GM is calling for stealth test more or less arbitrarily, depending on whatever he sees fit, having in mind things like the amount of traffic, what the hacker is doing, how tight the security is and the hackers knowledge of the system.

This is clearly a "we dont give you rules, make them up yourself" situation. And I dont have to elaborate that very much. Especially not why the excuse: "Hey, we also dont give you exact rules for the frequency of perception tests in a infiltrator-guard situation the real world either" does not work, because you already know my opinion. So I just mention it here: Its because VR is not real. The number of variables is finite and quite small, as compared to the real world.

PS: What do you mean by "security tally"?

It's the SR3 value of your bad matrix deeds. The ones Santa, err, The System noticed, at least.

So how would that work, anyways? IC Agent is set up to use Analyze to scan the node automatically for stealthed personas. A hacker comes along with a rating 6 stealth program, and manages to pass repeated opposed tests against the IC until the IC has had its dice pool -2'ed into non-existence from the Try Again rule. That hacker is now safe from detection by that IC until the IC has "Rested" for the time specified by the GM (book suggests 5 minutes to an hour).

A minute later, some lesser hacker comes along with only a rating 1 stealth program. Is that IC Agent stuck with the same reduced/non-existent dice pool if it wanted to Analyze to detect that hacker? Sure, it's the same thing it just failed at a minute ago, "Perform a Matrix Perception Test to look for stealthed personas," but I would think that detecting a hacker using a rating 1 stealth program would have to count as a different task than detecting a hacker using a rating 6 stealth program.

Try Again should only apply to repeated attempts to perform the exact same task without a change in conditions. When the task involves an opposed test vs multiple opponents, some of whom you may have already failed previous tests against, it gets trickier. A opponent whom you're attempting your perception test against for the first time certainly indicates a change in conditions with respect to that opponent, so they should face a full dice pool, with or without the "rest period" called for by the Try Again rule.

Similarly, trying to detect a stealthed persona that's just entered the system should count as a different task than detecting a stealthed persona that's racked up one or more glitches. Detecting a persona that's acquired glitches should also call for the full dice pool regardless any "rest" taken or not taken since any previous failures to detect the hacker before he glitched.

Even with the Try Again rule, IC Agents running constant perception checks still sounds like a no-brainer. Any other reasons why there should be a "patrol cycle"?

Well, thats an interpretation.
(Not thats not a valid one, but still, there are others).

Edit: Though, the "scanning only sporadically" interpretation would have the consequence, that once you hacked yourself a user account (not admin, just user) you will not be noticed by IC anymore, even if you do something that is not covered by those privileges. As IC is not looking for hack actions constantly, but only sporadically scanning for valid user accounts.

This may or may not be desirable.

Serbitar, you almost always revert the conversation of hacking to either agents or account rights. Correct me if I'm wrong on this, but is it your view that when a hacker is hacking into a system, he is, by definition, logging into the system with an account? Is it your view that a hacker can choose to login with an "illegitimate account"? Can he login and hack without an account? It would help me to understand some of your arguments that I've having trouble grasping if you can give me an idea where you're coming from with this view.

It sounds like you're saying that a hacker is given rights by the system because of his account (legitimate or not). I think that's taking the definition of "rights" a little too far. Accounts aren't the only thing given "rights"; programs and processes are given rights, too. For that matter, "rights" just means that a given task (like assigning a pointer to a zero-length block of memory) is protected from accounts, programs, and processes that do not have "rights". So what? A hacker can bypass these protections... that's what he does. That's what his Exploit system is supposed to do. So by a hacker's "rights" we're not necessarily talking about the same type of "rights" that a user or admin is assigned by the system, but rather a measure of the capabilities the hacker can influence within the system despite his lack of any rights granted by the system.

Does that make sense?

So, acquiring rights by aquiring an account is one technique of the hacker, but it is not the only technique, nor is it the best technique (far from it), nor is it particularly "stealthy", and I don't think it should be thought of as the default model for hacking that you seem to imply. (Or at least that's the impression I get from your posts.)

Garrowolf, Synner, correct me if I'm wrong in any of this.

(P.S. I know this contradicts my earlier posts, but I think we've all seemed to abandon my "Matrix as Operating System" theory, which, I still think has a lot of merit despite everyone's insistence on dismissing it, by the way.)

That assumes that IC are checking logs and not loooking a "current" flags, or pass codes.

Again, a valid assumption, but still one that does not necessarily have to be made.

Typically all process and and services are running as a user. An attacker who compromises a service or process gets access to the system as the account that the process should have. In a well run system this is not a admin account, so the attacker next has to do some sort of priv escalation to get full control of the system. This is the SR exploit.

Answering your questions:

I have no idea how RAW sees it. RAW is giving not enough information to give a straight answer to any of those questions. Thats why I am just pointing out consequences of interpretations.

But your ipmression that I am always coming back to agents or accounts might have to do with the fact, taht I am building my intrepretations arround a certain protocol of node interaction. Once this protcol is set, everything (programs, software, agents, persona) has to obey it. Thats what I call consistency (and as a by product streamlining and simplicity).

In my own hacking rules, yoou hack into an account but you dont have the password for it. You can not hack into an illegitimate account because such a thing doesnt exist. You also cant hack into accounts that dont exist. Thats why you cant hack into a user level account when no such account exist. If you only hacked rights, you could hack in with user rights even if no user account existed (somethig that is contradicting Rotbarts interpretation with RAW).
In my world, nothing can exist without an account. Even when only interacting with the node you "log in" with an anonymous account.

In my world programs and agents run on accounts, because thats how it is done in the real world. I stick to real world stuff,b ecause I know that it works and translate it to construct a ruleset that works.

A hacker can do everything with computer without being resisted, his account has the rights to do. For everything else, he has to hack and the node resists.

But again, thats just my world.

Yeah, I don't care about RAW; at least not for this sub-discussion. I'm just trying to get our views on what hacking IS because it seems like we're at cross-purposes due to our definitions.

Thank you for clarifying your position.
Here is mine:

(I don't like the word Node for this discussion. I'll use system, because that's what I'm talking about. Usually the operating system, but also all programs and such installed into it.)

A system has three major components: programs, GUI, and processes. The GUI is what gives the user access to programs and processes, and users are categorized as given rights to their accounts, we can conceptually percieve this as: Programs, Accounts, and Processes.

Now despite what you posted above about so-called "real life", a system *is* capable of running a program without a user-account telling it to do so. It's also capable of running processes. Examples of processes include managing memories, updating the system clock, managing how much power is used, maintaining a cache for file access, and hundreds of thousands of other similiar tasks happening all the time managed only by the system. Often, even an administrator working with all of his administrator rights can't access some of these processes if the operating system wasn't made to allow such access.

I think we can take for a given that the user-account can access processes through the GUI. If a user says "delete this program", that's a process. Technically it's being accessed through a program (delete) but that's breaking the operating system too far into component programs. In fact, when I specify "programs", I'm pretty much talking about "applications".

For the purposes of our discussion, the user (through his GUI, through his account) can perform processes (such as delete files off a hard drive, for example) and the operating system can perform processes (such as deleting all contents in a block of memory).

Programs can also access processes. For the typical user, everything he does is through programs. Need to scan for a file to see if it's being tampered with? Use a program to compare its code to a previously recorded code for that file. Need to dial into another computer? Use a program that sends commands to the modem. Hell, operating systems will do that for you these days with a variety of processes that manage your internet connection. A user using a program may think he's just clicking on a hyperlink, but there are thousands of processes that go in the background.

A "right" therefore is defined in two ways: 1) as the ability to perform or terminate a process, and 2) as the ability to execute a program with the ability to perform or terminate a process.

For example, generally my Windows environment doesn't give me the right to directly determine what pixels appear on my screen. Those rights are determined by programs that send requests to the operating system which sends requests to the video card. However, it is possible to access a program where I can input binary commands that completely bypass and override the operating system, sending conflicting commands to my video card and effectively destroying my display.

So what's the point of all this?

It's important because in addition to the standard GUI used with operating system, there's all kinds of ways to access processes within a computer system without using the GUI or its associated programs. Security features use "rights" as one method of preventing a hacker from doing just that, but there are ways of bypassing these restrictions. A hacker is someone who knows those ways. Since he doesn't need "rights" or permission from the operating system to directly access processes, he's very difficult to detect. Effectively, nothing is telling that operating system that the process is being run - and since the operating system itself isn't running it, it may remain ignorant of it until it tries to access that device, file, block of memory, byte, sector, or whatever (at which point it will either alert the sysop or crash completely, depending on who made your operating system).

So, definition of hacker: Someone who can directly access a computer process without going through applications or the operating system. Alternatively, somone who has the ability to bypass the operating system.

User accounts never go deeper than the highest layer of the operating system, since that's the part that interacts with users.

That's where I'm coming from.

I advise others in this discussion to post their "conceptual views" on what a hacker is so that we can all get on the same page and move forward.

You do neither. You trick the system into doing your bidding, then use it.

Trying to manually modify a process by machine code is... not an option.

Machine Code is not the only process you have at your disposal. That problem came up earlier in this thread, too... there isn't just GUI and MACHINE CODE, you know. There are many subtle levels of programming in between. Users and administrators work in the HIGHEST level of programming and function, giving commands and requests and then allowing those requests to be translated at multiple stages until finally everything that needs to be be managed, is managed.

There are many, many LOWER LEVELS of easily accessible programming beneath the GUI where you can bypass a lot of this "translation process", especially the ones that aren't necessary. For example, programming in Python is still programming and you can do a lot with it - but the system still manages A LOT for you behind the scenes. While C, for example, is a much lower-level programming language, able to do its job far more efficiently but requiring the programmer to do a lot of low-level management of system resources by hand.

Hackers, thus, would have programs (like Exploit) that works at a much lower level of programming than the standard GUI. The lower the level, the more skill required, and the more efficient the end result (as a general rule).

Okay, yeah. But specifically, I'm talking about the kernel, its processes, interupts and system calls, not (just) kernelspace.

Why would a hacker be using anything else?

These are just aspects of how virtual memory are assigned. There's more to a system than that. And I told you what I was focussing on. Why did you choose to ignore it? System calls and interupts to the kernel are at the very heart of what I'm talking about.

---

Okay. There's not much point in us trying to convince eachother either way. It's obvious we have two very different models for how someone "hacks", both in the game and the real world.

But I think knowing this will help us in the discussions on this thread.

Apparently not. Given the information in the article, this has been a nearly standard attack pattern against windows machines since 3.1, thus the encryption includes a salt nowadays...


per the article of course. I haven't got three clues what a rainbow table actually is..

He was being sarcastic.

Serbiter, are you just arguing for the sake of it now? I know you want to defend your system, but this is rediculous. First you critique SR4 for not being realistic. Then you attack other interpretations to streamline custom rules for not taking into account your views on how hacking works. Then when someone tries to explain to you that your views in no way match how hacking rules, you say you don't care, and want to know how it works in SR4.

There have been numerous attempts to explain it to you. I and others have tried. You just don't want to listen.

An exploit allows you access to a system without a user account. That's how it works in SR4. A hacker doesn't have permission rights, but he can do stuff anyway. (My theory is that this is done through the kernel.)

A hacker can attempt to get a user account, but this is +3 to his exploit test. Since a user account has basic permissions to many parts of a system and limited access to the operating system, he can do more from here. With +6 he has admin access which has even more permissions, but still not everything.

You are not understanding it because you are sticking to this idea that there is no way to hack a system unless you have a user account that gives you permission rights. It's just not true.

Gorrawolf, I can only respond in a very limited way to your suggestions so I'm sorry if I sometimes ignore your points. But a lot of what you describe was the "mission statement" behind my custom hacking rules, so I don't know what I can contribute that dodn't go into those and I know you've already seen them. So, I want to contribute more and feel you're bringing up important points and ideas, I just don't know how to contribute.

I know this statement was addressed to Serbiter, but if you're applying it to the posts that Garrowolf or I have made on that subject, I want to point out that what is being called into question is not just the "abitrary rate those tests are made" but whether some of them even need to be made at all. Just trying to clarify matters.

Serbiter, this isn't fair. You attack an interpretation, demending a defense, then someone else explains/defends/expands it, and you dismiss the reply out of hand because its not convinient for your interpretation. If your going to request a clarification on an interpretation you have to be prepared to awcknoledge the response.

Someone (Synner?) already addressed that the perception-tests are not node-wide. The perception test is made to see if the IC is looking in the particular part of the system you are accessing at the moment as it cycles one at a time through the various files and processes in a system. IC, apparently, can not look at all aspects of the node at one time.

I agree, but this is an overall flaw with Shadowrun, and maybe RPGs in general that rely on a "skilled gamemaster" as the omni-answer to everything. You won't fix it by re-writing the hacking rules. (I'm well aware of your baselines though and agree that they are vitally important and missing from the rules. I've made my own for my system. But it's really a minor point. RPGs have never really worked out stuff like this and its not fair to bash Shadowrun for it.

It's a really cool rule from older editions that, in practice, was kind of difficult to implement. Fans of the system tend to bash SR4 for not having it (or something like it). Serbiter added one in his system that was a little more streamlined. I've been trying to avoid adding something like it to my system.
It was basically a security count-up of all activity on the system. Everything was handled in opposed tests with the system counting up all hits and adding results to its security tally. The GM had a pre-designed sheet that showed the system's response when the tally got to certain points. Like "4 - Release Trace IC, 12 - Release Attack IC" for example.
It was the main reason you couldn't simplify hacking (as per Garrawolf's suggestions) because you'd have to re-write the security tally rules which depended on having all of those opposed rolls.

Thank's for answering a question asked by someone else than me.

First: I dont want to defend my system (my system was never attacked in this thread, it wasnt even discussed). If I really want something in this thread then it is to show the flaws of RAW.
Second: I am not criticising rules for not taking my rules into account, but for not being consistent or streamlined. That is an objective criteria. This has very little to do with what I prefer. And when I prefer something I write phrases lie "in my world" "I would like to" "I prefer" "in my opinion" "at least for me" and so on. Search for them, you will find them.
Third: I dont care about a certain level of complexity. On some point you have to make abstractions. How exactly hacking works is abstracted by me as well as by RAW. So it is completely irrelevant. Accounts and Rights are not abstracted (if that is an English word). They appear in the rules, so it matters how they work. Its really that simple.

This is simply wrong. It is not mentioned at all in RAW wheter you get a user account or only the permissions. Its completely up to interpretation. The phrase that is used in RAW is "user access". Whatever this is.
And a hacker HAS permission rights. That is explicitly stated in RAW.
Maybe ask Rotbart if you dont believe me. He stresses the point several times in this thread.

+0 is user access
+3 is security access
+6 is admin access
whatever "access" is. Its up to you to interpret it.

Wrong again. I explicitly mention that you can make this assumption (not getting an account by hacking in), but point out some consequences. But you always have at least user access (again, whatever that is) that comes with user permissions.

PLease read my posts before complaining.

Actuall you wanted to know how I view things. I just want to point out consitency flaws and anti streamlining in RAW and point out consequnces of certain assumptions.

Maybe you dindt get the "this may or may not be desirable part".
Im am not dismissing anything, I am just stating the consequences which one has to live with then making an assumption. Its for everybody himself to deside wheter he wants to make the assumptions or not. Be there is no way arround the consequences of an assumption.

So you basically say: "Well, all rules in every RPG are bad, no point in trying to make them better?"
What kind of reasoning is this?
Especially as it is extremely easy to give rules for scanning IC if you want to. Its exactly one sentence.
"Everytime a hacker performs an action not coverd by his permission rights, the IC can roll a perception test to spot this action."
Doesnt sound too difficult for me. And I really dont see the reason why anybody should prefer a "the GM will handle it" solution, and defend it for pages after pages, just because its written in a book (no, we are not talking about religion at the moment).

And btw its Serbitar.