Networks -- Hacking part 1.5

ID:96915
 
Jun 14 2010, 5:01 pm (Edited on Jun 14 2010, 5:16 pm)
Hopefully this picture will explain a little better what exactly is happening behind the scenes.

(Computer A being the computer hosting the network)



Let me explain what this system limits in relation to the hacking concept.

The send and receive protocols must be the same between the two corresponding computers. A change in the protocols will fail all attempts to upload a file to the network.

Next, by checking a dynamic hash with A's own protocol assumes that the corresponding protocol existing within computer B has hashed the file, and not some third party source. Of course this isn't bulletproof, knowing the protocol code and how a file is hashed, you can imitate this and trick the network into thinking the actual terminal hashed the file. This is what I want, a flaw in the system.

Now maybe you can see the weakness in the system that could allow for a good hack.
Intercepting a file when its in middle of being sent to computer A and updating and hashing it correctly with the appropriate virus may be deemed possible.
A spy could download a different receive firmware (?Audeuro) version for computer A. Why bother with this? Well now you know the send protocol code to hash your files with. Get onto the network with a laptop, hash a file with the same protocol code you used to upload into computer A, and upload it.

With a system like this, you gotta think creatively. Taking your gadgets into account, how far could you take this hacking concept..? It's all up to the spy's competence.
Jun 14 2010, 5:30 pm
I think this needs to be thought through a little more.

If you end up having dozens of users per mainframe, how are you going to determine who's connecting and verifying identities and whatnot?

I sure as hell hope that you're not going to loop through everything; there's definitely a better way of going about this.
Jun 14 2010, 5:43 pm
Well for starters, only 1 person can be logged in at a single terminal at a time. Further more, only 1 person can access a single terminal at one time.

Next, the terminal simply serves as an interface. Upon first load of the interface, it uses the computer's variables along with the network datum to simply 'know' if everything is in order.

If so, variables are fetched from a mysql database and loaded into appropriate data datums, which are then displayed into that interface.

Next, when saving an edited file from within the interface, that corresponding data datum is edited. This is then hashed and sent to computer A, computer A does all these checks as described above. If everything checks out, the variables within that datum are saved to the mysql database.

So basically, the only real sources of possible lag is loading the terminal interface for the first time, and sending an updated file back to the server. I'm assuming there won't be need to loop through much more than the main computers and satellites, which I have added to a specific list which will dramatically reduce the number of instances I have to loop through.

As for authentication, the terminal itself does that. Before granted access to the interface, you must either present necessary codes or supply your ID card. Then (I'm still debating on this) to connect to the network you need additional authentication. After this is all done, the physical terminal will keep track of who is logged in and authenticating the users.
Jun 14 2010, 6:37 pm (Edited on Jun 14 2010, 6:43 pm)
--Quick Idea/note to myself:

The upload proc uploads the file ready to be sent to the main computer into computer A's variable called 'waiting list'.

Every 4 seconds, computer A takes everything from the waiting list and then proceeds to decode it and send it through protocol checks.

This opens up more hacking functionality, a device could be set up to 'ping' and receive (physically remove) all the files in the waiting list. It then goes about rewriting certain fields on the data (depending on the hacking device and the data), and it will send it back to the waiting list, maybe taking about 1 second to do.

THEN I could put a timer functionality on a file. Record 'fred' was sent to the waiting list at [world.time].
Computer A takes 4 seconds MAX to get the files left in the waiting list. When computer A receives the file, it runs a check comparing the files 'sent' variable with the new world.time. If its over 4 seconds, we have some illegal operations going on, and it could set an alarm off or delete the file.

Heh I hope I'm not confusing anybody

Edit: Then I could make different quality hacking devices, higher quality taking less time to retrieve, edit, and send back the data, thus lowering the chances of setting off alarms.

ALSO you can program how often your device 'pings'. Each ping takes X amount of charge in your battery cell. Pinging at a rate of 2 seconds will most likely catch updated files but will run your battery down low. A ping of 6 seconds would last 3 times as long, but your chances of catching a file are slim. The device could ping at the sixth second, but a file was sent to the waiting list at the third second before computer A retrieves the list. Taking one second to edit and send back the data will bring the file past the 4th second check, thus missing it's que.

Man I could go on and on..