17

Now, I don't want to learn hacking (but if I learn some I learn some), but I am writing a cyberpunk story so I need to have some idea what's going on. And, maybe how I can use VR to make it more interesting to the readers. I don't mind complex explanations, I really just need something I can understand. Also, there are going to be networks separate from the massive internet providers. So, the character will have use wifi or cables at say an office that only has LAN (local area network) to get in. Honestly, most of this stuff is over my head.

19
  • 1
    Unless you’re asking us to come up with a cyberpunk method by which you don’t have to explain real world hacking (which is a bit unfocused) I think this is a better fit with writing.se
    – Joe Bloggs
    Jun 30 at 15:01
  • 6
    It is not a dumb question. It just falls in the crack between three different stack exchange forums (maybe more). Worldbuilding, Writing, Networking, Security... and the list goes on. Also, programmer's aren't necessarily knowledgeable on these matters. You might be better off finding a network security specialist or a white hat hacker. Jun 30 at 19:38
  • 1
    Regarding your "isolated network"... The hacker need not be present if, say, the entire network is not in a Faraday cage and a transceiver device is placed (by person, drone, etc.) to give the hacker easier access. I.e., the hacker could create remote access. Even if the transceiver wouldn't work, the hacker might pwn a worker's smartphone that could "run scripts", etc., when the worker is in range of the isolated network. No useful isolated network is completely isolated - the intended users have access.
    – rickhg12hs
    Jul 1 at 10:09
  • 1
    If you want to know what real hacking sounds like... read "The Cuckoo's Egg". It's a true story about a guy realizing there's a hacker in MIT's system and his quest to isolate and remove said hacker. It's fairly good with including technical details but probably also readable if you don't get any of it. It's probably not what you actually want, but I'm putting it here for interest's sake. Jul 1 at 19:22
  • 3
    Do you want to make it realistic (as in "hacker searches for vulnerabilities, then eventually finds one and exploits it"), fantastical (as in "hacker writes a virus so powerful it can punch through any firewall in under 45 minutes"), or something in between? Jul 1 at 21:37

11 Answers 11

22

Start with the works of other cyberpunk authors, specifically the father of the genre, William Gibson. Neuromancer and Burning Chrome are a little dated, but in a backwards kind of way. They are set far enough in the future that their cyberspace is more advance than what currently exists. Some of the ideas, like black ice, aren't possible yet (I hope) but as an author describing future hacking, few compare to Gibson.

Read those works with your "author eyes" and with a highlighter in hand. Make note of the metaphors that Gibson uses to describe navigation through cyberspace and the protagonist's attacks on system defenses. Notice that he doesn't try to describe the techniques but instead treats them as black boxes, dangerous sounding tools used by an expert who doesn't think about how they work any more than you think about how a word is spelled as you type it onto a page. Once anyone is fluent enough with a tool set, the details of how they are used fade from conscious thought.

As I mentioned before, black ice is probably off the table unless your story included direct brain/computer interfaces. In the absence of such an interface, the danger posed towards the hacker is less mortal but no less serious. Being detected, traced back to current location and either identified or counter-attacked are the risks faced by current day hackers in the real world. Those risks are what your character is going to be thinking about while they hack, not how their well-worn tools are doing whatever it is they do.

8
  • 16
    Gibson notoriously had little experience with computers before writing, and was actually quite disappointed in computers once he had a chance to work with them.
    – DWKraus
    Jun 30 at 21:13
  • 1
    That's the comment of the day right there.
    – Clair
    Jun 30 at 21:17
  • 1
    Thanks @DWKraus! I didn't know that about Gibson and although at first it sounds like you invalidated my answer, you really drove my point home. Gibson may have not known how the dangerous tools that his characters used actually worked, even theoretically. With care and craft, an author can work around their own ignorance... within limits. Jun 30 at 21:33
  • 2
    Do this only if you want your work to show up on a video like "real <x> reviews <y>"...which involves the person who really does those things snorting water out of their nose laughing at how implausible/crazy it is. Most of Gibson reads more like fantasy than sci-fi to anyone who knows a bit about technology. (Although it's not a bad read, it's just zero realism. It resembles real computer work in the same way that superhero fights resemble real martial arts.) Jul 1 at 13:01
  • 3
    I agree with most, except for the "black box" thing. All the actual hackers I know personally very much think about the low-level details that everyone else ignores. That's a large part of what makes them hackers. You see an online shopping site. They see a bunch of protocols, data flows, interfaces and potential weak spots.
    – Tom
    Jul 1 at 15:51
18

I've been working in Cybersecurity for 20+ years, and while I'm not a penetration tester (aka "white hat hacker") myself, I have worked closely with those for many, many projects.

Real-world hacking rarely makes for a good story. There are a few amazing stories that I can't tell (NDAs and that), but they are rare, and most of the job is repetitive and, to be honest, you mostly collect low-hanging fruits because most companies have shitty security.

From an attacker / cyber-criminal perspective, most books want to tell us about the great and rare hack, but most attackers are spending a considerable amount of their time on scouting out the easy targets. Because they're also the least likely ones to get you caught.

If you want to bring some amount of real-world into your story, here are some of the top things that I often miss in movies or books that include hacking:

  1. Research. Watch the old "War Games" movie, that got it right. If you are after a specific target, you find out anything you can about that target. On a grander scale, you will try to infiltrate them, get documents, paperwork, talk to people who worked for them - every piece of information can point to a potential weak spot.

  2. The tools. Every hacker I know has a toolset. A collection of both publicly available tools such as vulnerability scanners and private tools (from the black market or self-made). Tools are important. Watch the "Swordfish" movie for how it's NOT done - you don't crack an encryption by hand. Even if it is crackable, without your toolset you'd be fucked. Read up on 0-days and how they are made and traded.

  3. Systems view. Modern IT isn't one server on the Internet you're trying to break into. There are networks within networks, channels upon channels, dozens of locations around the world, connected via VPNs, talking to backend systems, clusters spread around - an attacker thinks of the whole system and looks for the weak spot. The forgotten old system that's on the same network. The backup system, the admin network, the network-connected printer in the lobby...

8
  • 5
    Also, the fact that the vast majority of hacks rely on human factor (phishing) is often omitted. It's not that intense when a huge mergacorp was hacked because one of their employees opened a "report_2021.docx" attachment ;P
    – Dan M.
    Jul 1 at 15:24
  • 2
    Hacking the casino through their lobby fish tank thermometer was a pretty good story.
    – rickhg12hs
    Jul 1 at 15:32
  • 5
    @DanM. that is debatable. I find that most people who stress the human factor are the ones who sell something in that area. Hacks relying purely on tech, with no human interaction, are pretty common, both in the high-end attacks and the bottom-feeder automated crap we all see in our server logs.
    – Tom
    Jul 1 at 15:43
  • 1
    @rickhg12hs absolutely, yes. A few years ago I worked with a large insurance company and one of the projects we started was to split the office network from the "all the other crap" network (you know, the coffee makers and so on). I can totally relate to that story. :-)
    – Tom
    Jul 1 at 15:48
  • 1
    @Clair we know that governments do engage in such activities. They are hard to defend against, right up there with organized crime (let's skip the discussion about what the difference is). It's hard to defend against these threat actors, because they have more than just cyber weapons at their disposal. But as I said: Most companies aren't anywhere near where I'd discuss anti-government measures with them, they need to get their basics right first.
    – Tom
    Jul 1 at 21:53
10

"Good writers borrow, great writers steal". Real-world hackers have already found ways to solve this problem so just copy them. They've already solved the problem of presenting the often mind-numbingly boring topic of hacking in an interesting and engaging way. So I recommend that you learn a bit about hacking - not from a textbook, but from something entertaining - and along the way you can figure out how to use their stories and oratory techniques in your story.

  1. This is ten minutes of interesting hacking anecdotes about breaking and entering. The first thirty minutes is about the tools that you can use to bypass locks. I and 2.5 million other people think it's interesting to hear about high-tech security bypassed by dumb and simple tricks. For example, did you know you can legally buy the keys to most police cars on the Internet?

  2. This talk shows more conventional computer hacking. What's more important to writing is the title of the talk: "I Will Kill You & Birth You". What does that mean and how do you do it? I'll let you learn for yourself but the take away is that your readers are curious and they'll be willing to sit through something that's less interesting if there's a good set up and pay off. Chris Rock's other talk "How to Overthrow a Government" is another good example.

  3. "Ghost in the Wires: My Adventures as the World's Most Wanted Hacker" by Kevin Mitnick and William L. Simon. This book is the biography of one of the most successful hackers of all time. I can't condense the writing tricks used in an entire book but this will give you great insight into the hacker mindset. Most of Kevin's exploits were achieved by cleverness and a good understanding of social dynamics, not programming. The take away is that hackers aren't necessarily smarter or more knowledgeable, it's that they have the right skills and right knowledge to avoid others' defenses. Also it's a compelling read. Who wouldn't want to hear about someone who was imprisoned without a phone call because he could launch nuclear missiles over the phone?

"If they think you're crude, go technical; if they think you're technical, go crude". Your character needs to break into someone's apartment. What you're proposing is that the character goes into VR, hacks into their network, and scrubs through the security footage until they see a key that they make into a CAD model which can be 3D-printed, letting them unlock the door and walk in. A hacker in a movie would pick the lock. A hacker in an action movie would climb down the side of the building and break in through the window. A hacker in the real world could knock on the front door and walk right in. Hacking isn't about using computers or advanced technology: it's about bypassing defenses in unexpected ways. So you can use sci-fi tech and/or you can pretend to be a pizza delivery guy.

I think that you'd be better off going crude rather then technical:

  1. It saves you from exposition. You might need to explain to someone the difference between a trojan and a worm, but everyone understands lying.
  2. It makes more drama. instead of having a character sit in front of a computer, they're forced into direct conflict with individual human beings with agency, motivations, and personalities.
  3. It's more relatable. Which of these sounds familiar: realizing that your target has failed to meet the basic OWASP standards, or trying to cover your ass when someone has caught you in a lie? Not only is it more relatable to your audience but it's also more relatable to you. The more real technology you mention, the more likely you are to get it wrong, i.e. the mistakes that I may or may not have left in my technical jargon.

TL;DR: Just have them use social engineering to steal the admin's post-it note with all their passwords.

11
  • This was very informative. You seem knowledgeable. So, I wanted to ask about Script kiddies. Would it be reasonable for people to buy hacking scripts? Like a hit man buying a key-script to open an electronic lock, open the door, and just walk in.
    – Clair
    Jul 1 at 17:46
  • @Clair Seems is the operative word why didn't you ask the guy who claimed to have 20+ years of experience. Meta jokes about social engineering aside this is an example of how using tech and terminology your not familiar with can bite you in the ass. Script kiddies refer to people who copy publicly available code stereotypically because their a kid with no money or skills to write software. But buying zero day exploits is a perfectly reasonable thing for someone to do. Though maybe not the way you mentioned. Jul 1 at 18:06
  • @Clair for instance a key-script sounds like a key to open a lock which doesn't make much sense for a "script kiddie" to buy. Any key is probably encrypted to the point where it would be to expensive to break it so the only way to get the key would be to find vulnerability that gave you the key either in the computer system of the place your attacking or in it employees so that they'll give you the key both of which defeat the purpose of needing a key since you could just get them to open the door. The most reasonable way I can think of getting the key is would be dumpster diving for post-its Jul 1 at 18:13
  • 1
    @Clair if you ground yourself in reality then minute technical details will bog you down its better to make up your own jargon or use low tech solutions to your problems. Making up your own terms can also make your setting themes and characters richer depending on how they use it. The vocabulary and memes that people use can show the tribes in your world. The way your characters use words and which words they use can effect our perception of them. Words can play into the central theme. A good example would be how different people use pepe and what it means in culture and to induvial. Jul 1 at 18:25
  • 2
    @Clair sorry if I came across as rude I didn't mean to be insulting. Jul 1 at 19:32
5

Social
The most successful hacking is usually at least partly social. It depends on poor human judgement as a weak point. Getting an executive in a corporation to click on a link to download and install a tool that captures passwords for you is surprisingly common.

Likewise, dressing and looking like someone who's supposed to have access to the networking closet so you can install hardware that listens in on the network for passwords and other useful tidbits transmitted in the clear can be surprisingly easy.

Dumpster Diving/Impersonating Cleaning Staff
People write down passwords all the time. It's the alternative to re-using the same memorable one all over the place. (Which is another common human failing.) Those notes get thrown out or are pasted to the keyboard tray or other ridiculously easy places to find.

Not Changing Default Passwords
It's also a very common thing to not change the default password for a piece of hardware or software's admin account. I've done penetration testing and this was often a problem. This happens with networking equipment, database servers that contain company critical data and many other places.

Tools
As others have stated, there are a lot of common tools used by ethical hackers that do security assessments as consultants as well as others. They take advantage of the above weaknesses and more and provide detailed verbage of the weaknesses suitable for pasting into a report.

Zero Day Exploits
These were also mentioned in another answer. They are bugs that are security holes that haven't been fixed yet AND have a tool written that exploits them to gain unauthorized access to computer resources. This can range from access to just a few files to complete access to a system and the ability to leverage that to access the entire company's network. The files can contain any information useful to the story.

Motives for Hacking
It used to be the case that the main point was to steal information or computer resources. Nowadays this has broadened to disrupting the business, encrypting all their data to extort money or for nation-state objectives such as destabilizing a regime or aiding a physical attack.

1
  • "Not changing default passwords" can also extend to not changing the factory code on a door lock's keypad. Jul 2 at 16:56
4

I don't think it is possible to write about "hacking" (between quotes because personally I give it a different meaning than you) in a realistic way without scaring all your readers away with (to them) incomprehensible technical details. In most cases "hackers" just exploit an existing exploit with an existing tool - super trivial. Someone who finds a NEW exploit in some application might take days to months to do so, all the while doing incomprehensible things, and using expert tools the function of which your readers don't understand either. The best you could do is write something up that isn't complete nonsense in the eyes of a computer expert (99% of the movies I saw about hacking are complete and utter beep).

I suppose the most interesting "hacks" are those that use an exploit that was deliberately added by the programmer. But such backdoors are kept secret of course; only in rare cases anyone else but the programmer will learn about it. I'll give you an example from my (distant) past, that - until now - I more or less kept secret ;). This was way back when user@hostnames were still visible on IRC. I was the main developer of the ircd of Undernet and added something to the code that allowed me to spoof an arbitrary user@hostname (by setting my RealName to something special). From the point of view of the normal user this is impossible: you connect with your IP number, that is reverse looked up and used as your hostname. So, if someone says "I can hack to look like thepresident@whitehouse.gov then that seems very impressive, because it is impossible! The point is however, it is not impressive at all: all you need to do is use the right Real Name. The only thing "impressive" about this was that this backdoor was added a way that nobody could ever find it: it ended up in the binary of the ircd without that it was in the source code. In order to do that, I needed direct shell access to where the server was compiled (and running); once you have that the rest is not impressive (I did get that access legally by the way, people trusted me with the shell access to nearly all servers that were running - so I could help them compile the servers when a new release came out).

To make a long story short: it is knowledge. Knowledge that makes things trivial and not smart or impressive at all once you have that knowledge. If you'd write about it without explaining how it is done, then it might seem like magic, but it is just a story and your readers will say: duh, that is not possible! "Yeah right, I can write a story about 'hackers' too that way", they'll say. And when you explain how it is possible then that takes away all magic and they'll say: "Boring, everyone can do that. Explain why the hacker is the only one knowing this?". That would be realistic hacking.

Like I said above, it comes down to knowledge, including a lot of technical knowledge; but you simply can't write about that (in a realistic way) because it will be over the heads of your readers. Lemme give an example of that as well... here is a paste of what I wrote on IRC yesterday while fixing a bug (and typing out my thoughts on IRC);

<CarloWood> 1027      // Paranoia check: we shouldn't be running when we're idle?!
<CarloWood> 1028      ASSERT(!sub_state_w->idle);
<CarloWood> *sigh*
<CarloWood> I'm asserting there :/... not so paranoid after all!
<CarloWood> We get there (inside begin_loop()), because multiplex() is called and inside that function keep_looping is true (therefore calling begin_loop()).
<CarloWood> keep_looping is true because need_new_run is true.
<CarloWood> Added debug output:
<CarloWood> ThreadPool04    STATEFULTASK  :   | Base state changed from bs_reset to bs_initialize; need_new_run = true [0x563ceaf9b050]
<CarloWood> ThreadPool02    COREDUMP      :   | /home/carlo/projects/aicxx/linuxviewer/linuxviewer/statefultask/AIStatefulTask.cxx:1033: AIStatefulTask::state_type AIStatefulTask::begin_loop(): Assertion `!sub_state_w->idle' failed.
<CarloWood> Oh.. different threads... both are red :/... that shouldn't happen.
<CarloWood> The last debug lines of ThreadPool02 are:
<CarloWood> ThreadPool02    BROKER        :   | Waiting for more work...
<CarloWood> ThreadPool02    STATEFULTASK  :   | Entering AIStatefulTask::wait(1) [0x563ceaf65ba0]
<CarloWood> ThreadPool02    NOTICE        :   | need_new_run = true (default)
<CarloWood> ThreadPool02    NOTICE        :   | need_new_run = true (bs_multiplex): sub_state_r->need_run = true, sub_state_r->idle = 1073741824
<CarloWood> and then the COREDUMP.
<CarloWood> So yes, we are idle (idle is 0x40000000 - non-zero), but need_new_run is set to true regardless because sub_state_r->need_run is true.
<CarloWood> Ok - need_run is set in signal(0x40000000). The only reason it can set it is because at that point is isn't idle (after resetting the 0x40000000):
<CarloWood> Code in question:
<CarloWood>     // Did this signal NOT cause us to wake up?
<CarloWood>     if (!prev_idle || sub_state_w->idle)
<CarloWood>       return false;
<CarloWood>     Dout(dc::notice, "Setting need_run to true (signal()) [" << (void*)this << "]");
<CarloWood>     sub_state_w->need_run = true;
<CarloWood> So, idle has to be zero.
<CarloWood> What is happening is unclear... but I see the following in the debug output:
<CarloWood> ThreadPool02 tries to add a task, that has to run:
<CarloWood> ThreadPool02    STATEFULTASK  :   |       | Entering AIStatefulTask::add_task_to_thread_pool(#2, 0)
<CarloWood> but
<CarloWood> ThreadPool02    WARNING       :   |       |   Threadpool queue #2 full, can not run [0x5558128ca7b0]. Slowing down parent task 0x5558128d70c0.
<CarloWood> ThreadPool02    STATEFULTASK  :   |       |   Entering AIStatefulTask::wait_AND(40000000) [0x5558128d70c0]
<CarloWood> This makes the parent task (0x5558128d70c0) idle (not running), but setting the bit 0x40000000. That is a mandatory bit, meaning that this task won't run anymore until a signal(0x40000000) is being received (which should happen when a timer expires that is started, or when queue #2 runs empty).
<CarloWood> After a lot of debug output (it was the timer that expired), the first action we see on that task is:
<CarloWood> ThreadPool04    STATEFULTASK  :   Entering AIStatefulTask::signal(40000000) [0x5558128d70c0]
<CarloWood> ThreadPool04    NOTICE        :     Setting need_run to true (signal()) [0x5558128d70c0]
<CarloWood> I don't think there was another reason to be idle, aka - that was the only bit set - so now the task is running again (idle == 0) - which means we need to call multiplex() on it; and that happens (from signal()):
<CarloWood> ThreadPool04    STATEFULTASK  :     Entering AIStatefulTask::multiplex(schedule_run, <idle>) [0x5558128d70c0]
<CarloWood> but(!)
<CarloWood> ThreadPool04    STATEFULTASK  :       Leaving because it is already being run [0x5558128d70c0]
<CarloWood> So, this call to signal changed idle from 0x40000000 to 0 and therefore set need_run and called multiplex(), which immediately returned because another thread is already running this task... I actually didn't understand how that is possible to begin with (it is idle!)... so I had an assert at the "Leaving because...", but decided yesterday to trust that this can happen and remove that assert again.
<CarloWood> The idea is now that the thread that is already running the task (aka, is inside Task::multiplex()) will pick up that need_run is set and then re-enter multiplex() from the top (which begins with a call to begin_loop()). (Re)starting at the top is the requirement when need_run is set. begin_loop() then resets need_run.
<CarloWood> ThreadPool02, that called wait_AND() above, hasn't done much in the meantime (even though a timer was set AND expired: that timer starts with a timeout of 125 microseconds, so not that weird), and that now starts to play a role again... so lets see what ThreadPool02 all did since it called wait_AND:
<CarloWood> ThreadPool02    STATEFULTASK  :   |       |   Entering AIStatefulTask::wait_AND(40000000) [0x5558128d70c0]
<CarloWood> ThreadPool02    NOTICE        :   |       |   Entering AIThreadPool::defer(#2, 0, lambda)
<CarloWood> ThreadPool02    TIMER         :   |       |     Entering Timer::start({#0, 0.000125}) [0x7f446c004c58]
<CarloWood> ThreadPool02    TIMER         :   |       |       Entering RunningTimers::push(0.000125, 0x7f446c004c58)
<CarloWood> ThreadPool02    TIMER         :   |       |         Inserting 1095268.95920015 into the queue.
<CarloWood> ThreadPool02    ACTION        :   |       |         "Timer" Action::required(1): required count 0 --> 1
<CarloWood> So, it is STILL inside AIStatefulTask::add_task_to_thread_pool (you can see that from the indentation), which called defer() and we're even still inside that function - which added the timer.
<CarloWood> next comes the call to signal() by ThreadPool04
<CarloWood> The next debug output by ThreadPool02 is then:
<CarloWood> ThreadPool02    NOTICE        :   | Requested name = "".
<CarloWood> ThreadPool02    STATEFULTASK  :   | Entering AIStatefulTask::set_state(DBusMethodCall_wait_for_lock) [0x5558128d70c0]
<CarloWood> ThreadPool02    STATEFULTASK  :   | Entering AIStatefulTask::wait(1) [0x5558128d70c0]
<CarloWood> ThreadPool02    NOTICE        :   | need_new_run = true (default) [0x5558128d70c0]
<CarloWood> ThreadPool02    NOTICE        :   | need_new_run = true (bs_multiplex): sub_state_r->need_run = true, sub_state_r->idle = 1 [0x5558128d70c0]
<CarloWood> ThreadPool02    NOTICE        :   | Setting need_run to false (top of begin_loop()) [0x5558128d70c0]
<CarloWood> ThreadPool02    COREDUMP      :   | /home/carlo/projects/aicxx/linuxviewer/linuxviewer/statefultask/AIStatefulTask.cxx:1034: AIStatefulTask::state_type AIStatefulTask::begin_loop(): A      ssertion `!sub_state_w->idle' failed.
<CarloWood> Hmm, ok - so the thread that was "already running" this task was ThreadPool02 itself.
<CarloWood> If I understand this correctly, the summary is: ThreadPool02 is running the task "DBusMethodCall" at 0x5558128d70c0, executing state DBusMethodCall_start which does: 
<CarloWood> m_dbus_connection = m_broker->run(*m_broker_key, [this](bool success){ Dout(dc::notice, "dbus_connection finished!"); signal(connection_set_up); });
<CarloWood> set_state(DBusMethodCall_wait_for_lock);
<CarloWood> wait(connection_set_up);
<CarloWood> The call to run() causes a child task to be started - but that can't be added to the threadpool queue because it is full. Therefore the parent task (THIS task) is told to wait for signal 40000000. A timer is started, which expires and sends that signal (all while this thread is inside that run() call)
<CarloWood> That causes the need to run from the top, so need_run is set - but an attempt to start the task fails because it is already being run... 
<CarloWood> Then the thread continuous and calls wait(connection_set_up) - going idle, leaves multiplex_impl and sees need_run is set - so it starts at the top, enters begin_loop and asserts because it wonders why it is being run while being idle...
<CarloWood> Now the big question: how to solve this...
<CarloWood> Hmmm
<CarloWood> Ok - lemme solve this :/
<CarloWood> One of the main features of a Task is that race conditions (when they exist, and they are unavoidable) don't matter: the result should the same, no matter which 'thing' comes first.
<CarloWood> Most notably, calls to signal() and wait().
<CarloWood> So, in the above case we have (abbreviating 0x40000000 to 4): wait(4), signal(4), wait(1). Where there is a race between the last two.
<CarloWood> Ie, it could as well have been: wait(4), wait(1), signal(4).
<CarloWood> In the latter case, the signal(4) would NOT wake up the task because it is still waiting for the 1, so need_run would not be set, and when the task continues running it would just exit multiplex() because it is idle.
<CarloWood> Hence, in first order I'm inclined to say that the call to wait(1) in the first case should reset need_run.
<CarloWood> Also, I wondered by I run into this NOW - and not before (been working on this project for years).
<CarloWood> The reason seems to be that wait_AND(4) (ok, it is wait_AND and not wait(4)) is new.
<CarloWood> In principle, wait_AND is the same as wait: it causes the task to go idle until a signal is received, but there are two major difference: 1) the bits set with wait_AND are required to see a signal (for the same bits), while -say- a wait(7) would wake up on signal(1), signal(2) or signal(4).
<CarloWood> 2) There are a requirement for wait(): it may only be called from multiplex_impl() and must always be followed by a break; aka, leaving multiplex_impl immediately after.
<CarloWood> wait_AND() however does not have those requirements. If it had then the above wasn't even possible: what happens is that wait_AND(4) is called and then WITHOUT returning from multiplex_impl, a timer is started that causes signal(4) to be called.
<CarloWood> I think that theoretically it is still possible with just wait(): it is not forbidden to have a thread flood a task with signal(1), so it is possible to call wait(1) and get a signal(1) from a different thread before we return, but NOT to *also* call wait again before returning.
<CarloWood> I think the big difference is that the same thread calls wait_AND(4) and then wait(1) before actually returning from multiplex_impl.  Aka, it did not return immediately after the wait_AND.
<CarloWood> That allows for this unique situation where have the sequence: wait_AND(4), signal(4) --> sets need_run, wait(1) --> sets idle, and then returning from multiplex_impl, going to the top of multiplex again because need_run is set while being idle.
<CarloWood> I'm still hesitant to rush and reset need_run inside wait however... and well because of this comment:
<CarloWood> // If the state is bs_multiplex we only need to run again when need_run was set again in the meantime or when this task isn't idle.
<CarloWood> need_new_run = sub_state_r->need_run || !sub_state_r->idle;
<CarloWood> The 'in the meantime' means, since the beginning of this "loop".
<CarloWood> s/need_run/need_full_run/ as it were
<CarloWood> Seems to me that when I wrote that comment I had a reason to think that it is possible that need_run is set and idle too.
<CarloWood> However, as we know since this assert never fired before... whenever need_run is set, idle is not. At least, if idle was set at the time then need_run would not have been set. So, if both are set then that means that FIRST need_run was set (while idle was false) and THEN idle was set, all before returning from multiplex_impl.
<CarloWood> Yeah, that was simply not possible before I think... at least(!) when need_run is set as a result of calling signal. That function only sets need_run when idle goes from non-zero to zero as a result of that very signal. So, using the assert (that it didn't fire) we know we weren't idle at the start of multiplex(), then apparently we were because signal decides to set need_run, which means that wait() must have been called - but since that is only 
<CarloWood> possible at the END of multiplex_impl, it is not possible that idle would be set again afterwards...
<CarloWood> *thinks hard*
<CarloWood> *reads the three page long comment in front of wait()*
<CarloWood> *sigh* - really everything in the library is equally complex :/
<CarloWood> leaving out the comments... this is what 'wait(condition_type conditions)' does:
<CarloWood> sub_state_w->idle |= conditions & ~sub_state_w->skip_wait;
<CarloWood> sub_state_w->skip_wait &= ~conditions;
<CarloWood> condition_type mask = (conditions & ~sub_state_w->idle & OR_conditions_mask) ? OR_conditions_mask : 0;
<CarloWood> sub_state_w->idle &= ~mask;
<CarloWood> Hmm, I think I got it working... my test application doesn't assert anymore and I get all the replies from the dbus server - but when I make the thread pool queue too small the applications stops terminating because the fd of the connection to the dbus server isn't closed anymore - strange :/
<CarloWood> ThreadPool06    STATEFULTASK  : Entering ~DBusHandleIO() [0x7f1d8c001ef0]
<CarloWood> Yup, that line is missing in that case... so the problem is that DBusHandleIO isn't destructed.
<CarloWood> TRACKER       : Instances of tracked::intrusive_ptr<dbus::Connection>:
<CarloWood> TRACKER       :   DBusHandleIO.h:38
<CarloWood> TRACKER       : Instances of tracked::intrusive_ptr<task::DBusHandleIO>:
<CarloWood> TRACKER       :   DBusConnection.cxx:56
<CarloWood> TRACKER       : Instances of tracked::intrusive_ptr<task::DBusConnection>:
<CarloWood> TRACKER       :   Broker.h:60
<CarloWood> the problem is that task::DBusConnection isn't destructed...
<CarloWood> the problem is that the Broker isn't destructed...

<CarloWood> Still didn't find it :/.  Seems my tracker is broken.
<CarloWood> p utils::InstanceCollections::dump()
<CarloWood> This does not show an instance of DBusMatchSignal, but I didn't see the destructor be called. Just,
<CarloWood> STATEFULTASK  :   Entering DBusMatchSignal() [0x555555e81670]
<CarloWood> Seems that that instance still has a reference count of 1.
<CarloWood> p &((task::DBusMatchSignal*)0x555555e81670)->m_count._M_i
<CarloWood> Oh! haha, I set a hardware watch point on that counter, and it gets decremented (and the instance destructed) upon a call to AIRefCount::allow_deletion(bool, int). That means it wasn't kept alive with an intrusive_ptr but with a call to inhibit_deletion() - which directly increments the reference count; hence that it didn't show up on the instance tracker (tracking instances of intrusive_ptr).
<CarloWood> Right, so inhibit_deletion() is called for every task as part of its initialization. So that brings the question to why not all tasks where destructed, which is kinda obviously because they didn't finish yet.
<CarloWood> I see being terminated: 0x55e2ff2504f0 (DBusConnection), 0x55e2ff250230 (DBusMatchSignal), 0x55e2ff250830 (DBusMethodCall), 0x55e2ff250ad0 (DBusMethodCall), 0x55e2ff24e240 (Broker)
<CarloWood> Hmm, I see six times a 'Returning task pointer', among which:
<CarloWood> ThreadPool00    STATEFULTASK  :   |           |   Returning task pointer 0x7f8b58001ed0.
<CarloWood> what? That 0x7f8b58001ed0 is on the stack?!
<CarloWood> Anyways, that is a DBusHandleIO.
<CarloWood> ThreadPool00    STATEFULTASK  :   |           |       | Entering AIStatefulTask::set_state(DBusHandleIO_wait_for_lock) [0x7f8b58001ed0]
<CarloWood> ThreadPool00    STATEFULTASK  :   |           |       | Entering AIStatefulTask::wait(1) [0x7f8b58001ed0]
<CarloWood> ThreadPool00    STATEFULTASK  :   |           |       | No need to run, removing from thread pool [0x7f8b58001ed0]
<CarloWood> ThreadPool06    STATEFULTASK  :   Entering AIStatefulTask::signal(1) [0x7f8b58001ed0]
<CarloWood> ThreadPool06    STATEFULTASK  :       | Running state bs_multiplex / DBusHandleIO_wait_for_lock [0x7f8b58001ed0]
<CarloWood> ThreadPool06    STATEFULTASK  :       | Entering AIStatefulTask::set_state(DBusHandleIO_locked) [0x7f8b58001ed0]
<CarloWood> ThreadPool06    NOTICE        :       | Entering AIStatefulTaskMutex::lock(0x7f8b58001ed0, 2) [mutex:0x7f8b58002080]
<CarloWood> ThreadPool06    NOTICE        :       |   Mutex already locked [0x7f8b58001ed0]
<CarloWood> ThreadPool06    STATEFULTASK  :       | Entering AIStatefulTask::wait(2) [0x7f8b58001ed0]
<CarloWood> ThreadPool06    STATEFULTASK  :       | No need to run, removing from thread pool [0x7f8b58001ed0]
<CarloWood> Hmm, too much follows.. I thought it would hang quickly or something.
<CarloWood> It is locking and unlocking a task-mutex a lot of times (because the 2rd party dbus library is single threaded and may only be accessed by one thread at a time %-/), and ends with:
<CarloWood> ThreadPool00    STATEFULTASK  :       | Entering AIStatefulTask::set_state(DBusHandleIO_wait_for_lock) [0x7f8b58001ed0]
<CarloWood> ThreadPool00    NOTICE        :       | Entering Connection::handle_dbus_io() = <unfinished>
<CarloWood> ThreadPool00    NOTICE        :       |       Entering sd_bus_process = <unfinished>
<CarloWood> ... internal call backs from sd_bus here, handling replies ...
<CarloWood> ThreadPool00    EVIO          :       |       Entering RawInputDevice::start_input_device({{m_flags:FDS_RW|FDS_R_OPEN|FDS_W_OPEN|FDS_SAME|FDS_R_ADDED|FDS_W_ADDED|FDS_R_ACTIVE, m_epoll      _event:{events:EPOLLIN|EPOLLET, data:FD:0x7f8b58002280}}}) [FD:0x7f8b58002280]
<CarloWood> waiting for more input apparently
<CarloWood> ThreadPool00    NOTICE        :       | Entering AIStatefulTaskMutex::unlock() [mutex:0x7f8b58002080]
<CarloWood> ThreadPool00    NOTICE        :       |   Mutex released [0x7f8b58001ed0]  
<CarloWood> Oh, I missed, after the start_input_device: ThreadPool00    NOTICE        :       | <continued> io_handled
<CarloWood> ThreadPool00    STATEFULTASK  :       | Entering AIStatefulTask::wait(1) [0x7f8b58001ed0]
<CarloWood> ThreadPool00    STATEFULTASK  :       | No need to run, removing from thread pool [0x7f8b58001ed0]
<CarloWood> And that is the last thing... a signal(1) is never coming :/
<CarloWood> right... so it doesn't finish because abort() is never called, which is because DBusConnection::terminate() is never called, which is because ~DBusConnection() is never called...
<CarloWood> which is because the Broker is never deleted... which is because there is a DBusMethodCall kept alive... which is because that doesn't finish(?) 
<CarloWood> Nope that finishes...
<CarloWood> ThreadPool05    STATEFULTASK  :   | Base state changed from bs_callback to bs_killed; need_new_run = false [0x55e2ff250ad0]
<CarloWood> ThreadPool05    STATEFULTASK  :   | No need to run, removing from thread pool [0x55e2ff250ad0]
<CarloWood> but it isn't destructed after that :/
<CarloWood> I think I just saw the light... the reason my instance tracking isn't working is because I overload boost::intrusive_ptr<DBusMethodCall>, but DBusMethodCall is derived from AIStatefulTask and at some point I do:
<CarloWood>       boost::intrusive_ptr<AIStatefulTask> parent_task(tl_parent_task);
<CarloWood> That is then put into a lambda, which is stored in a static container...
<CarloWood> Wew - I fixed it.
<CarloWood> In the end, tasks were kept alive by an intrusive_ptr stored in a lambda that was the callback of a Timer, and that Timer wasn't destructed. I now set the std::function that is the callback to nullptr directly after calling it and that fixes the issue.
<CarloWood> Still weird though that Timer object isn't destructed...
<CarloWood> Man, I run into the crazies things.
<CarloWood> Turns out that I wasn't removing expired Timers from the defered_tasks_queue, like ever.
<CarloWood> So, I add the lines:
<CarloWood>               else if (timer.can_expire().is_false())
<CarloWood>                 defered_tasks_queue_w->pop_front();
<CarloWood> in the idle portion of the threadpool - when all thread pool queues are empty, then it looks in the defered_tasks_queue and "expires" timers that didn't expire yet.
<CarloWood> Well, up till the number of threads.
<CarloWood> Aka, I was trying to stop() a timer and when successful (that is, it didn't expire yet and now never will) then I moved the expire callback to another queue, popped the Timer from this queue, and in the end unlock the defered_tasks_queue and call the callbacks on the removed Timers.
<CarloWood> Now I added the above two lines when stop() fails.
<CarloWood> This leads to a dead lock:
<CarloWood> Calling pop_front() above() does indeed destruct the Timer, hence call ~Timer, but destructing a Timer isn't safe because it could be in the process of expiring... so at the end of ~Timer I try to grab a mutex that is locked between the moment that it is decided that the Timer must expire and the point where its expire() was called and all is done.
<CarloWood> So, it turns out that a Timer is indeed in the process of expiring, so this thread blocks on destructing the Timer - WHILE holding the lock on defered_tasks_queue - and the expire callback tries to readd a task to the threadpool queue, which is full again (this is a test for that) and then tries to lock defered_tasks_queue in order to add a new Timer back to that.... dead lock.
<CarloWood> I suppose that instead of can_expire() I need a has_expired().
<CarloWood> perfect, everything works now :)
5
  • Well put. Wordy, but that is the point. What would you think of a [style or realism] a dozen computers or even people linked together and connected to a network to scan for long periods of time (days, months, even years) to find such an exploit. The future setting would allow that. Then just establish the scanners to the reader and have them pull out whatever plot data. I am interested in your opinion.
    – Clair
    Jul 1 at 17:37
  • Something I've always been interested in is the concept of combining the brain power of many people to solve a certain task, in a scalable way. I once wrote a story even that used this idea to create an Artificial Intelligence: in my story the main character invented an infinite fast computer and used that to simulate entire civilizations; each civilization (inside the computer) had to split the problem into two sub problems, feed those to two newly spawned civilizations and combine the two answers. Unfortunately I never got to it to even begin something in Real Life beyond defining an XML
    – Carlo Wood
    Jul 1 at 19:09
  • format that people could use to describe themselves (name, email, contact points, links to libraries they wrote etc). Also every library would need such an XML (aka, machine readable format of this data). That way you could automate a lot of things (ie, configuration of applications (or IDE's) that use such a library). If such a thing would exist, as an underground thing, coming from some mysterious group that could fall in the category "hackers", then certain people could be exposed to it as curiosity, fill in their data and expertise and later find a little task or question in their "mail".
    – Carlo Wood
    Jul 1 at 19:14
  • Some of them could start to wonder at some point what they are working on; considering the nature of the subjects. And when they climb higher in the hierarchy of this illegal, distributed network of knowledge, be allowed to formulate questions themselves - leading to certain characters to come into contact, etc. All in all it would be a plot of slow discovery (one of my favourite), where the reader learns more and more about this society, the forces at play and the characters involved.
    – Carlo Wood
    Jul 1 at 19:17
  • It sounds like a good dystopia, and it can have rather satisfying ending. Unless, a less network want to become its heir for a sequel hook. Funny enough I had a sci fi story they did just the opposite. They grew enlarged brains with no memories the was at the center of a massive machine hooked up to super computers. They could never figure out how to create a true A. I. without the brain. These run massive ships, and have various personalities. They are as loyal as another person and just as cooperative. They live in there on dream world connected to the real one.
    – Clair
    Jul 1 at 19:25
1

You have the same problems that fantasy writers have with magic, and that is how does it work and is it believable.

Start with writing down the rules of cyber-space.

because if you don't understand your own rules then you can't express how they operate in your world, and your writing will be vague and unsatisfying as your characters do cyberpunk things in your cyberpunk world. And, that will result in your stories feeling less real and likely lead to handwavium and deus ex machina resolutions to conflict and crisis.

The important thing to keep in mind when doing your world building (developing your version of cyberspace) is that believability follows from understand-ability. This doesn't mean you ought to be defining precise technical details how your human-machine interfaces work, but that you can describe a consistent set of actions and gestures used by your cyber-cowboys as they interact with cyberspace and those actions lead to readers being able to imagine and predict the consequents of those actions.

Once you have developed your cyber-system, you need to make sure its not over powered otherwise your story degenerates into boring power fantasy. And it needs to be flexible enough that it can support tension and suspense. Just as characters need agency to be engaging and interesting, they need to face consequences for their decisions for there to be tension and risk.

3
  • The closest you could get to cyber-space is a optic set up allowing you to see a network and, if hacked, the (nodes) parts of the network. Use you optics to find and a tool kit to break into a node. Then you would need to see info, programs, security, virus, even backdoor. There is not world net, you have to get close enough to interact is isolated networks. I don't see the hassle unless the team needs to break through multiple nodes in a variety of ways.
    – Clair
    Jul 1 at 18:14
  • 1
    @Clair, i believe that the space in cyber-space is used in the mathematical sense of any n dimensional system with well defined metrics and not a term specifically implying a 3d virtual reality. It sounds like your cyber-space looks like our world today, which is great and all. Next you need to make up how it works and the costs and risks and payouts so you have a self consistent definition to use in your story
    – EDL
    Jul 1 at 18:21
  • Your right, and I ended up making my own rules. I Didn't even notice.
    – Clair
    Jul 1 at 18:37
1

Simply don't try to write about real world hacking and hackers. There is zero chance to get it right unless you know what you're doing, and people involved with it in the real world will immediately throw your book away.

If you look at the popular Cyberpunk authors, when the genre was still around, you will find that they basically invented everything from scratch, with colorful language. For one, back then, the real world simply was not there yet - they had nothing "real" to really write about. And secondly, it is so massively more entertaining to write about "ice", "decks", "runners" and whatever else they came up with.

Some argue that Cyberpunk is dead because the genre was about the fight of individuals against big corporations, in a nutshell; and today it's a moot point (the corporations have won, in the real world). That said, there are still modern authors who manage to write extremely interesting stories including hacking/hackers. They (at least the good ones that I have read) usually also just invent everything as they need it. They also do not spell everything out in excruciating technological detail - the reader is not supposed to be a hacker themselves, and for the reader the story is as mysterious as for any bystander inside their world.

So focus on bringing the wonder and mystery to the reader, don't try to impress 2021 real world IT persons.

3
  • 1
    The story is more social not scientific. This is just setting where hacking is not the focus. Because it is there I need to know about it, only enough. But the real reason I wanted to respond is the idea the loss of individuals to corporations is pretty dead like you said, but this story has a social twist from history. One major element is the Red Coalition lead by a socialist acting as a political machine utilizing violence and charity. Helping the poor in a big way. Their boss is a living legend but not as an individual. I think that is what's worth exploring. Any thoughts?
    – Clair
    Jul 2 at 15:32
  • And a few other great answers and comment helped me figure out how to have it 'realistic' and dumb it down. This community is a great help.
    – Clair
    Jul 2 at 15:34
  • @Clair, while the movie Hackers was great, it was a horrible explanation of what hackers do. Speaking as a software developer, we do nearly everything in text, not graphics, even when we're designing graphics. All that was just flash for the audience. So just don't try to go into details, as it won't age well, just like Hackers didn't. New tools and techniques pop up and old ones die frequently. The Matrix's Neo was a hacker, but they didn't go into detail, so that's why it's still interesting. Even Sneakers is borderline, due to the details they provide, but they still aren't too detailed. Jul 2 at 16:21
0

If your story takes place in a fictional, futuristic cyberpunk world, where technology is different from what we know, you pretty much have a clean slate. It's up to you to decide how the hacker community and traditions would work in this fictional world. It can be similar to what we have in the real world today, or completely "Hollywoodish".

I actually have a published novel, a techno-thriller which pretty much revolves around hacker culture. The story is about an aging hacker who decides to rob a bank with a robot. But he's primarily driven by dedication to his trade, and traditions of hacker culture which he greatly respects.

This is what would define a hacker beyond all. Respect to the unwritten "code", no matter he's a black hat or a white hat.

A hacker, first and foremost, loves technology and worships the Spirit in the Machine. Really devoted hackers are outright fanatics. Pulling off a prank, a technological trick, a "run" might be more important to a real hacker than the reward itself, or literally their own life.

Think of hackers as pilot jocks who love flying. They are very disciplined inside, but they do crazy stuff all the time, and at first sight, they look quite the opposite of what they actually are. What they are doing seems crazy and chaotic for the outsider, but it's actually very precisely calculated and professional.

A true hacker would never disrespect the Spirit, or another hacker who he recognizes as one. In this respect they're much like fighter pilots: they may fight to the the death, but shake each others' hands when it's over. They fly for flight, not to fight. The hacker also hacks for the hacking, and not for the reward, or out of spite for somebody. Except if that person disrespects the Spirit.

A hacker never actually destroys: he only builds. Even if his activities actually destroy something, it's something that's meant to be destroyed, because it's tainted, bad, disrespectful to the Spirit, violates the hacker's perception of right or wrong. A hacker might write a destructive virus or malware, but in his own eyes, the world will be a better place if the target is destroyed.

But of course there are people who call themselves hackers without actually being one. They don't know jack shit about the Spirit, and just want to break and destroy. An outsider may confuse these with actual hackers. They don't know, or outright disrespect the Spirit. But without the Spirit they can never be good, even if they can still achieve something. Hackers have a lot of derogatory names for these: script kiddies, lamers, l-users, etc.

0

I would start out by reading a book called "Ghost in the Wires" that details the story of Kevin Mitnick, one of the first people to be jailed in the US for cyber crimes.

From my experience in IT and skirting the edge of what some might call hacking (I'm routinely tasked with making systems work together when they shouldn't be able to, often by writing software that takes advantage of issues in one system or another), the single most important thing about actual hackers like Mitnick would be curiosity. They are driven to figure out how things work, and take pleasure from gaining access even if they don't actually do anything with it. Social Engineering is a big part of it also. Mitnick impersonated people to get information and then used it to put together a big picture of how everything worked.

One more critical piece is on system designers. Mitnick was only able to infiltrate the systems that he played around with for so long because the phone companies that he was exploiting used an outdated OS called VMS with known vulnerabilities. Lazy sysadmins and corporate cost cutting measures keep vulnerable systems up and running when there are better alternatives.

0

A lot has been said, for instance reading Gibson and others, but here are some other thoughts.

Roughly speaking, you can grade most organizations on two dimensions; commercial focus and security focus.

On one extreme is high commercial focus/low security focus. This is likely the kind of organization where you can walk in the front door, steal the CEO's lunch box, eat it at his desk and then have him bring you coffee... (And you'll steal the engineering plans for the next energizer bunny while he brings you the cream...)

The other extreme is low commercial needs/high security needs. This is probably the kind of organization where security is the main focus. Here you're not going to just walk in unannounced. You're not going to be left alone in there and you're not going to be bringing any electronic equipment with you in. Not that it matters much since the "real" data won't be reachable from the nearest networking socket anyway (at least not without a client side MacGuffin cipher descrambler... ok, just throwing things at the wall to see what sticks... what I meant to say was "Nah").

Generally, high commercial focus and high security focus are rare, because high security is costly and intrusive.

Most hacks have a social engineering component.

It could be stress: For instance, the "are you the naked person in this video?" Facebook messages to make people click a video link or mails about lost pensions and security breaches that need to be handled provided with a nice login link.

Or curiosity: For instance, if people find (or well found in the 00ies) a USB stick on a conference table and it had the company logo some alarming number of people would stick it into their computer to see what it contained. An even larger number of people would load a CD (now we're talking 90ies) with the label "wage negotiations"... I guess, these days it'd be along the line "don't you know the naked person in this video?"

Or just general lack of attention: sending an email with an attachment that looks like something one might get sent to oneself so one opens the attachment... because the baby kept one up all night last night...

If you want to be realistic, I suggest not having your hacker trying the hard to crack targets, but as others have mentioned, go for the softer type of targets instead... quantity over quality...

After all, on the other side of that e-mail offering huge rewards, there's a (likely not) Nigerian Prince that needs to pay his bills and feed his kids, so rather than spending months or years trying to do an insanely hard hack, most "for-profit" hacking is more about quantity—trawling for the stupid and/or ignorant...

Unless your hacker is doing it for creds.

0

The core of most hacking is to exploit mistakes (in this context oversights are also mistakes). Broadly speaking people can be put in one of three groups:

  1. Engineers / Security professionals - anyone with (some) responsibility for securing a system.
  2. Users/Consumers
  3. Hackers

I have called out users as a separate group for two reasons:

  • Typically they are far less knowledgeable than security professionals.
  • Sometimes users genuinely don't care about hacking. **

** - For example if a users system gets breached, but the hacker is only using the users system to attack someone else, it is possible it will neither be detected by the user or impact them in any meaningful way.

In an ideal world there should be no distinction between a user and a security professional they should both be knowledgable (and equally diligent about protecting the system) unfortunately that isn't reality. So we live in a world where security professionals try to anticipate mistakes made by both users and other professionals and put in place mechanisms to prevent hackers from exploiting them. This is similar to a castle with multiple concentric walls, the concept being that if an attacker breaches one wall, there is another wall behind it which will still keep the attacker out.

One can make an analogy between hacking and an election, again we can say there are three groups:

  1. Election Officials (trying to ensure a "fair") election.
  2. Voters
  3. Anyone trying to ensure a particular candidate wins.

Put yourself in the position of someone trying to "rig" an election, how would you do it?

  • Fill the ballet boxes before they are distributed.
  • Add extra votes to the boxes in transit to the counting center.
  • Remove some votes from the boxes.
  • Ensure some boxes never make it to the counting center.
  • Change the hole punch machine so they don't line up.

An election official will put in place mechanisms to try to prevent each of these from occurring.

But one can extend the analogy to things which are not illegal, but still affect the likely outcome of the vote:

  • Incumbents vs Challengers.
  • Redistricting
  • Two candidates with the same name.
  • Multiple candidates representing the same party (splitting the vote).

There are analogies in the tech space for example, paying for a bunch of fake reviews to make your restaurant appear better than it is.

In short people design and build systems to achieve specific goals or only grant access to specific individuals. However those building the systems make mistakes and overlook things. Hackers spend time trying to find the mistakes, so they can exploit them for some kind of gain (even if the gain is simply recognition from their peers). If you set your story in a contemporary context there will be a group of people who find the lack of technical detail problematic - that may not be an issue for you - there are plenty of movies that have totally inaccurate representations of hacking that do just fine at the box office.

If you want to avoid that problem you will need to change the context of your story, for example:

  • Set the story far in the future where current paradigms don't apply.
  • Introduce some new tech that radically changes the way things work today - quantum computers that can instantly defeat (most) encryption.

However you can probably still use the core concept that hackers are looking for mistakes and/or oversights that others have missed.

With respect to more general knowledge about tech and how things work, I would suggest limiting yourself to describing things from a user perspective: what was the user trying to do and what happened to them. If your narrative absolutely requires you to explain how things work, you can always invent some new tech and explain how that works.

Not the answer you're looking for? Browse other questions tagged or ask your own question.