Need help! Recovering scrambled bits!

I don't now the answer but a few points.

Number one - you MUST use a hex viewer to look at the data

Number two. The code 0xbf occurs on it's own many times. If the data is a text message it may indicate a space.

Number 3 0xe5 is always followed 0xeb. What is the most common two character sequence in text? (clue non printing)

Your skill is to find patterns. In over 30 years of data manipulation, reverse engineering I know almost anything can be used.

A true story - I once spent a long time trying to decode an embedded number field on an optical disk. Eventually I realised the number was based on a different base, ie not 10 or 16. I was very amused when I discovered that the answer to what base (question) was 42.

Mind you not necessarily the frequencies of letters in the given text or word patterns will help you solve the problem.
It is only one of the possible preventive analysis of the text that you should carry.
Without any further data, hint or information about the kind of transformation algorithm that produced the given results, you are posed before a kind of textual puzzle, which may well be analyzed linguistically.
And maybe it is just another red herring.

The "scrambled bits" you provided is exactly 0x155 or 341 bytes in length.

Not so casually wink the following snippet of the above text

It is only one of the possible preventive analysis of the text that you should carry.
Without any further data, hint or information about the kind of transformation algorithm that produced the given results, you are posed before a kind of textual puzzle, which may well be analyzed linguistically.
And maybe it is just another red herring.

is also exactly 341 bytes in length.
Try copying the above quote and pasting it in a hex editor, and check it.

You should be able to see some patterns.

Like the most common character being actually 0x20 (space), like being there a few occurrences of 0x2E 0x0D 0x0A (period+CR+LF), and if you create and look at the histogram you see how, set apart the space, most of the "peaks" are between 0x61 i.e. 97 and 0x7A i.e. 122.
As well in the actual "scrambled bits" you may see some anomalies, like the occurrence of sequences of three "same" codes, 9F9F9F and 111111 which is something that very rarely happens in properly written/formatted text, and that thus will need to be somehow justified, or maybe it is a hint towards the use of a form of encoding/scrambling/whatever algorithm that is not a simple "code shift" or modification at the single byte level.

More generally I tend to refuse to believe 😯 (though it is of course well possible) that your professor/teacher did not provide you with the means of resolving this puzzle, by way of what specifically was taught you or through the exact wording of the question, or because a limited number of specific algorithms were th etopic of the connected lesson(s) or that he/she gave you an unresolvable puzzle, just for the fun of it ? .

jaclaz

Hi Jaclaz,

Slowly, I understand what do you mean looking at patterns. I guess that the 0xbf in the scrambled bits is space. So that means by analysing this kind of files I have to guess each hex code? Is there another method, for example, through any calculations?

I've paste that text that is also exactly 341 bytes in length. The space in that text is in hex code 0x20 but is there any connections between 0xbf to 0x20?

BTW, this is the slide that our lecture show us without any deeper explanation
Bit-Shiting

-Some users use a low-level encryption program that changes the order of binary data
-Makes altered data unreadable To secure a file, users run an assembler program (also called a “macro”) to scramble bits
-Run another program to restore the scrambled bits to their original order
-Bit shifting changes data from readable code to data that looks like binary executable code
-WinHex includes a feature for shifting bits

There is a sentence (Run another program to restore the scrambled bits to their original order), so there exists a program that restore scrambled bits?

@mscotgrove, yes I'm using 2 hex viewer tools, one is Winhex and the second is Hex Workshop. Do you have more hints?

Has anybody here find the solution, if yes it was difficult or it is an easy task?

I had some spare time to look at the "scrambled bits".

It is relatively easy to transform them into the original content, and I can confirm (without giving away the solution) a few things

1. the already given hints (as expected wink ) fully apply to the specific text
2. the content is plain enough English
3. it comes from a recent article published on an online magazine
4. there is seemingly one error 😯 (either due to transcoding or copying) in byte at offset 0x146 which is 0x9A but should IMNSHO really be 0x9B (but this of course does not affect the rest)

[/listo]

depende, you are seemingly taking it the "wrong" way, in the sense that you are looking at it thinking of "scrambled", "mathematical" transformation etc, which is loosely correct BTW but what you are doing is essentially the decrypting of a crypted message, more than pertaining to "digital forensics" (or "digital") you have to think at the challenge as solving a puzzle, the hex editor and the use of hex codes are only "means".

