Decivre wrote:

Which is why I recommended that critical successes on a brute force test be instantaneous breaks. It allows for hackers to do very quick entries into systems without completely invalidating the use of a firewall (brute force hacking puts you automatically into locked status). Moreover, if you're going for a cinematic feel, it seems more appropriate to me that the system is informed so a climactic mesh duel occurs, don't you?

Indeed you did, and a very good suggestion it was, and one I will most likely use. However, I wasn't saying that any of the points you raised weren't valid, I was pointing out that it feels like you are trashing other peoples opinions or ideas just because they don't mesh (excuse the pun) with your way of doing things. We all have an equal voice here, we shouldn't be trying to push our own visions of anything. G.

smokeskin wrote:

With EP, the main problem I see is to get around extra actions from multitasking and such not benefitting from this - is supposed to switch and action normally be used for shooting to provide an equivalent effect by buffing others. But from my experience it can be completely viable with rules that lets a character do meaningful stuff in combat without firing.

I ran a player with an engineer character (in EP) and do a similar thing by allowing her to make field modifications to equipment, but that was too situational to be a sustainable mechanic. I think one way of accounting for mental actions could be as follows: increase smartlink bonus by 5 for rest of action turn (no stacking), increase chameleon skin by 5 for rest of action turn (no stacking), negate 5 of the indirect fire modifier for rest of action turn (no stacking). Start with a short list of things like this and then allow hackers to make up their own mods, making a programming roll to develop their method (modified by GM). This could also work for negative modifiers on enemies, using the limited uses exploit thing (these will be 'spensive imepu.

GJD wrote:

Oh really? And the phrase "It just dosen't make sense from a technical standpoint" isn't trashing somones opinion? It's not what you say, it's how you say it. G.

Hey, if your campaign had people falling away from the ground and ships that could fly faster than light, I would say it "breaks the laws of physics". I'm not trying to denigrate the idea or the person who stated it, I'm just calling it how I see it. Seriously though, why would it make sense? If I use an exploit on an isolate habitat that has no communication with the outside world, why would that exploit lose "one use"? Moreover, why does the specific number really matter? Why can I use some powerful exploit a single time, then save it for years without anyone ever getting the bright mind to patch the flaw that it exploits, simply because I only used it once? Did they magically all forgive me? Assume "eh, it only happened once. It's not like we actually need to patch a problem, right?" Did no one else in the whole system find the flaw that I found? I was simply being honest about finding the idea flawed. Besides, how could I have stated it more politely? I didn't drop an insult in that entire statement, didn't make a snide comment, nor did I use any sarcasm... so what was it?

*facepalm* "It's just fiction, so it doesn't matter if I get the science wrong"? [i]Really?[/i]

Decivre wrote:

Hell, you can plug dragons, elves, dwarves, warp drives, cylons, zergs, death stars, Jedi and sentient candy corn into your Eclipse Phase setting if that's what floats your boat...

Hmm. I'll point out that dragons, elves, and dwarves are all well within transhuman bioengineering abilities. The Zerg very well may be as well, at the very least without the whole "super-evolution" thing and superpowered psychic hive mind thing they've got going on. Jedi are a real religion, if relatively small. As for the sentient candy corn, well, they'd probably be about the right size to serve as the nodes of a swarmanoid morph. Warp drives and death stars are right out, though, at least for transhumans. The ETI might be capable of building them, though.

Except, you know, that he [i]is[/i] right, at least about this. His understanding of weapons systems could use some work, but as for this, well...

GJD wrote:

You don't have to do any of the things you mentioned to make your response unreasonable. I take umbarage not at what you said but in the bombastic "I am right" assertion that you know how this part of the game should work because you have a certain view based on your experience. Since I'm assuming that you don't actually come from the future, have a mesh security manual that dropped through a wormhole from the future or have psychic precognition that allows you to see into the future, I'll assume that you, like me, are actually making this stuff up based on what you know and extrapolating and not actually trying to tell me how it ACTUALLY works in AF10.

As much as computer technology has advanced in the past century, there are plenty of things that haven't changed. Computers still function with a binary numeric system. They still utilize a complex sequence of logic gates to produce mathematic functions. They require an input (keyboard, mouse, punch card feed or thought-controlled data transmission) and output (monitor, printer, LED light display or neural uploading technology) interface. They are Turing complete. They utilize a software bootstrapping process so that they can handle complex software loading procedures without the need to be shut off between programs (which only the oldest and simplest computers don't have). They utilize directly-accessible memory to which the processor can shove data when it isn't using it, and pull it again when the need arises (again, only the first computers didn't have this). There are dozens upon dozens of things I could list, on and on, that have yet to change when it comes to computer technology. On the other hand, there are plenty of things that have and will changed. Architecture has remained stable for a few decades, but has also begun to shift as the demands of the consumer base change. IBM PC compatible computers are likely to die off or change as technology it simply wasn't designed to handle becomes ubiquitous (like universal memory); by Eclipse Phase's time, computers will be so small that the modular IBM PC architecture (which was designed so that peripheral components and parts could be added, exchanged and replaced with human hands) will become completely worthless. Cell phones threaten to completely overtake the personal computer as the de facto standard of internet access; by Eclipse Phase's time, ectos and mesh inserts will do the same to all other computer tech before them. Computers today can handle 64-bit singular integers, when the earliest computers could often only handle 1-4; who knows how massive an integer mesh inserts can handle. Keyboards and mice have virtually replaced all human input methods that came before them; Eclipse Phase tech seems largely thought-controlled, which would shove both prior-mentioned technologies into obsolescence. As one of my favorite sayings go, "the more things change, the more they stay the same". As much as I know that computer technology will advance and change in the generations to come, there is plenty I know won't change. I'm not under the impression that computers will be powered by magic smoke, or that at some point all software will be so advanced that it will be impossible to hack. I also know, with as close to absolute certainty that I could possibly have, that software will never go obsolete [i]directly due to overuse[/i]. In fact, I will go one better; as computer software gradually utilizes more learning algorithms and skirts the line of artificial intelligence closer and closer, it is more likely that computer software will [i]improve with more use[/i]. In fact, many technologies today already do this (predictive text software on phones, speech recognition software, Norton's SONAR and SONAR 2 technology in their antivirus suites being the first to come to mind).

