SnD222 - Analysis and Report

Go down

SnD222 - Analysis and Report

Post by Crono on Wed Sep 23, 2009 8:43 pm

Subject: SnB222 'Slash and Burn'
Purpose: Forced system information wipe.
Author: Damon Decantes

On our prior assignment at an Earth Analogue, the Blaze of Glory was exposed to both figureheads of the Void operations there. One, Damon Decantes, was revealed as the author of the SnB222 data wipe algorithm we've encountered twice on our most recent mission on the world of Pokemon. It would be important to analyze the figure to take an adequate guess as to how to decipher current versions and consider future iterations.

Damon was anything but subtle in our encounter with him. In our final confrontation on the earth analogue, we made an attempt to contact the Renraku Vice President who supposedly controlled the life of our hostages, but instead found Damon on the other end. He didn't even bother hiding the fact that the had offed the VP, and cut right to the chase - an exchange of prisoners on the promise of a show down. He was eager for a challenge. Given his unique ability to create clones of himself, his tactics and mindset were purely on overwhelming and overpowering. This theme continues in SnD222.

The protocol starts with a mapping of local file structure, sorting to create a minimum spanning tree of referenced memory-addresses, prioritizing full wipe on spaces with /actual/ information on the storage space. This is accomplished by means of a reverse-delete algorithm such that:



This is preferred for the case of SnB222 because it returns the edges in decreasing order of weight, allowing instant access to the next smallest node within memory address. A node may become corrupt by matter of deleting a referencing node, therefor, it becomes more efficient to delete smaller nodes first with the possibility that a larger will follow with it than vice-verse. Now, the kicker to the protocol is two features. First, the wipe is a strong balance of both coverage and thoroughness. Several instances of the wipe are opened simultaneously, running in parallel threading on alternating nodes, eventually re-wiping the same space as their partner instances, but in a different formatting. While something like a clean slate of logical 0's is a quick wipe, it doesn't ensure irreversibility of the deletion from analysis. Only with several passes is the ensured effect accomplished. Between the two separate times we've run into this protocol patterns seem to have matched different subsets of the following standard cases. In the case of 'user defined', his defined wipe sequence has remained '222'.



The second kicker is the real trouble - the protocol, once substantiated, becomes malicious. That is to say, it is not ceased from standard system control. In a way, when activated, the Void are choosing to run something closer to a virus than a tool on their systems. There is no direct method cease it once it has begun. In future strains, we can expect to see this control method altered to prevent exact-counter matching, and likewise, different wipe sequences further randomized.

The question becomes, now, how to create a follow-up that is fairly reliable, such that it can react to differences between different strains and lock down the protocol during infiltration missions. The baseline thoughts should be broken into several pieces:

1) One of SnB222's biggest strengths is also its biggest weakness. Given its malicious state, while independent from system run time, this also means it has no forcible interaction with a system's operating system. Thus, it is unable to reach and priority queue for CPU time, and as done in the past, it is possible to simply 'bog' a system down such that SnB222 is unable to find any available system resources for its computations. First step for counter-designs will be to create a reliable, reusable application if garbage injection that seeks to take specified resources SnB tends to take hold over when left unhindered, allowing further time for data recovery before it extends.

2) The means of ceasing SnB222 in the prior two encounters has been the following. Start in a random place on file structure, and begin removing references to other nodes, storing local copy of these references unreachable by the protocol. Continue to do so until system shows no further activity, proving you've 'cut off' the protocol from any reachable nodes, making it believe that is had finished its deletion process. From there, re-compile references on local copy and retrieve your pieces of information. Working this process by hand, while effective, can be vastly improved by an automated process that does this work for us. The issues there become several fold in turn.
-Creating a stable method for recognizing that your random node of information has not already been wiped, and therefor, is already within the bounds of the contaminated structure.
-Choosing a proper graph-traversal algorithm for the memory space using the proper heuristics. That is, on SnB's side of the equation, it is converting smaller nodes first. Likewise, we would rather favor an algorithm that maps the memory space as quickly as possible, regardless of shortest-path.
-Optimization could come in the form of: Creating a counter-conversion system such that, rather than cutting a node off from the memory space from SnB, we instead turn it into an active reactive-agent such that any tampering of its data responds by attacking that particular thread of SnB, cutting its active sweepers, slowly the process even further (and eventually eliminating it). Conversion system would have to be prepared to handle changing strains of SnB222.

-Crono Arinborn, discussion to be furthered as project process continues.
Crono
Crono

Number of posts : 50
Age : 31
Location : Washington State
Registration date : 2009-03-19

View user profile

Back to top Go down

Re: SnD222 - Analysis and Report

Post by Crono on Thu Oct 01, 2009 9:33 pm

Progress Update

I've successfully deciphered the main components of SnB222's structure and put together a counter-file that will function as described above when loaded onto the Void's systems - SnD 'Shield and Douse', against SnB 'Slash and Burn'. However, also as mentioned above, the structure SnB allows fairly easy future alteration such that it won't be too difficult to route around my current solution. I'm working on my own to 'guess ahead' so to speak, but to anyone qualified and capable, I'd like to ask the following:

You take a copy of what we have on SnB, and alter it such that it still works even while under the influence of SnD. Send me the result, and I'll in turn patch that route as well, repeat, and so forth. By the end, we should have a much sturdier result that's several 'steps ahead', so to speak. I've attached both what we have on SnB and my current version of SnD below. NOTE OF CAUTION: Be sure to set up a proper testing environment, either a well-sectioned partition or free system altogether to avoid any risk of slip-up and... well, wiping your system!

Current Modifiers
-Challen Ravess
-Ralf Derrison
-Sokai Hemmingway

Thank you for your assistance,
-Crono Arinborn

***Attached to the message is a link which, when followed, triggers a request to download the mentioned SnB and SnD for study and alteration, which will be sent to Crono to approval.
Crono
Crono

Number of posts : 50
Age : 31
Location : Washington State
Registration date : 2009-03-19

View user profile

Back to top Go down

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum