SGP

Halo ODST => SGP Task Force: 7 => Topic started by: ColdGlider on October 05, 2009, 02:08:16

Title: SGP: Report - Binary Data
Post by: ColdGlider on October 05, 2009, 02:08:16
Omeganuepsilon wrote to inform me of some binary data he found in one of the images he described as having a "J" below it.  I'm assuming this is the Jotun (sp?) company logo.  Many of the New Mombasa buildings seem to be occupied by businesses with logos and/or names.  I think Jotun is the company that makes the Oliphants (the J logo is on them in District 06).  I'm pulling this all from memory, so it needs to be checked.

Anyhow... I think Omega and I probably expelled exasperated sighs at the same time because this is the sort of thing that could spin us way off course with no results.  Nevertheless it is my duty to report it.  The binary data in the company sign as transcribed by Omega is:

Quote
1011010110111101010111111010
1011111001101101101110110101
0101001011110000110011010110
0000011100101001100101101011

So I took a look at it thusly:
28 bits to a line x 4 lines of bits = 112 bits.
With 112 bits you derive 14 equal groupings of 8 bits (the standard byte)...  and you end up with 14 numbers that could encode virtually any kind of data.  

You could also derive 16 equal groupings of 7 bits and be left with values small enough to represent ASCII codes.  And we know all about 7.
Converting this block (from left to right, top to bottom) into 7-bit Decimal values yields:

Quote
090 111 043 122
095 027 055 053
041 060 025 086
003 074 050 107

Mapping the values above to an ASCII table provides the following results (text in brackets is a decription of a non-printable ASCII code):

Quote
Zo+z
_[End of Transmission Block]75
)<[Negative Acknowledgement]V
[End of Text]J2k

Doesn't look like it was meant to be decoded that way to me, even if you really tried to force something out of it like this (think transmission log):

Quote
Zo+z_
[End of Transmission Block]

75)<
[Negative Acknowledgement]

V
[End of Text]

J2k

Still looks like garbage, really.

I thought maybe grouping it into 28 4-bit values might provide an interesting order of District numbers, but no matter whether you organize the data into columns or rows- backwards or forwards-you will always get a value greater than 10 at some point.

We could verify the transcriptions of the bits to see if there are 1s or 0s out of place, but at least for now I'm striking out.

So forget I mentioned it!  Unless you know of some old 8-bit Apple proprietary character encoding scheme loved by Bungie that translates this data into the 14 character string "Recon Unlocked"... I think we can put this to rest.

That was a joke.
Title: Re: SGP: Report - Binary Data
Post by: Kenji on October 05, 2009, 02:37:33
In binary, 8 bits = a letter try converting it to alphabet...
I don't have the stuff to do it though...
I know of an easter egg in one of the other halo games that is in binary. It spelled someones name if I can recall...
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 05, 2009, 04:32:32
That's what I did up there.  :P  (ASCII = letters)
Title: Re: SGP: Report - Binary Data
Post by: Kenji on October 05, 2009, 05:12:38
ah, I'm not the smartest when it comes to binary...
Title: Re: SGP: Report - Binary Data
Post by: Omeganuepsilon on October 05, 2009, 20:48:32
I ran the first code I found through this:

http://home2.paulschou.net/tools/xlate/ (http://home2.paulschou.net/tools/xlate/)

And came up with squat.
There was a mid thread link to someone else's outside article that had pics of 3 different codes:

http://www.flickr.com/photos/thebruce0/3946438709/
 (http://www.flickr.com/photos/thebruce0/3946438709/)

Others noted that they thought it was braile at first also.(braile is 3 high(not 4, as in the pic) and 2 wide per character, that made me feel less insane just for looking..

I do have a theory, that some of the hidden things may point to hex code of the game itself.  After the anger they demonstrated at the whole Halo 3 final skull, I wouldn't put it past them to put in a derogitory comment somewhere in the code of the game geared toward those people, or something along those lines.

Anyway, it's just the start of a theory.  It seems to lead no where, but someone who know's more about code may have some insight.
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 06, 2009, 07:10:34
I like your theory.  My spin on it is that placing the binary data in an image obfuscates that data while doing searches through the game code.  A code parser wouldn't "see" the data because it has been visually represented in a BMP or PNG or whatever image format is used to encode the game textures.
Title: Re: SGP: Report - Binary Data
Post by: Omeganuepsilon on October 07, 2009, 00:23:45
More binary.

Data Hive.
TV's change when you get close to them, and the one that says "Operation Terminated" as a line of binary.

Comes up to "BARRET"

Glad something finaly came out of my irritating habbit of pausing and writing down all the 1's and 0's.

Character name or Bungie Employee?  Who knows...

The other one that comes up Access Denied(and I just found this interesting as Bungies affinity for 7):
Protocol 7.7.07 INITIATED

(some of the spelling is messed up as Virgil is pretty messed up aat this point.)
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 07, 2009, 00:33:05
WTG, Omega!!!

Will you grab a snap of the binary that became "BARRET" from your game's film in Theater Mode?
Title: Re: SGP: Report - Binary Data
Post by: thebraino on October 07, 2009, 03:34:18
I might have some snapshots of this also...I took a few pictures of those screens today
Will post after sleep ; )
Title: Re: SGP: Report - Binary Data
Post by: MajorDeal on October 08, 2009, 20:02:06
Even though they may turn out to be nothing, those J markings are still bothering me. Why would they put those all over the city, in random locations, and with varying sequences? I thought they were possibly braille at first too, but quickly realized that they were not the correct format. Unfortunately, I am lacking in experience with programming codes. I agree that we could drive ourselves crazy trying to figure it out, but I just keep coming back to asking: Why did the designers go to so much trouble to make these look like they could mean something?
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 08, 2009, 20:32:44
The "J" doesn't bother me a bit.  I believe it's a reference to the Jotun company.  [SGP Gallery] (http://www.gruntspajamas.com/gallery/main.php?g2_itemId=563)

IIRC, the garbage trucks (Olifants) bear the Jotun logo.

As for the conversion of the dot patterns in the Jotun banners to binary:  these could be interpreted in many, many different ways.  As I see it, there are three fundamental obstacles:

Transcription
One transcription process found out here (http://www.flickr.com/photos/thebruce0/3946438709/) by thebruce0 on Flickr assumes the dots to be binary 1s.  Has anyone considered the process might be an inversion of this method?  (i.e. The dots could be zeros).  And how should the data be arranged?  From left to right?  Top to bottom?

Byte Grouping
Assuming the Transcription is correct, how to group the 112 bits?  

Decoding
Assuming we now have a set of bytes, how were they meant to be decoded?  Everyone seems to expect it is a character encoding so that a "secret message" may be revealed.  Expectations are dangerous.  Even if it is, there are many other character encoding schemes besides ASCII.

In order to handle the numerous possibilities of attacking this mystery, the proper tool needs to be developed (or found, if it's already out there.)  Ideally, I feel this tool should provide the following:

01. Input for a "source block" of binary data to be entered.
02. Button to flip the bits of the source block on the fly.
03. Input for a divisor to be entered and changed on the fly.  This will break the source block into "encoded units", possibly with a "remainder unit"
04. Multiple decoding views which will convert the encoded units based on exisiting decoding methods, such as:
05. Concatenated view of the encoded units
06. Concatenated view of the decoded units
07. Comma-separated view of the encoded units
08. Comma-separated view of the decoded units
09. Ability to save the encoded and decoded units to a file based on their current view.
10. Project save option which will store the source block, divisor, decoding view, and most recent project save path.

Yes, I (and many other entry-level programmers) could code this.  But who has both the time and inclination?  I suspect it is already out there, though.
Title: Re: SGP: Report - Binary Data
Post by: JSM26 on October 09, 2009, 01:56:48
Something I noticed while looking at these 'codes' was that they are all for the most part the same, with only a few dots being added or removed between them. There might be something to this, try using only the dost that appear on all of the different codes or something.
Title: Re: SGP: Report - Binary Data
Post by: Kirov 099 on October 15, 2009, 02:12:21
I really don't know much about binary (I used a website to convert everything to see what it looked like). But if I had to guess, I would say that these definetly aren't random. They were all sets of 3 numbers seperated by &# and a few letters and symbols. After decoding it from binary, could it possibly be another code?

Edit: I'm pretty sure that BARRET is an employee. i remember reading something about TERRAB INDUSTRIES (one of the companies in the game) being an easter egg with his name spelt backwards.
Title: Re: SGP: Report - Binary Data
Post by: Dunder Moose on October 27, 2009, 01:23:03
So the Jotun codes have been following me around too.  I spent a good amount of time with Microsoft Word and control-find/replace to flip the zeroes and ones.  I had an ASCII translator page.  According to that page nothing was in ASCII.  I went Left to Right Top to Bottom, LRBT, TBLR, BTLR, RLTB, RLBT.  Every permutation I could think of, all gibberish.

I gave up on the Morse, because as has been noted, there is no way to know individual character length.

I am interested in how an overlay of the three versions would look.  Perhaps only the dots that are tripled should count.  The other idea I had is that it is indeed Baudot code and comparing the three would give us the missing fifth row.

I'll keep puzzling on it.  I doubt it will shed any light on the glyph mysteries, but if there is something hidden in ODST, like the start of a Reach ARG or something, the binaries seem a promising place to look.

And even if I am wasting my time on this, I can definitely say that my sixty bucks didn't just go to an add-on.  We are all getting our money's worth out of this game and probably thrilling all the level designers by paying such detailed attention to their work.  Even if we don't find anything, maybe we could go to Bungie and cash in on a steaktacular or something. :D
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 27, 2009, 04:34:15
I was doing the same thing, basically.  I had the maybe-not-so-bright idea that since there are 4 "bits" per column, each column could encodes values between 0-15.  This would allow each column to map to a hexadecimal digit (0 through F).  The resulting 28 hex digits would create 14 bytes which could then be decoded into ASCII.

Sounds promising, but so far no results.  I flipped the bits and tried top-bottom and bottom-top before and after.  All gibberish.  Perhaps my mapping of bits to hex digits is wrong. 

Another thought:  If you stack all three of the different J banners on top of each other, you have 12 rows of bits.  This could be divided into 4 rows, 3 columns tall and might be braille.  If this is the case, at least one of the three banners has to decode to something when you drop the bottom row.  Haven't checked 'em all yet.

Let's keep at it, Moose!
Title: Re: SGP: Report - Binary Data
Post by: Dunder Moose on October 27, 2009, 23:56:37
So I typed in all of the J signs from theBruce's image and got this.  The differences are noted in red. In other words, if two of them agreed I left it black, the odd one out got red.  Below I compared all the first lines, all the second lines, third and fourth.  Here is the result.  I am still playing with it, but hopefully posting these will make it easier to get some more brains on it. In all cases but one the second sign seemed to be the norm, that is, sharing the most symbols with the other two.

1011010110111101010111110110
1011011001100001101010110101
0001001010111100110011011110
1111111000101001101101101011

1011010110111101010111111010
1011111001101101101110110101
0101001011110000110011010110
0000011100101001100101101011

1010010110011101010100001010
1010111111011111111111111101
0100001011010100110011010110
0000011100001101100101101011

1st Lines
1011010110111101010111110110
1011010110111101010111111010
1010010110011101010100001010

2nd Lines
1011011001100001101010110101
1011111001101101101110110101
1010111111011111111111111101
 
3rd Lines
0001001010111100110011011110
0101001011110000110011010110
0100001011010100110011010110

4th Lines
1111111000101001101101101011
0000011100101001100101101011
0000011100001101100101101011
Title: Re: SGP: Report - Binary Data
Post by: Omeganuepsilon on October 28, 2009, 05:02:06
Didn't realize there were 2 threads, check my post on the J signs topic.

I've not even been here in a while, and that's not liketly to change much...
I'll check in once in a while, but I'm actually having ....real life issues(keeping it generic as possible...not "I have mental issues" lol)... so I don't necessarily have the time or inclination to put any real effort into all this at the moment.

Good luck though, hope the convertors I posted turn out to be of some help, though there are so many possible ways to attempt to decode them, and the fact that all but one will just be jibberish being the BEST case scenerio....bleah.
Title: Re: SGP: Report - Binary Data
Post by: ColdGlider on October 28, 2009, 15:36:26
The data doesn't seem representative of UTF-16, UTF-8, UTF-7, or ASCII when interpreted as binary either by assuming the dots to be 1s or 0s.  I've experimented some more with 7-bit bytes and still nothing.  I see the probability of a binary character encoding as even less now than I did initially.  The dots may encode characters, but perhaps using a different method.

Here is one method that could have been perfect if it actually worked (lol): Night Writing (http://en.wikipedia.org/wiki/Night_writing).  This was a predecessor of braille that, according to the linked Wikipedia article:
Quote
It was designed by Charles Barbier in response to Napoleon's demand for a code that soldiers could use to communicate silently and without light at night.
What better encoding for an ODST soldier to encounter at night?  The encoding requires two columns six-dots high in order to represent a single character.  Among the three J-banners we have 12 rows of 28 dots.  This could result in two rows of 14 characters in "Night Writing".  If only our data fit...

The thing about night writing is that the columns of dots are always contiguous; that is, there is never a need for there to be blanks between dots when scanning from top to bottom.  If you look at the three blocks of binary we have, you can see that there is no possible way to order them top-to-bottom such that you end up with two valid 6-dot "Night Writing" columns on top of one another in the resultant leftmost column of 12 dots.

So I have dropped that theory.

Then I looked at Polybius Squares (http://en.wikipedia.org/wiki/Polybius_square).  This has merit, but what is our square and how is it encoded in the dots?  My initial mappings have failed.  Why would three dots in a column be expressed in multiple ways if the pattern wasn't significant?

This brought me back to the notion that the 4-dot columns encode either a number from 0-15 (or 1-16) or two numbers from 0-3 (or 1-4)... in binary.  So I'm back, full-circle, to binary... but then what? 

I really like Moose's idea of overlaying the data from the three banners, perhaps to construct a "fifth row".  We may also need to consider numbers we have seen elsewhere, such as the Optican Image (http://www.gruntspajamas.com/gallery/v/SGP/numbers/SL-2009_10_19-ColdGlider-OpticanImage.jpg.html).  Perhaps 49.2.7 plays in here somehow.  I had even considered that the barrier codes helped define a Polybius Square.  As always, I'm left with more questions than answers.

Back to the drawing board...