GJD wrote:

I know how computer security works too. I know that when an exploit is found, it works until somone closes it. This can happen quickly, or slowly, depending on how widespread the exploit is, how quickly the exploit is spread, how quickly it is recognised, how quickly a resolution is found and how quickly that resolution can be propogated. Some exploits lie around for years, some are patched and closed the same day they are encountered.

Very true, though you have left out several factors. Exploits can and have been closed by third-party software, as has become common for outdated versions of IE and Norton's antivirus suite. Moreover, the most common reason for lack of computer security is a lack of updates. However, internet ubiquity and automatically-updating software have rendered both of these issues gradually more moot. Because of this, hacking has become less about slipping through old holes, and more about staying ahead of the curve. The invention of the mesh will likely have a similar effect, and more prominently so as the personal computers in that time (and in the very near future) are almost completely based around mesh (internet) use. Besides, the most effective exploits don't rely on software holes anyways. They rely on human error, the one thing that never universally improves. This is why trojan horses continue to remain widespread despite all efforts to halt it... no programmer can ever fix the gaping wide security hole that exists between your keyboard and chair (or inserts and groin; PEBIAG).

GJD wrote:

There are several ways you could reflect this in the game. You could model that by: 1. Arbitrarily saying an exploit only works for a month or two. 2, Each hacking attempt has a cumulative possibility of dropping the effectiveness - first attempt with your Jackhammer program works fine, next attempt has a 10% chance of dropping the effectivness, next has a 20% and so on 3. Each exploit a set number of uses. 4. Each exploit a random but unknown to the player set of uses 5. Each exploit works fine if the hacker remain undetected, but each time they are detected the icebreaker faces a chance of degrading. 6. Use no special rules and decide the hacker just normally updates their meshware to the latest level. These are just a few ways i came up with, there are undoubtedly loads more. All of these are abstractions to a greater or lesser degree of my core requirement: a hacking method, be that using a certain piece of software or a certain exploit, won't last forever. The choice of which method I choose to use is based on how much abstraction I want and am prepared to accept. All of them can achieve the aim of reflecting that.

