Return to “Suggestions”

Post

Re: An Investigation Into Hacking

#46
BFett wrote: Class 2: Data is password protected and a monitor program is installed on the system.
Class 3: Data is password protected, a monitor program and firewall are installed on the system.
why in that order?

why should i get a system that allows me to track intruders before i get a system that prevents intruders in the first place?

in first instance you dont care who has done it, you want them not to do it in the first place.


whats the difference between log files' sensor data (about a newly discovered wormhole) and "normal" files' scanner data?


i'd also probably roll map and location data into its own file type, its likely to be exchanged often and being of major interest for hackers.

same for stock and cargo collections

so the collection of data types would be
  • Log files: What has the ship done/experienced in the last time. (discovered x, fought y, links to map data)
  • System data: What is the status of the ship. (energy status, current sensor readings, currently running programs)
  • Map data: What things existence does the ship know of and where those things are. (links to system and cargo data files for known objects)
  • Cargo Data: What the ship has in its cargo bay and desired changes of that state (Cargo and buy and sell info)
  • Miscellaneous: whatever doesnt fit into the other categories; boot files for programs, blueprints, etc

and last but not least: how does hacking actually work?
how does the player interact with Password protection, tracer programs, guard programms, firewalls?

what does the player do when hacking?
Post

Re: An Investigation Into Hacking

#47
Cornflakes_91 wrote:
BFett wrote: Class 2: Data is password protected and a monitor program is installed on the system.
Class 3: Data is password protected, a monitor program and firewall are installed on the system.
why in that order?

why should i get a system that allows me to track intruders before i get a system that prevents intruders in the first place?
The monitor is a cheaper solution to fending off hackers than installing both the monitor and the firewall. A firewall will prolong the time it takes for a hacker to gain access to a system but it will not necessarily discourage the hacker as quickly as a monitor may. (This is one of the parts which I am open for ideas. I may just say class 2 is a system behind a firewall or a monitor program instead of making it fixed.) Thoughts?
Cornflakes_91 wrote:in first instance you dont care who has done it, you want them not to do it in the first place.
This is true, this is why I think by having the monitor as the most basic defense is important to keeping a system secure. We don't want a hacker to have all day to hack the password to your ship.
Cornflakes_91 wrote:whats the difference between log files' sensor data (about a newly discovered wormhole) and "normal" files' scanner data?
Log files just state what has occurred. For example "object scanned at location X" would be in a log file while the actual data (the wave lengths the object was scanned on) would be in a normal file. Normal files contain much more detailed data than the simple log files.
Cornflakes_91 wrote:i'd also probably roll map and location data into its own file type, its likely to be exchanged often and being of major interest for hackers.

same for stock and cargo collections

so the collection of data types would be
  • Log files: What has the ship done/experienced in the last time. (discovered x, fought y, links to map data)
  • System data: What is the status of the ship. (energy status, current sensor readings, currently running programs)
  • Map data: What things existence does the ship know of and where those things are. (links to system and cargo data files for known objects)
  • Cargo Data: What the ship has in its cargo bay and desired changes of that state (Cargo and buy and sell info)
  • Miscellaneous: whatever doesnt fit into the other categories; boot files for programs, blueprints, etc
That's an interesting breakdown for 'normal files'. Personally I'd put map data under the 'normal files' header along with the ship's current cargo data. The cargo buy and sell data might fit in under 'normal files' also until it is acted upon, in which case the transfers would be logged in the log files.
Cornflakes_91 wrote:and last but not least: how does hacking actually work?
how does the player interact with Password protection, tracer programs, guard programs, firewalls?

