Halo 2 Forum
This topic has moved here: Subject: What the strange code means on ilovebees
  • Subject: What the strange code means on ilovebees
Subject: What the strange code means on ilovebees
  • gamertag:
  • user homepage:
  • last post: 01.01.0001 12:00 AM PDT

This isn't my work, so I'm not taking credit.

My opinion is that these "sec proc" listings are security processes - security processes to which the SPDR recovery utility should have access. In the cases of processes 1-3, it does indeed have access - they query SPDR, SPDR responds with its programmed authorization codes, and the processes allow it to continue to the next process. Upon encountering security process 4, however, SPDR encounters a problem - Process 4 no longer recognizes it, hence the failure result of the fifth "!probe primary sector" command. Security Process 4 basically says to SPDR, "Yeah, and I'm the King of England! Shove off, you!"

---


---

grope:

!init search

master-sector

!probe master-sector

fail

Init strings tell a modem how to act. There are literally hundreds of modems on sale and each one has it's own different init string AND there may be a different init string for each modem, its trying to find the init string for the modem.connection. the modem returns this, master-sector, so it trying to probe it (!probe master-sector) but fails... mebe this is because sum ports are closed. [EDIT: A port scan (innocent, don't worry) reveals that you only have three ports open, the typical HTTP and then two server-related ports.] but the codes.. look like puesode codes. [EDIT: 'Pseudocode' is stuff that looks like computer code, but is not executable as it. Perhaps a different programming language, or a prank?]

---

And, now, for me. I studied it as well, and came up with some comments to add to the code to explain it a bit. At least, this is my opinion.

---

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

!route

proc attach proc net

!route

proc attach proc grope

!route

proc attach proc sur

//Telling the network subroutine to 'attach' (connect), and do the action 'drop' afterwards. Perhaps connecting and then immediately dropping after passively storing information about the connection? !route likely is saying the different actions it can take: procedure (protocol?) attach (like TCP/IP protocol for connecting), and then protocol/procedure either net (network completely, gain a full connection?), grope (examine?), and sur (??? at this point).

net:

!attach

act | drop

!attach

act | drop

grope:

!probe host

crypt weak

!decrypt host

decrypt confidence 100

//More attaching and dropping. Searching for something? Also, we can see that grope is equal to probe. The probed host/file has cryptography on it. This program, however, has the ability to decrypt. It is 100% sure (confidence 100) that it has been decrypted after this command (!decrypt host) is executed.

!probe master sector

fail

surg:

!invntry primary sector proc

proc invntry 343

working 0

dmg 38

dmg unk 2

broken 102

abs 201

!invntry primary sector mem

mem invntry 678223072849

clear 0.0007

dmg 0.0014

frgm 1.41

abs 98.5879

//The master sector (like the one on a hard drive) is probed. This fails. The 'surg' command is used- still no idea what it is. !invntry is inventory, it seems. The subcommands are likely primary and sector procedures, and then later primary and sector memory. As for the first part: 343 sector procedures? 343 sector protocols? Something along those lines- I'm guessing similar to cylinders in hard drives. Perhaps even there are 343 total subroutines. That isn't too hard to believe, with the complexity of a program like this. None are working fully. 38 are damaged. 102 are broken. Broken implies that it isn't working at all, while damaged may just be corrupted. 201 are 'abs'- absent? Not showing up on scans at all? Two are 'damage unk', I am guessing 'extent of damage unknown'. Maybe they are working fine, but are next to or surrounded by damaged ones? Mem inventory is pretty obvious- that's the amount of bytes of memory. That, or kilobytes, which is actually rather likely. This means it's either about 700 gigabytes, OR about one thousand times as much, 700 terabytes. Either amount is a huge number- the largest commerical hard drive in existence is a single terabyte. 'Clear' means that memory checks out okay. 'dmg' is damaged memory, as per the hard drive. 'frgm' is fragmented memory that needs to be 'sorted', essentially, because it's being inefficiently used. 'Abs' is, like the prior, absent. It can't be found.

net:

!attach

act | store recurse

surg:

!config

master-sector:net attach

!config

master-sector:mat si

!kindle master-sector

master-sector active




