Jump to content
Sign in to follow this  
hisoka

periods with unicode characters in a decrypted message

Recommended Posts

I decrypted a message by using a software and got a mixture of Unicode characters . This is , indeed , what I got :

3d 28 9b 49 e1 e4 99 8f a5 20 4c 64 4c 69 98 64   =(.I..... LdLi.d
4f 70 99 6b 6e b9 7a 5d cf 4f 02 68 47 76 0a 89    Op.kn.z].O.hGv..
02 6a c8 90 58 0d 02 60 7a 05 35 ef 19 1d d6 5f   .j..X..`z.5...._
e4 a1 da 97 85 45 44                                                   .....ED  

I have two questions :

1) what are these little periods on the right side ?

2) do they belong to the decrypted message ? I mean is this the decrypted message =(.I..... LdLi.dOp.kn.z].O.hGv...j..X..`z.5...._.....ED   or  this    =(ILdLidOpknz]OhGvjX`z5_ED  ?

 

 

Share this post


Link to post
Share on other sites

Those are typically how they print non-printable characters or extended ASCII characters.  If you look up the hex codes for those characters you'll see what they represent, but if this is Unicode then that is a multi-byte format, so several of those bytes probably make up one character.  A hex editor will not show you that, hex editors only show the byte stream converted to hex.

Share this post


Link to post
Share on other sites

I think these are extended ASCII characters . Extended ASCII characters are Unicode characters too . I do not think it is a multi byte format character :)

Unfortunately , you did not answer my second question :

2) do they belong to the decrypted message ? I mean is this the decrypted message =(.I..... LdLi.dOp.kn.z].O.hGv...j..X..`z.5...._.....ED   or  this    =(ILdLidOpknz]OhGvjX`z5_ED  ?

 

Share this post


Link to post
Share on other sites

Neither of those are the "decrypted" message.  Hex is not encryption, and it is not decryption.  And those periods are not the actual characters, that is just how the hex viewer you're using  shows those characters.  A period is 2E in hex, so if you're not seeing a bunch of 2E bytes, then it's showing periods instead of the extended characters.  In short, you have a hex viewer that is showing you characters in the 7-bit ASCII character set (not Unicode), and it is using periods for any characters outside of that range. 

The only reason I mentioned multiple bytes is because you claimed it was Unicode, and Unicode is a multi-byte character set.  If that text actually is supposed to be Unicode, then open it with a text editor that supports Unicode.  Copying and pasting won't work either, you need to save it as a file and open it with a program where you can specify to use Unicode to open the file.

That assumes that the text actually is supposed to be Unicode, I'm just taking your word on that.

Share this post


Link to post
Share on other sites

Thank you for correcting me .

This is a ciphertext :

§ƒÜì ©©”Ѫÿƒ_G¢4Ø{i§çÞ“./

when I put this ciphertext here in this site :

http://www.charactercountonline.com/

 some others 4 weird characters were shown : one character after the / and two characters between the ì and the © and one character between ¢ and 4

what are those characters ?

do they belong to the ciphertext ? will they be decrypted with the other characters ?  or they do not belong to the ciphertext and can be ignored and deleted ?

 

 

Edited by hisoka

Share this post


Link to post
Share on other sites

I'm not sitting there watching you, but when you are encrypting and decrypting data you are not dealing with "characters", you're dealing with binary data.  If you open it in a text editor, the text editor will try to convert it to characters and show those, but it is not character data, it is binary data.  You need to understand that, I've been trying to make the point that you are dealing with binary data, not text.  If you copy and paste that binary data around you might be losing information depending on how you're copying it, because you're probably copying it from a program that is trying to display it as text.  It is not text.  It is binary data.  Do not treat it like text.  When you encrypt data, it does not change each character to a different character, it transforms the entire binary stream.  It does not look at the data as a series of characters, it looks at the data as a series of bits.  That is how you need to look at it.  You keep looking at it like it's text.  The encrypted data might not even be the same length as the original data.

So, I'm not sure what the purpose of pasting this into a website to count the characters is, and there's no reason to try and paste it here.  It's just binary data.  The reason you are seeing different characters in different situations is, again, because you are treating it like it's text and it's not.  Different programs might display binary data differently, especially if they're treating it like text.  The only way to view binary data is in either binary or hex format, which are 2 different representations of the same data.

With that text you pasted above, that contains Unicode characters.  So, whatever you're using is treating it like Unicode text.  Like I said, Unicode is a multi-byte character set.  So, some programs might group the bytes into Unicode characters, and others might try to treat it as ASCII and show each byte as a character.  That means they will have different lengths.  Again, this is because you are treating the data like text when it is not.

All of your confusion is due to the fact that you think you are looking at text.  You are not.  You are looking at a text editor trying to show you binary data, which it was not designed to do.

 or they do not belong to the ciphertext and can be ignored and deleted ?

Why would that ever happen?  Why would encrypting or decrypting data result in characters that you should ignore?  That seems like an awful quality in an encryption algorithm.

  • Thanks 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×