what does the player do when hacking?
The player would initiate a hack by entering the hacking interface which would display all ships, stations and colonies within a defined region of space (Probably dependent on the sensors of the player's ship, proxy connections ect. [insert technobable here]). The player would then connect through various proxies until ending at their target. They would then scan the network looking for firewalls, monitor systems, and proxy servers which are defending the system. The hacker would then disable or bypass the defense systems with the appropriate programs (exact details to be worked out). If a monitor bypass or disabling program is not available the monitor will detect the intrusion at this point and begin tracing the hacker. The hacker now has limited time to have the password decoding program finish its job, allowing access to log files and normal files. As time ticks down the hacker does as much damage as possible, as quickly as possible and then disconnects from the system before the trace completes. Note that if the firewall and or proxy were not bypassed the hacker would only be able to view the files without access to coping, modifying or deleting them. In order to access the system files the hacker would have to enter a terminal and navigate the text interface using some generic commands.
Image
Post

Re: An Investigation Into Hacking

#48
BFett wrote: The monitor is a cheaper solution to fending off hackers than installing both the monitor and the firewall. A firewall will prolong the time it takes for a hacker to gain access to a system but it will not necessarily discourage the hacker as quickly as a monitor may. (This is one of the parts which I am open for ideas. I may just say class 2 is a system behind a firewall or a monitor program instead of making it fixed.) Thoughts?
so you have only a facial-recognition-capable automatic camera system in your house and no doorlock because the camera system plus doorlock are more expensive? :roll:

i'd say that firewalls completely prevent access if the attacker doesnt have some approbiately stronger way of attacking or a weakpoint somewhere else in the system
to get, for example, into a properly firewalled network you'd either have to have a strong firewall breaker or search out a ship thats part of that network with a weak firewall you can penetrate.
BFett wrote:
Cornflakes_91 wrote:in first instance you dont care who has done it, you want them not to do it in the first place.
This is true, this is why I think by having the monitor as the most basic defense is important to keeping a system secure. We don't want a hacker to have all day to hack the password to your ship.
why should the hacker care for a tracing program?
"so, eh, yeah, i know that this ship on the other side of the sector has done it, by the time im back at him to do something he's away"
BFett wrote: That's an interesting breakdown for 'normal files'. Personally I'd put map data under the 'normal files' header along with the ship's current cargo data. The cargo buy and sell data might fit in under 'normal files' also until it is acted upon, in which case the transfers would be logged in the log files.
why?

cargo and map data are much more direcly game relevant than log data, though log data gets its own data type and map/cargo not?

map and cargo data are highly interesting for most parts of the game, so they would make sense being coupled out from the general "everything else" heap you'd have to sift through otherwise.

BFett wrote: Note that if the firewall and or proxy were not bypassed the hacker would only be able to view the files without access to coping, modifying or deleting them.
weird firewall you have, mine doesnt let anything through when its not open :roll:

why should the hacker be able to read my data even though he didnt get into my system?

and if he can read files, he can copy them, because in order to read them he has to transfer them to his own computer where he can intercept and store them :P

BFett wrote: In order to access the system files the hacker would have to enter a terminal and navigate the text interface using some generic commands.

looks forced to me, especially coupled with the fact that theres already a generic way to read files, else the player couldnt read his own files either

so, why a command line tool?

what would it give that justifies the time needed to implement a system that looks like a real command line?
why arent GUI tools suffecient, like everywhere else in the game ?
Post

Re: An Investigation Into Hacking

#49
BFett, it sounds like you want to play Hacknet (33% off it's normal $10 right now). Go do so. Despite its gamified simplicity, it is actually a respectably accurate imitation of hacking, and it's quite fun.

But I don't think a Hacking minigame is the right thing to add into a game about trading and blowing ships up. The application of force in this game is done via guns. It's very difficult to balance completely different games encapsulated in the same framework... hacking would be too easy, or too hard, relative to just shooting. If it was too easy, gamers who just want to shoot would be annoyed that the 'best' way to play was not fun. If it was too hard everyone would complain that all this time was taken to create a system that is pointless because shooting things is easier.
Post

Re: An Investigation Into Hacking

#50
MyrddinE wrote: But I don't think a Hacking minigame is the right thing to add into a game about trading and blowing ships up. The application of force in this game is done via guns. It's very difficult to balance completely different games encapsulated in the same framework... hacking would be too easy, or too hard, relative to just shooting. If it was too easy, gamers who just want to shoot would be annoyed that the 'best' way to play was not fun. If it was too hard everyone would complain that all this time was taken to create a system that is pointless because shooting things is easier.
errr, that assumes that hacking is used to fight ships directly.

hacking can do many things that just shooting at cant ever archieve

finding that base you'd never have found otherwise by taking a scout's computer apart.

stealing that cache of mineral scan data and selling it.

expanding your sensor network through your concurrent's ones by planting a ton of troyans in his systems.


long story short: many things you couldnt do with just shooting.

its not stronger or weaker, its something completely different.

just like trading, its not better or worse but completely different.
Post

Re: An Investigation Into Hacking

#51
Cornflakes, you bring up a lot of good points, and since this is a work in progress I'll probably change my stance on some of my original ideas.

I like your comments on the firewall and it does make sense to me that the firewall would prevent all access except through particular ports which are open. If the firewall is the bolt lock for a house then the password would be the lock in the door's handle or as you put some sort of detection system ;) . I also like the idea of trying to trick a firewall by accessing a owned ship of the target vessel, and using that connection to trick the firewall into thinking that you are a user from that ship trying to gain access to the systems.

Well, a Tracer program could notify the authorities of the person who was committing the hack and mark down the ship's ID (similar to the IP address of a PC). This is an optional feature, but it would give the hacker more enemies to worry about if they were not careful in covering their tracks. Besides, this data could be logged and then used to find who the hacker has worked with, where the hacker has purchased weapons and equipment among other things. These businesses could then be notified which would force the hacker to go elsewhere to find targets of opportunity.

The main reason why I have suggested 3 file types is because it makes describing their securities on a system easier. If you think it would be better to organize the data into categories it relates to I can live with that.

I agree that my solution for system files is forced. Maybe we should just encrypt them so that the hacker can't read them without a file decrypter. What do you think? Is this a good solution or do you have another idea? I really want it difficult for a hacker to change my shields or other values which pertain directly to my ship.
Image
Post

Re: An Investigation Into Hacking

#52
BFett wrote: I like your comments on the firewall and it does make sense to me that the firewall would prevent all access except through particular ports which are open.
I'd personally say that a closed firewall is closed for a specific attack program, with no "but" in there.

So if attack program A cant get through defense B on first try it wont ever get through, regardless of the amount of time invested, but program C which works differently gets through.
BFett wrote: I agree that my solution for system files is forced. Maybe we should just encrypt them so that the hacker can't read them without a file decrypter. What do you think? Is this a good solution or do you have another idea? I really want it difficult for a hacker to change my shields or other values which pertain directly to my ship.
The "forced" was referring to the "there is a command line" but nevermind :P

I just disagree with the notion that a hacker can read my files without breaking through my firewall.

And i dont really see a reason for more layers of security, when you got into the system, you are in.

Or maybe we could go all out and include nested firewall s.
So theres an overall firewall that protects your whole ship and ihen individual firewalls for diverse subcomponents.
An extra layer for your map data, a different firewall for your system data inside that another nested layer that protects engine control etc.
So you could make it arbitarily hard to access certain parts but would have to layer many firewalls ontop of each other.
Post

Re: An Investigation Into Hacking

#53
Cornflakes_91 wrote:
BFett wrote: I like your comments on the firewall and it does make sense to me that the firewall would prevent all access except through particular ports which are open.
I'd personally say that a closed firewall is closed for a specific attack program, with no "but" in there.

So if attack program A cant get through defense B on first try it wont ever get through, regardless of the amount of time invested, but program C which works differently gets through.
This sounds good to me. It would be easier to implement this way anyways.
BFett wrote: I agree that my solution for system files is forced. Maybe we should just encrypt them so that the hacker can't read them without a file decrypter. What do you think? Is this a good solution or do you have another idea? I really want it difficult for a hacker to change my shields or other values which pertain directly to my ship.
Cornflakes_91 wrote: The "forced" was referring to the "there is a command line" but nevermind :P

I just disagree with the notion that a hacker can read my files without breaking through my firewall.

And i don't really see a reason for more layers of security, when you got into the system, you are in.

Or maybe we could go all out and include nested firewall s.
So there's an overall firewall that protects your whole ship and then individual firewalls for diverse subcomponents.
An extra layer for your map data, a different firewall for your system data inside that another nested layer that protects engine control etc.
So you could make it arbitrarily hard to access certain parts but would have to layer many firewalls on top of each other.
Sure we can do nested firewalls, with the catch being that each nested firewall is a separate program which costs x amount of credits to purchase (same as all other programs). This means the player or NPC can't use the same firewall program to secure the ship and all subfolders.
Image
Post

Re: An Investigation Into Hacking

#54
BFett wrote: Sure we can do nested firewalls, with the catch being that each nested firewall is a separate program which costs x amount of credits to purchase (same as all other programs). This means the player or NPC can't use the same firewall program to secure the ship and all subfolders.
well, they already cant use the exactly same one as programs that can break the first one also get through the other ones ;)
Post

Re: An Investigation Into Hacking

#55
Cornflakes_91 wrote:
BFett wrote: Sure we can do nested firewalls, with the catch being that each nested firewall is a separate program which costs x amount of credits to purchase (same as all other programs). This means the player or NPC can't use the same firewall program to secure the ship and all subfolders.
well, they already cant use the exactly same one as programs that can break the first one also get through the other ones ;)
Good point :thumbup: .
Image
Post

Re: An Investigation Into Hacking

#56
Still, if nesting the same firewall program was allowed, you could protect your ship simply by making it take more time to get to certain parts of the ship. If it takes a non-zero amount of time to break a firewall instance, and then it also takes that same amount of time to break the nested ones too (I'm assuming that even the same program will have a random encryption key or whatever), you could just make it take arbitrarily long to hack your engines or data- you would be able to blow up the enemy (assuming you know where they are) before they could wait for the hack to complete, or they would be kicked out when the "trace completes" as Bfett suggested. Either make the same type of firewall be instantly broken if it was already broken during the hack, which would make nesting the same firewall pointless, or make breaking into the same firewall exponentially faster for each firewall of that type you break during a hack, so that even if you had and infinite series of the nested firewall, the time to hack them all would converge to a finite number. Perhaps this could be used to determine what level the firewall is said to have- the time it takes to break an infinite number of them is the firewall's power. :geek: :lol:

Maybe the time it takes for the "trace to complete" would be dependent on how many firewalls or monitors were installed, so the more security equipment and the larger the file system protected, the more time one has to hack.

Or we limit protection by making firewall performance somewhat dependent on how much power you give it. So if you dedicate all your powerplants to the firewalls and electronic counter measure stuff, say if you have a super fancy data storage station, it takes much longer/is more difficult to hack than if you allocated less power to it, even with the same software. This makes the player think about how much they are willing to sacrifice in other parts of the ship for decent protection. Each program instance takes the same power, so you would have to have infinite power to infinitely nest, making that problem moot, and this forces the player to think carefully about what is actually important to protect. Perhaps firewalls are easier to break the more stuff they protect?

This could be extended to processing power. So you need computers to provide processing power to run programs, and those computers then need power themselves (as has been suggested elsewhere). That way, you base the performance of all the software on the power of your computers, and how much power those computers have is based on your powerplants. This gives more flexibility to the player- does all the processing power go to the targeting system, or do we use some to run the firewalls? Do we prioritize the actual equipment, like the drives and guns, or do we want to keep all the computers and software running at peak performance?

Just some thoughts.

(I just read skimmed the last two pages. I apologize if any of this was covered earlier, but I wanted to chime in, even though I am crunched for time. :thumbup: )
Libertas per Technica
Post

Re: An Investigation Into Hacking

#57
Thanks for taking the time to post your thoughts on the hacking idea I presented Graf. I really like the points you brought up and I think they will help flesh out the idea.

So, for simplicity, we probably should assume that all programs take the same amount of CPU power. Maybe have it so that the physical size of each program on the ship's hard-drive is the varying factor. This would mean that faster CPUs relate directly to how many (and how fast) programs run simultaneously on a computer. While the hard-drive would relate directly to how many programs can fit on the computer (storage space).

I think we could just make it so that the same type of firewall can't be ran in multiple instances on the same computer. It simplifies things and prevents nested firewalls.

I think we touched on "trace to complete" previously, but in case I didn't here's my thoughts on it. The moment a monitor identifies suspicious activity on its computer system it begins looking for the origin of the attack. Once the origin has been located the entry port is reset which results in the hacker being disconnected from the hacked computer. So, "trace to complete" is what the monitor on the defending system is trying to achieve. I would say that its speed depends on the defender's CPU and how much power is allocated to the monitor.

From the Hacker's perspective, firewalls and password prompts are probably going to be what extends the time to complete the hack. Encryption on files could be another thing that slows hackers down. It all depends on the quality of the software defending the target computer and the speed of CPU.



How does this sound? Does it make sense?
Image
Post

Re: An Investigation Into Hacking

#58
While I love the depth in this thread, i'm not sure how practical some of these ideas are CPU wise. You're looking at a different way of playing that all the AI need to have an understanding of as well, and frankly the complexity of some of these would be difficult for many people, let alone hundreds of AI on a 2.5GHz processor (remember, LT is supposed to work on older computers as well).

That said, I do like the concept of Passwords, Firewalls, tracing, and trojans, and have my own simplified suggestion.
Monitor & Tracing

Tracing is actually tracing is actually the simplest of my suggestions. Once a hacking attempt is detected a timer begins, when it his 0, you learn the name of who is hacking you. The more advanced your monitor is, the less time it takes. A low end monitor may take 5 minutes, while a very high end one may take 5 seconds.

Monitors are also very simple, they detect trojans. How well they detect them is described in the section on trojans.
Passwords

Passwords are not actually passwords, but instead are a random 6 digit number between 000,001 and 999,999 (the player can of course pick their passwords). Password crackers start with a random # and simply go through this range of numbers in ascending or descending order. Remember that information is physical in LT, so every password cracker is a physical object. We can give these crackers an market ID by using the number the cracker starts with and whether it goes in ascending or descending order (1,999,998 variations). Example A123456 or D234567. The number it starts on is chosen at random upon creation.

Password crackers can be improved upon in 2 ways: speed, and how many numbers they can go through before being detected by a monitor. Some crackers can only go through 10 numbers a second while others can go through 1000, and if you research long enough, you can get one that goes through all 999,999 in a single second. The other is also self explanatory in that it can guess at a given number of passwords before it is detected. Any given basic password cracker is worth just as much as any other, but it's these 2 modifications which determines the market value of a cracker.

Naming conventions for human readers would also be simple, just put the speed and evasion numbers in the name to get things like A567890-350-25010. This makes it plain that the cracker starts at #567890, goes through the range at 350 numbers/second in an ascending order and wont be detected by a monitor for the first 25,000 tries (~70 seconds). Does 47 minutes of trying to crack a password sound fun? no. So just throw 2, 3, 10, 100 different crackers at a given password to increase your speed. This is also really easy to generalize for LOD. For memory's sake it's probably wise to simply make the password the same for all password protected data the owner has rather than giving a unique password to every piece of information, passwords would just need to change every so often (or when breached). The AI would password protect any information they deem important. The question remains though, why not password protect all your information? simple, if it's password protected, you can't give it away until you remove the password.

But before you get to the password at all, you need to get through any Firewalls. And after the password, you might have to deal with Encryption.
Firewalls & Encryption

Firewalls work in a similar fashion to passwords. Firewalls are just 4 digits of the alphabet, going from AAAA-ZZZZ (456,976 combinations). Firewalls are tied to each AI and their assets, it is a basic property of the way the Engine handles an NPC AI. Every player gets a random Firewall combo upon creation, and it sticks with them until it's breached and information is hacked, then a new random one is assigned to them. As long as they have not put their information in public like on the market, it remains within their firewall. If they sell their information, it goes into the new owner's firewall. Encryption is exactly like a firewall, except it is an Object which can be attached to a piece of information.

Firewall breachers also function much like Password crackers in that they are just a key to that firewall lock. Firewall breachers are created with a single random combo that they can unlock. They don't become more powerful with research, instead they become less likely to break...But first how are they improved?
Unlike password crackers, which become better with research, breakers become more powerful with work. Remember how LT creates workers to do labor more effectively and efficiently? Well breachers are a kind of labor that "hackers" can work on. When you put hackers to work, you slowly expand your breacher's combo.

For Example, your hackers work on your breacher [G/D/N/J], they can expand 1,2,3, or all 4 digits (with decreasing likelihood). Lets say they expand 2 digits by 1, your breacher is now [G/D:E/N/I:J]. Meaning you can not only get into GDNJ, but also GENJ and GDNI. Now your hackers expand 3 digits by 2, so your breacher is now [G:I/D:E/M:O/I:L]. You can now breach HEOK and IDNL and all the other combinations. The better your hackers, the more likely they can expand all 4 digits and the more likely they will expand it by greater amounts. With a bunch of high quality hackers, you can rapidly expand the breacher to [A:Z/A:Z/A:Z/A:Z] and get into any and all firewalls.

But back to the research making them less likely to break. If breachers can't break, it wont take long for a whole bunch of people to get ones that can get into any firewall. So, every time you attempt to use a breacher, there is a chance that it's range will decrease... Going back to the example above, if you use your [G:I/D:E/M:O/I:L] breacher, and you don't get in, it could shrink to [G:I/D:E/M:O/I:K], you just lost the ability to get into any firewall where the last digit is L. If of course the range of any of your 4 digits is eliminated, the whole thing becomes junk. Research makes this less likely to happen.

Breachers experience a high likelihood of breaking if you try to use it and none of the combinations fit, but even if you do get in, they may still break. Research is straight forward, You can harden a random digit individually, you can harden all digits to a lesser degree against a wrong entry, and you can research all digits to a lesser degree against a correct entry. What will result is still a breacher that begins with a random combination that needs extensive work to be statistically useful, but a hardened breacher will allow you many more attempts at breaching someone's firewall before it breaks.

Regarding Breachers and Encryption, since they are both objects with a random combo, until you put hackers to work on the object or attach it to a piece of information, they are the exact same thing.
Trojans

Trojans are like encryption, in that they are an object which you attach to a piece of information. What they do is rather simple. They negate the firewall, and also have a chance to negate the password, they even have a miniscule chance of negating encryption. To use a trojan, simply attach it to a piece of information and give that information to someone else. Unless the trojan is discovered, you have no need to use encryption against that NPC, if they hand that information to someone else, the same rule applies. Research on trojans affects the chance it will negate the password, the chance it will negate encrypted information, and the chance of discovery. The first two are self-explanatory, but discovery chance is a bit different.

Trojans are by their nature a game of cat and mouse. Every time a trojan changes ownership, it has a chance of being discovered, if it isn't discovered now, it may be discovered later. Research on trojans begins with a 50% chance of discovery, and is ideally lowered to as close to 0% as possible. Monitors simply multiply that % until you get to 100.

Example, if you own 0 monitors, you will never detect a trojan (Be safe, wear a condom). If you own 1 monitor, then your chance of discovering a trojan is the % chance it was researched to. If you have 2 monitors, and the trojan has a 50% chance of discovery, you have a 100% chance of discovering it. if 10%, you have a 20% chance. If you have 12 monitors, and the trojan has 2.5% chance, you have a 30% chance of discovering it. if you have 100 monitors, you'll discover all but the very best trojans. As i said, it faces a chance of discovery when it first comes into your possession, but the same equation is run every time you acquire a new monitor.

What happens when you discover a trojan, well it deletes the piece of information, and tells you who attached it to that piece of information with the same %chance as the number of monitors you have, and will always tell you who gave you that infected information. Making / transferring trojans is a risky business, because it can piss off the rich and powerful. It also adds a new danger to any would-be information brokers... Just handing off infected information will get the person mad at you, even if you didn't create it, or knew it existed.
TL;DR

It's a lot of words to explain a simple idea: Static 4-letter-combo lock is your firewall - Behind that is a 6 digit password for all important info - Behind that is a 4-letter-combo attachable encryption for any very important info. ||Trojans negate firewalls and possibly passwords, monitors detect trojans.
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can
Post

Re: An Investigation Into Hacking

#59
That's a much more workable idea Hyperion. I still think it's an inappropriate amount of complexity to add to LT, but it implements hacking in a workable way.

I would simplify it somewhat though... for example, why should the user care what number the cracker starts at? All they care about is the median time a cracker takes to discover the password, and the median time before being discovered. We can implement it as numbers or something simple behind the scenes, but it's only the effects that should be displayed to the customer. I'm aware that smart selection of which number to start at and which direction to travel can guarantee shorter time to cracking, but that kind of tedium (hunting for a cracker with specific starting numbers and directions) is unlikely to be fun.

Similarly, knowing what firewalls you can crack via letters is confusing... the user doesn't care. Better would be just knowing the percentage of firewalls you can crack. 1% of them? 5%? 80%? If there are regional variations on which letters are popular, you may have variations like 'Can crack 40% of Blorf firewalls, but only 2% of Fleep firewalls'. If you implement it as letter ranges behind the scenes that's fine, but the resulting percentage is all that should be shown to the user. At most the user should be able to encourage the hackers to work on letters common to a particular region.

I also disagree with how you describe balance and research for firewalls. Instead, I recommend that you have a limited 'count' of letters you can crack. Say, a cheap firewall can only know 5 letters per slot, resulting in a mere 0.2 * 0.2 * 0.2 * 0.2 chance of opening any random firewall (0.16%). But as you sic your firewall hackers on the problem, they shift which letters the tool 'knows'. Given time, they can hunt for matching letters in all four slots. Just like passwords, given time the hackers will be able to break any firewall, but they lose the ability to crack other firewalls as they only have a limited count of letters they have access to in each slot... changing the letters migrates other letters out.

Better breachers will expand the available letters (13 letters becomes 0.5 * 0.5 * 0.5 * 0.5 = 6.25% chance on a random firewall, and maybe 50% after you have focused the letters to the ones popular in your current region). Better hackers will increase how fast they migrate the letters, and how likely they are to alert the target every time they test a new combination against the enemy firewall or penetrate a firewall with a working combination.

TL/DR: Nice idea, still too complex, simplify the UI shown to the user, and make firewalls more useful and interesting by introducing regional variation allowing specialization.
Post

Re: An Investigation Into Hacking

#60
OR... OR!

We steal the system from Uplink: Hacker Elite
Each "PC" on a network has a function, and if you hack it, you can control that function.

When attacking the system it will take some time before the enemy notices, at which point thats red flags and hostile action.

Each action doesnt even pretend to simulate real actions, instead we simply compare the quality (and other values) between the hacking program, and the defensive structure.
Then a timer starts based on that result.

Once you have hacked a ship entirely you can capture it, but that takes a long time, and requires you to not die, and to not get hacked back, and to not destroy the target.


Ships specialized in hacking would become quite strong against individual targets, and very useful in larger combat situations to cause havoc with the capital ships.
Imagine hacking a carrier during combat and preventing the enemy from landing and rearming/repairing their fighters!


With this approach computer modules of the different parts becomes yet another feature of the production and research system, where players will want to buy weapons and ships with high computer stats to protect them from being hacked
But where you could tradeoff some of that protection when you arent expecting to see a lot of hackers out there.

This should all be automated to both make the focus on spaceships still, and to leave the feeling that computers are way powerful and basically magic :V
(in a way a hacking system like this *IS* a form of magic)
°˖◝(ಠ‸ಠ)◜˖°
Toba - A Development Dump

Online Now

Users browsing this forum: No registered users and 1 guest

cron