Of course there is a coding or crypting algorithm behind every such puzzle, but usually you first find the solution and only later reverse the transformation algorithm used.

But it is possible to use your line of reasoning, once you have *something* logical to try.

Your approach was to "blindly" throw a number of "random" trasformation algorithms to the "scrambled bits" (and you failed), now that you have been given an hypothesis to follow, try to actually follow it, i.e. assuming that actually the "original" hex code 0x20 is corresponding univocally to the hex code 0xBF

1. find and describe an algorithm that can transform 0x20 into 0xBF
2. find and describe it's reverse one (i.e. one that can transform the 0xBF to 0x20)
3. try applying the algorithm in #2 above to the whole file

[/listo]

For the record (and in my simplicity) the text accompanying the slide(s) is however far from being accurate (BTW I am very picky).

• low-level encryption program -> Hmmm, no, this is not low-level or high-level, it is is "simple" or "elementary".
• an assembler program? -> Hmmm, I actually used an Excel spreadsheet to solve the puzzle, but as a matter of fact I could have used some paper and pencil for the decryption, and as well I could have used the same means for the actual encryption.
• also called a "macro"? -> Hmmm, I definitely did not use any assembler in it, nor a "macro", just good ol', plain, spreadsheet functions.
• looks like executable code? Hmmm, NO, it looks like hex gibberish, definitely NOT like "executable code", this is exactly one of the reasons why looking at a hex file through it's frequency histogram allows to usually guess if contents of a file are what they should be.

jaclaz

I think a big link between 0xBF and 0x20 is the number bits - if you invert the values

ie ~0x20 is 0xDF and ~0xBF is 0x40

(It shows how important thinking in Hex is)

(It shows how important thinking in Hex is)

Hmmm, in this particular case I would find easier to think in binary.

jaclaz

I think a big link between 0xBF and 0x20 is the number bits - if you invert the values

ie ~0x20 is 0xDF and ~0xBF is 0x40

(It shows how important thinking in Hex is)

Ok, I understand that after having find the right pattern and assuming that 0x20 is 0xBF which would be mean 'space', why do you convert 0x20 to 0xDF?

Your calculation

1. 0xBF - 0x20 = 0x9F
2. 0x20 + 0xBF = 0xDF
3. 0xDF - 0x9F = 0x40

But I don't see any clue that can help to calculate the other values.

I thought after knowing that 0xBF is 0x20 than I have to calculate the difference between them like 0xBF in decimal 191 and 0x20 is 32 which is decimal 159. But it looks that I'm on the wrong way right?

But it looks that I'm on the wrong way right?

Well, your lesson included this text

-Some users use a low-level encryption program that changes the order of binary data
-Makes altered data unreadable To secure a file, users run an assembler program (also called a “macro”) to scramble bits
-Run another program to restore the scrambled bits to their original order
-Bit shifting changes data from readable code to data that looks like binary executable code
-WinHex includes a feature for shifting bits

Maybe, just maybe, you need to manipulate bits. roll

Can you see bits in decimal?
Can you see bits in hex?
Can you see bits in binary?

Be warned, people that find math jokes actually fun are a minority
http//en.wikipedia.org/wiki/Mathematical_joke#Jokes_with_numeral_bases

though the best available explanation of binary comes from Clint Eastwood (directed by Sergio Leone) wink
http//reboot.pro/topic/910-favourite-films-movies-etc/?p=164583

jaclaz

(It shows how important thinking in Hex is)

Hmmm, in this particular case I would find easier to think in binary.

jaclaz

I just assumed (probably wrongly) that everyone who understands Hex, can also 'see' the binary makeup of the numbers. Hex is just shorthand binary

ie 0xBF is 1011 1111
0x20 is 0010 0000

However, for those who still occasionally think in decimal, the relationship between 191 and 32 may be rather obscure.

I got the solution, the first word is 'The' and the last is '2 March 2015'!!! lol

And you know what is funny? I've used WinHex and with totally 2 clicks I've got the result.

But I'm still interested in your solution jaclaz. If you not mind could you please send me your solution per PM. I would really like to understand how you got that solution without using a hex editor tool.

Thanks!