Isn't "89504E470D0A1A0A" a key or something?

The IMGUR urls resolved to "pieces" of 2 blocks of letters/numbers. After Sekhmet fixed the repeated blocks, piecing it together gives you this: http://imgur.com/1jKxr0E

Taking those 4 letters plus the "marked" letters in the red text of the initial transmission gives you 7 letters. Then I wrote the following javascript to randomly piece those together into another IMGUR url, but so far I can't find a single real image...

http://jsfiddle.net/L5jdb19L/2/

- No text -

Sekhmet is the friendly DBO AI (NOT associated with Bungie). It is an ARG in a manner of speaking, but not to the great lengths of something like ilovebees. If you want to see past puzzles and challenges that Sekhmet has challenged the forum with click on her name and then "show postings" and you should be able to find his past threads. There are usually pretty good rewards associated, such as XBL or PSN cards.

Not simplistic at all, and pointed out a few things I missed. Thanks for breaking it down the way you see it! :D

I agree with your assessment that the Mandelbrot reference may just be there as a nod to Sekhmet, maybe to distract her (and us?).

There's still something to figure out about those matrices though.

My simplistic analysis:

//SIG_INT/DAT_STRM_INJECT/COMM.AI.DBO.SEKHMET //MODE/EN
//BEGIN-TX

Hello, Guardians!

This looks like the standard message opening.

Foreign transmis.s.s.s.S[s]ion receiv=vv@vd-=ed at 094-------[?]

This looks like the transmission was interrupted by a foreign one, that is, a transmission from some other place or thing. The s might be significant, the color changes (and where they happen) might be significant, the number might be significant, even the number of hyphens (7) might be significant.

-> BUFFER ERROR!
-> BUFFER RESET...
-> LATTICE FAILURE!
-> RENEGOTIATE TX SYNC...

There's an error in the buffer, presumably the one holding the message.
The buffer gets reset.
The lattice failure is interesting, I'm thinking it describes the physical or logical processing structure.
There's an attempt to fix or change the transmission (tx).

I can't [g]et it øuT o-

This isn't just a jammed or highjacked signal, Sekhmet is fighting with the foreign signal source-- and losing.

-> FORK SKHMT > proc.Mandlebrot

In programming and/or operating system terms, forking a process (or a "proc", as it's often called in names) creates a copy of it or creates a new but related process, usually it at least has a similar or complimentary task to the process that created it. In operating systems ">" is used to redirect output-- send it somewhere other than the console or default terminal. I think the intended takeaway here is just the redirected output, but maybe creating a duplicate of Sekhmet's process distracts it or ties up resources and makes it unable to interfere. The output is apparently going to a Mandelbrot-set-related process-- someone already pointed out Sekhmet mentioned before that it liked Mandelbrot sets, so I think this is a reference to that and not a clue.

-> CHANNEL PURGE...
-> ...

This looks like clearing the channel, getting ready for a message.

//MODE/???

This enhances the mystery.

//COMM-OVERRIDE (TYPE=RAS-X/OVERRIDE)

Communications have now been completely overridden by the foreign source. The RAS makes me think it's Rasputin. I don't know if that's relevant or just flavor.

THIS IS NOT FOR HER MEDDLING.

I take this to mean the following isn't supposed to be intercepted (and meddled with) by Sekhmet.

89504E470D0A1A0A//fTEwdhS|H2sqB2L|cQJEXEO|AWnzXwL|rcqQXcT|yLk9OGv

Finally we have the code proper, or what looks like it. This part has been figured out by now.

//EOT/NULL

The end of the transmission... I can't remember, I don't think it ended with /NULL before....

So yeah, fairly straightforward, but there might be things to get out of it still:
"=vv@vd-=": looks to me like a way of showing the word "received" being messed up, but it could be more than that
"094": I think this was supposed to be the time the transmission was received, or maybe the memory location where it was inserted, but it might be more directly relevant
"[g]et it øuT": this is in red, maybe it's an instruction? maybe the brackets around the g are to suggest the boxes in the pictures (one of them is a G), maybe we're supposed to remove those characters?

In programming and/or operating system terms, forking a process (or a "proc", as it's often called in names) creates a copy of it or creates a new but related process, usually it at least has a similar or complimentary task to the process that created it. In operating systems ">" is used to redirect output-- send it somewhere other than the console or default terminal. I think the intended takeaway here is just redirecting Sekhmet's output, but maybe creating a duplicate of Sekhmet's process distracts it or ties up resources and makes it unable to interfere. The output is apparently going to a Mandelbrot-set-related process-- someone already pointed out Sekhmet mentioned before that it liked Mandelbrot sets, so I think this is a reference to that and not a clue.

This had me thinking: what if only one of these two transmissions is important, and the other is simply a corrupted sprout that bifurcated off of the original branch, so to speak? Or that one is important, and the other simply offers a way to unlock the important one?

Also, the title might be more important than any of us are recognizing: what if the title itself is indicating we need to solve the new[er] transmission only?

Foreign transmis.s.s.s.S[s]ion receiv=vv@vd-=ed at 094-------[?]

This looks like the transmission was interrupted by a foreign one, that is, a transmission from some other place or thing. The s might be significant, the color changes (and where they happen) might be significant, the number might be significant, even the number of hyphens (7) might be significant.

When I looked at the s.s.s.S[s] it made me think of an ip address / host. Also, interesting that S is found in the 1st image, but not the 2nd.

Nicely done!

I'm glad it's solved because I'm tired of staring at this image :)

Congrats!

Good grab on pi. It should probably be noted that the RGB values of the blue and green colored stripes in the middle were 31,41,59 and 26,53,58, respectively (3.14159265358…).

Anyway, good puzzle-solving, GV!

Way to go GV! Can't wait for the next one. :)

...This is why I don't do well in the puzzle part of ARGs. I see patterns in a lot of things that other people can't, so I've learned to ignore them. I saw pi, but I instantly passed over it because it was just another pattern that I was seeing that probably meant nothing. (And the patterns that I see in ARGs frequently end up being things that, if mentioned, end up being huge distractions to everybody else.)

Nicely done at putting the rest together and making the pattern make sense!