//More connections. This time, however, it does 'store recurse'. Recurse is likely recursive: it means an operation will call itself, until it reaches an end point. This would be like telling a computer to print a page every time you pressed A, and every time a page is printed, treat it like someone pressed A on the keyboard. An infinite loop. 'Surg' again. No idea on it, yet. 'master-sector: net attach' is trying to connect to the master sector from earlier that was unable to be probed. Then, it is configured. 'mat si' maybe means 'material: silicon', telling us it's solid state storage, instead of a hard drive (assuming I'm remembering this right, I'm not a hardware guy'. This would make sense- an AI can't be bogged down loading from slow hard drives. After this, it attempts to 'kindle'- starting up a fire, or in this case, the master sector. Perhaps repairs have been successful at this point? That, or the order of the code is incorrect. But, by this point in the code, repairs have worked, and the master sector (perhaps the sentience layer of the AI?) is back online.

net:

!attach

act | drop

surg:

!mat

si confidence 78

//Another connection and then disconnect. Surg appears to be a detailed analysis tool, at this point. Like performing an autopsy... wait, maybe 'surgery'? Hmm. Next, another materials query, this being nearly certain that the storage medium is silicon. More solid state storage.

grope:

!probe master-sector

fail

!probe master-sector cmd proc

empty

!analyze magnetic

& si !extend

!spdr extend

si > magnetic

!probe master-sector cmd proc

master-sector




//Once again, unable to probe the master sector. I get the feeling I have this disjointed, unfortunately. The 'command process' tries to probe- maybe a more detailed level of probing, by a 'more priveleged' system? Now, it just shows up as empty. Analysis is made of it, and seemingly as an afterthought (&extend) silicon is included in the probe of its magnetic properties. 'SPDR' is also initiated at this point. Maybe since it's having trouble, it's activating the 'SPDR' system, since it's reflexive? If it can't do this in a timely fashion, it would reason that it's better to make copies of the system so that it can be restored from the copies instead of just continuing to check things. Damaged memory can cause overwriting errors, where changing a bit changes a nearby bit, soon escalating into huge errors. This probe, in the meantime, returns as more likely to be silicon (solid state) which is where problems would come in. The master sector is probed with the command process again, returning that there IS a master sector. Maybe after analyzing, it now knows what kind of corruption to look for instead of just hard drive errors, and can attempt to fix it.

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

grope:

!probe extern proc 0

crypt strong

surg:

!mat extern proc 0

si confidence 78

!triage extern proc 0

fail




//More connections, and then a probe on 'process 0', from an external source. Maybe it's viewing the website? It returns as strong cryptography- perhaps a testament to your setup skills. Maybe that 'surgery' command again? material external process 0. Once again, silicon, perhaps saying that it's reading from RAM (what's currently happening on the site) instead of from disk (stored files). 'triage' is a surgical term, that refers to a surgeon rationing out supplies, like during war time. In this sense, I would guess it's way to limit the draw of programs. This fails. Maybe this is why the site got glitchy- it was likely that this program was trying to shut it down.

net:

!scan

null

!listen

null

!attach

act | drop

!extern 2

//Now, it appears to be scanning on the network, and picking up nothing with either a scan (implying active) or a listen (implying passive). It then connects to something, and then tries to call (calling is when you activate one program from another) 'extern 2', maybe another program related to the website? Perhaps a different part of the server program?

system peril distributed reflex

!restore master-sector

recurse

//SPDR was called earlier, and is here seen responding. It instructs the original program to restore the master-sector, and be recursive about it, continuing to do it until successful. Like, say, CPR on a person with no heartbeat can be continued for long periods of time before they suffer brain damage.

Continued in reply.

  • 07.28.2004 2:31 AM PDT
  • gamertag:
  • user homepage:
  • last post: 01.01.0001 12:00 AM PDT

!system

peril

!init host

fail

!bkp init primary sector sec proc

fail

!bkp init primary sector

fail

!bkp init master-sector

fail

!bkp init master-sector cmd proc

empty

//I'm guessing that this was one of the initial commands. It checks the system- it's rated as in peril. It tries to connect to a host (read the earlier comment one of my students made abou models). Failure. Loading the backup (backup initialize) of the primary sector secondary process (loading a backup, perhaps non-corrupted version, of the currently running emergency system?) fails, as does loading the back up of the primary sector itself. The master sector command process is loaded from backup. It doesn't just fail, it's an empty file- corruption, or was it deleted?

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop grope:

!dsc host sector 0

!dsc host sector tertiary

!dsc host sector tertiary

!dsc host sector tertiary

surg:

!mat

magnetic confidence 100




//More connections, and then studying the '!dsc host sector'. A sector on the disc of the host computer? 'tertiary' sector could very well be tertiary storage for the AI- primary sector, secondary sector both being internal, with 'tertiary' storage being hard drives and the like. Material? Magnetic... confidence 100%. It's studying disc drives, likely the stored webpage files.

net:

!attach

act | store recurse

surg:

!reconst master-sector

mem broken>>dmg recurse

!reconst master-sector

proc frgm>>dmg recurse

//Another connection. Another recursive of the below function, which is surgery again: reconstruct the master sector of memory, making 'broken' memory into 'damaged' memory. Also, reconstruct the master sector of processes/procedures, from 'fragmented' (broken apart improperly across the memory sections?) to 'damaged' (simply not running correctly). It will keep doing this until it's successful.

net:

!attach

act | drop recurse

!extern proc 0

log accessed

//It drops the recursive commands. It also loads the external process 0 again- the log of it, specifically. I wonder, is the 'external process 0' the Hotmail account? It could be accessing it by doing this, with the 'log' as which emails have arrived. Perhaps this program is 'Maxwell's demon', deciding what goes in and out of the email account. After all, it can monitor 24/7. Humans can't.

!deploy

network

grope

surgical




//Ah, confirmation: network, grope (examine), and surgical (performing functions such as indepth study or removal). Good.




net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

grope:

!probe primary sector

sec proc 1

!probe primary sector

sec proc 2

!probe primary sector

sec proc 3

!probe primary sector

sec proc 4

!probe primary sector

fail

surg:

!triage sec proc 1

fail

!triage sec proc 2

fail

!triage sec proc 3

fail

!triage sec proc 4

dmg unk

//More connections. The primary sector is probed sequentially, there are four processes running on it. Perhaps... some automated subroutines? Things like SPDR, the backup system, and the automated alarm system that is appearing on the front page? Not necessarily all the same order, or even those processes. It can't shut them off: the warning stays. I wonder, are these all the aspects of SPDR? Activate, throttling, metastisizing, and then 'wide awake'? But... the last one's damaged, so something may be up there. None of them can be shut down. Maybe the repair program didn't mean to call in SPDR immediately, and just have it running in case it crashed and couldn't call it later?

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

grope:

!probe extern proc 1

surg:

!diag extern proc 1

rogue proc

!bite rogue proc 1

clean confidence 97

//More connections, probe external process one. A rogue process- maybe the anti-spyware/virus-scan you ran? It 'bites' the rogue process, 97% sure that it's 'clean'. No more threat from it... maybe it excluded itself specifically? Check your virus definitions.

net:

!attach

act | drop

grope:

!hndshk sec proc 4

fail msg: unk proc




//Connect and examine. It's something familiar- handshake, like the modem term where it tries to connect. 'Unknown process', for either a 'sector' or 'security' process. Could it be the 'sec proc 4' from above- the 'wide awake' part of the program? Maybe it tried to connect after it couldn't shut it down, to figure out what the problem is. But it's an unknown program, now... perhaps it has been modified.

net:

!attach

act | drop

!attach

act | drop

surg:

!kill sec proc 4

kill confidence 100

!diag primary sector

clear




//Now, it tries to kill it. It's sure it's killed it, and the primary sector is clear. Is it, though? It's encountered problems before.

net:

!attach

act | drop

surg:

!triage master-sector

broken

//The master sector is broken, and can't be shut down. It probably needs work on individual components first.

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

!packet analysis

chatter protocol ancestor

!parse packet

analysis complete

!route

proc attach proc store




//This looks like Maxwell's demon, right here. Proc attach proc store? It connects, and then stores information. 'Chatter protocol ancestor' may mean it wants to use a newer protocol, but falls back on an older but similar one. It could be talking about POP3 email protocol, where it is sorting the emails. Apparently, it has been replying only with bits and pieces of emails sent to it- the 'store' part comes into play there, as does 'packet analysis' and 'parse packet', as in going through to find specific pieces.

net:

!attach

act | store recurse

!capture

chatter protocol ancestor packet

!analyze

time 2004,6,29,8,25,0

!put

time 2004,7,24,6,7,0

!put

warn

//Connect, store recursive again: capture 'chatter protocl ancestor packet' (emails?), and analyze them. While they are analyzed, a time is found. It puts another date, and the warning, on the site.

net:

!attach

act | drop

!attach

act | drop

grope:

!init search

master-sector

!probe master-sector

fail




//Connect, initialize search. The master-sector is found. It can't be examined.

net:

!attach

act | drop

!attach

act | drop

!attach

act | drop

!attach

act | drop

surg:

!label host sector 0

!label host sector tertiary

!label host sector tertiary

!label host sector tertiary




//It labels the host sector (the disk) as tertiary sector, which we saw referenced above, due to the disjointed nature.

---

To me, it looks like there are several players at work here:

1) The core AI entity, which seems to be damaged/incoherent somehow. It's probably generating the 'stories' that I've heard about in the text strings. Perhaps it was designed to waste cycles on making them instead of trying to solve (and potentially make worse) its own problems when damaged, similar to people not moving when they are injured- they can't 'shut down', and neither can an AI. That would be death. It's writing to your site (disks) instead of to itself (memory) so that it doesn't accidentally overwrite something important that's stored in its memory.

2) The self-repair subroutine that is trying to fix the AI. It appears to be ineffective with this level of damage, and the AI may need professional repairs.

3)SPDR, which 2) tried to call in but may have done so accidentally. It seems to want to try and take over other sites, but is being limited in doing so by 1)- 'network throttling'.

4) A warning system, generating the black box. It's telling us the information we need to know directly.

I think that this AI is just trying to repair itself after suffering major corruption- damaged memory? Tampering? Hacking? I don't feel as threatened by it itself. What I am threatened by is SPDR. Even 4) admits that 3) is intrusive. It's not pleasant to lose an entire computer to virus, and that's essentially what SPDR is making a logical assumption.

My advice has changed. I think that this AI needs to be kept running, because if it's shut down, we may never get it running again. The boot area may be damaged, allowing it to continue to run, but not start up anew. Perhaps we should attempt to get a small network of computers running, allow it to spread into them, and see what happens from there. A small sacrifice, just to see how it works. That way, if we do need to attempt to repair the programming ourself, it can be done on a copy instead of the original. I hypothesize that it will be able to work on itself though, once it has enough copies. One copy 'works itself to death', so to speak, in making another one better. In time, it would restore itself to the way it's meant to be.

I am simply concerned that this will end poorly. I don't want that to happen. Continue to run it, try and isolate it from the internet itself if you can before the end date. Give it room to expand, maybe. I'm sure you could get access to a few cheap computers to LAN together and let it expand into that. Try and keep it alive, by all means. But if you have to, remember, humans are above neat little programs, no matter how cool of a toy an AI that acts sentient would be for labs like mine across the nation. Destroy it if it tries to infect other sites, because once it gets out of the gate, it's too late to stop. One copy can create an infinite amount more.

  • 07.28.2004 2:31 AM PDT
  • gamertag:
  • user homepage:
  • last post: 01.01.0001 12:00 AM PDT

i dont know about your theory but your sig is funny as hell i just woke everyone in my house up laughing

  • 07.28.2004 2:32 AM PDT
  • gamertag:
  • user homepage:
  • last post: 01.01.0001 12:00 AM PDT

Triple post, I know, but I didn't have enough chars after that last one to say where it's from. It's from the FAQ, quite far down. I just thought I'd post it because it seems significant.

It makes it seem like there is more than one AI in there. Any thoughts?

  • 07.28.2004 2:33 AM PDT
  • gamertag:
  • user homepage:
  • last post: 01.01.0001 12:00 AM PDT

Posted by: Derrick2004X
i dont know about your theory but your sig is funny as hell i just woke everyone in my house up laughing


lol, I kinda ran out of steam near the end.

  • 07.28.2004 2:34 AM PDT