But why does the amount of time an exploit continues to exist necessarily need to be arbitrary? The duration of an exploit can be directly based on a person's MoS during the programming test they took while creating it (which represents just how far beyond the curve their creation actually is, and how long it'll take for the rest of transhumanity to catch up). Moreover, the actual book already makes mention of ways to handle it, which as far as I can tell seem far easier and just as managably abstract as anything else listed (all software, hack or otherwise, degrades by 10 at a specific interval; 3 months recommended; page 246). My big problem is that all of these recommendations are directly based on how many times you use software, when that literally has nothing to do with whether software goes obsolete. It would be like if we determined the size of a ship based on the pilot's skill.

GJD wrote:

The way I see it is that in this instance I am trying to model the process of obsolescence that appears when hacking "software" is used, that some things do not last forever and that a white-hot piece of code only takes one guy to write an equally white hot piece of code to make it obsolete. I want to show that eventually every piece of Ubersoft Hackmaster 3000 will need to be replaced with an Ubersoft Hackmaster 3001. Limited uses are one way to demonstrate that.

But a very abstract way to do so which risks creating bizarre issues. Reliable Firewall 9.9 (which are generally ran 24/7) will likely go bad long before Uber-Exploit 3.36, which can literally shut down the entire mesh simultaneously, because the latter has 5 uses and you've only used 1. So long as the other four remain, no one ever seems to get up and do anything about it despite the fact that they openly know that there's a [b]glaringly brutal flaw that threatens to shut down the entire mesh![/b]

GJD wrote:

On to your second point, if you want to know how you could have stated that in a more approachable way, here are some phrases you could try on: "Hmm, that's an intersteing idea, GJD, but I feel that it dosen't reflect how I see the mesh intrusion/security working" or perhaps "I see what you are saying, but my feeling is that the technology works in a different way..." or maybe "That's certainly one way of looking at it. I'd be inclined to adopt a different approach, though...." or even "Good idea, but have you considered that maybe....." G.

I apologize if I don't have the social tact of a preschool teacher or a politician, but my social life consists of night clubs and bars. Just gazing over my posts easily tells me that I am using [i]infinitely more[/i] tact here than I ever hear or use in my usual social scenarios, even I generally speak to people who would crucify you if they even get a whiff that you fail to be politically correct (which has always drew my ire about them). If that's not good enough to satisfy, then I doubt that anything I say will be. Besides, none of the above listed statements reflected what I intended to say. I would like to find a way to convey my thoughts more politely, but not at the cost of my ability to convey thoughts.

i'm on limited bandwidth and expensive mobile broadband on the second leg of my 18 hour train journey here, due to geological uphevals in Iceland grounding my plane, so i won't bother with quotes and all that jazz. Decivre, I'm not trying to simulate the obsolescence of the software itself, I get that software is immutable, but I do want to show that a cutting edge exploit that works one day may not the next. The examples I quoted were just a few that I came up with off the top of my head, and weren't supposed to be an exhaustive list at all. Time could be variable, as you said. One of the ways of doing it is to use an "ammo count", which isn't to suggest that the software can only be used 6 times before it self destructs (without some sort of crippleware, as you suggested - although that is an idea...), but to reflect a wider idea that software and exploits need to be kept fresh. Yes, there are other ways of reflecting this and yes it may not be the most technically accurate way of doing it, but it is a fast and dirty way of achieving the same thing. Mostly it's there for storytelling purposes. My feeling is that we are going round in circles with this particular point and I suggest we just accept we have different views and let the thread run on with other matters. As to your language use, your social circle clearly know you and you them well enough to be comfortable with a certail level of.... abruptness. I, on the other hand, do not know you. There is, of course, the built in limitations of the medium to consider too. Comments that passed face to face can be recieved very differently when typed. G.

I ressurect this thread, because I would like you to write all hacking combo with other skills/gear you like/know. Decivre wrote something about that:

Decivre wrote:

One thing I would recommend is not to make pure hacker characters. They tend to be boring. Instead, it's best to mix hacking skills with another skillset that complements it. Combining pilot skills and other SOM and REF skills with your hacking skills can allow your hacker to pilot drones in combat, and he can do so and participate in combat through his drones while still hacking. If you go for social skills, your character can be a subtle hacker, one who can break into someone's mesh inserts while spending time with them, utilizing their social skills for that opportunity. Social skills combined with hacking skills also reflect a common hacker motif in real life, as many of the greatest hackers were also expert social engineers who "hacked" people's trust as well as their systems (Kevin Mitnick immediately comes to mind). If you go with infiltration skills, you come off as the classic computer spy, who can sneak into facilities and get close enough to computer systems which are otherwise inaccessible. Lastly, a personal favorite is to combine hacking with unarmed combat. With an opportunity for direct physical combat, a hacker gains the means to hack into things he would not normally be able to do wirelessly... like, say, a cyberarm. Hint for the last one: purchase skinlink, a disabler (page 316), and either shock gloves or eelware. You'll thank me for that advice. In short, the best way to make hacking fun is to combine it with other skills. Most skill-based games are designed in such a way that characters with one trick are generally bland, anyways.

But you didn't explain details about this combos, so pls, write something more. I am looking for something like that. Thx.

Most people can not battle-hack, but infomorphs in ghostrider modules or people with multiple personality programs that allow them to perform mental actions could probably hack into an opponent's battlenet. In a world with sensors that can provide data on a whole battlefield, going autistic turns you into a proverbial dinosaur, while your opponents are using sensors that see through walls and constantly receiving a data stream on where you, and they, are at all times. They are in constant, silent communication with their allies and their weapons. And then there's the whole "Ordering around automated drones" thing. While you're giving hand gestures, the ally you're waving at gets a bullet through the brain, fired through a wall by a sniper half a mile away, because they have telemetry while you don't. Battle hacking is an extremely important thing to have. Hand gestures are still important, of course, but never discount the potency of information control.

Anyone running a tacnet will also be running crypto. Unless you have the keys for that, you're looking at a base time of 1 week on a quantum computer to crack it, before you can even start hacking.

Yeah. It completely kills GITS-style combat hacking in its tracks.

LostProxy wrote:

Only if you're aiming for the traffic itself. If you hack into a device directly then you can access the data streaming through it.

If they leave their devices open to non-encrypted traffic and access, sure. But that's pretty slack operating procedure, unless you absolutely have to interface with something in your surroundings.

The Doctor wrote:

Smokeskin wrote:

If they leave their devices open to non-encrypted traffic and access, sure. But that's pretty slack operating procedure, unless you absolutely have to interface with something in your surroundings.

Cryptographically secured connections do not mean that someone cannot connect (unless multi-factor authentication is used), only that the connection's traffic cannot be understood by eavesdroppers. That does not mean that someone cannot try to brute-force login credentials, exploit subtle bugs in the cryptosystem to suss out some bits of the key, or exploit a vulnerability in the login service. To put it another way, people try to brute-force SSH logins all the time (approximately 6,042 times on one of my machines this month alone).

I don't see how multi-factor authentication would make a difference to this sort of hacking. It only helps against social engineering and stuff like that. Only a mathemathical ID tool would matter, and those are no different from crypto, which you imply can be bypassed. Assuming you could log on, it wouldn't do an intruder any good without the key - anything sent or received would be gibberish since accounts would be set up for only crypto comms. Maybe the GM could allow a Hidden intruder to do stuff without a key since that is a backdoor access.. A sensible security approach would be to apply crypto to more than simply the data contents, like anything but the recipient and sender IDs. You could still brute force it though you'd have to guess a lot more than just login credentials, but even if that succeeded even a backdoor access would suffer from lack of a key, unless the GM allows for vulnerabilities in the crypto software, which the rules as written leave no option of. If the team is running stealthed signals, transmitting anything to them becomes impossible as the hacker won't know the channel hopping and modulation sequences.

Smokeskin wrote:

I don't see how multi-factor authentication would make a difference to this sort of hacking. It only helps against social engineering and stuff like that. Only a mathemathical ID tool would matter, and those are no different from crypto, which you imply can be bypassed.

Do not mistake a cryptographically secure connection for cryptographically strong authentication to an account on a machine. One can use SSH to contact a machine, but that is not the same as gaining access to an account, that requires authenticating to the system. If the passphrase on the account is weak encryption only hides the content of the traffic in transit. Multi-factor authentication would use a cryptographic module of some kind on either side containing pre-exchanged certificates, or something along the lines of a one-time pad (think RSA token) that, in addition to a username and passphrase would be required to access an account. Brute forcing a username is relatively easy; a password less so and multiple passwords even less so. To put it in EP terms, it would be possible for a mesh hacker to initiate a connection to a device over an encrypted channel, but that would not prevent them from trying to brute-force access to an account (unless stronger measures were taken, which would translate to a difficulty penalty on the die roll). Or you could just throw it at the player if they get a string of bad Infosec rolls.

Quote:

Assuming you could log on, it wouldn't do an intruder any good without the key - anything sent or received would be gibberish since accounts would be set up for only crypto comms. Maybe the GM could allow a Hidden intruder to do stuff without a key since that is a backdoor access..

Logging on is not the same as opening a connection. That would indeed be a possibility (at an even higher die roll penalty) for a more strongly secured system - rather than the sides of the connection randomly (for certain values of 'random') agreeing on session keys, to get a valid connection both sides would have to use pre-agreed upon crypto keys for a session.

Quote:

A sensible security approach would be to apply crypto to more than simply the data contents, like anything but the recipient and sender IDs.

Remember that the data would still have to be decrypted to be used by a running system.

Quote:

You could still brute force it though you'd have to guess a lot more than just login credentials, but even if that succeeded even a backdoor access would suffer from lack of a key, unless the GM allows for vulnerabilities in the crypto software, which the rules as written leave no option of.

Or something like compromising the crypto software itself - difficult but possible. I would give the player an Infosec roll with another penalty to see if they could inject a backdoor into the crypto software itself when setting up a backdoor.

Quote:

If the team is running stealthed signals, transmitting anything to them becomes impossible as the hacker won't know the channel hopping and modulation sequences.

That is a different matter from cryptography in itself.

Smokeskin wrote:

Sounds like we agree that combat hacking against a team that takes measures to protect their comms is next to impossible.

At serious penalties on the dice rolls, yes. Players could also take the same measures to make their communications less likely to be infiltrated.

Arenamontanus wrote:

In real security the issue is usually when these measures fail. That squad member who opens a VPN channel to her favourite music site; the unprotected port on that ammo clip you can dump malware into; the use of the old version of the open source targeting lidar routine that can be infiltrated by shimmering the right packets back as an IR echo...

Just as no strategy of war ever survives its first contact with the enemy, no system security plan ever survives first contact with the users. Do not forget disabling automatic firmware updates, viruses hiding in file metadata, unauthorized software being installed in a hardsuit's battle computer ("What do you mean, you're running BitTorrent over our tacnet?!"), and corrupted external storage media getting plugged into just about everything with a matching jack.

CYBER78 wrote:

but extra speed can reduce the time of task action for hacking ?

Frankly, I'd be more interested about the possibility of running an infomorph in an accelerated state/VR and trying to hack durig the combat the enemy's net... But yeah, extra actions make the hacking quicker, because you can make a roll per action, and more actions per turn means less actual time needed to accomplish the task.

no one can help to solve this dub ? how did you make your hacking sequence , send some example.... bye bye

GJD wrote:

Why can I use some powerful exploit a single time, then save it for years without anyone ever getting the bright mind to patch the flaw that it exploits, simply because I only used it once? Did they magically all forgive me? Assume "eh, it only happened once. It's not like we actually need to patch a problem, right?" Did no one else in the whole system find the flaw that I found? I was simply being honest about finding the idea flawed.

There is ample real-world precedent for this, incidentally. Also, many compromises are never reported or even really researched (the "nuke and pave" philosophy of defensive IT), or even detected (sound like any CAs recently?)

GJD wrote:

There are several ways you could reflect this in the game. You could model that by: 1. Arbitrarily saying an exploit only works for a month or two.

I would add, on a natural 99 the exploit was discovered and patched, hence, why it set off every alarm on the sector's mesh.

GJD wrote:

3. Each exploit a set number of uses. 4. Each exploit a random but unknown to the player set of uses

Ouch. Crippleware 'sploits.

GJD wrote:

These are just a few ways i came up with, there are undoubtedly loads more. All of these are abstractions to a greater or lesser degree of my core requirement: a hacking method, be that using a certain piece of software or a certain exploit, won't last forever. The choice of which method I choose to use is based on how much abstraction I want and am prepared to accept. All of them can achieve the aim of reflecting that.

The cost of finding new vulnerabilities and updating one's cracking software might also be rolled into the downtime bits covered by monthly lifestyle costs.

Smokeskin wrote:

Sounds like we agree that combat hacking against a team that takes measures to protect their comms is next to impossible.

I would say "very difficult," with penalties of -20 to -50 depending on how disciplined the other team is. Remember, in Eclipse Phase military sysadmins could possibly get away with using BOFH tactics against recalcitrant team members for screwing things up because the team member in question could always be resleeved.