Remember when you were a kid? You might have had one of those crazy rings that let you send secret messages to your friends. Secret messages that you would write to your friends weren’t truly secret, but it was novelty and just fun knowing that other people didn’t know what you were talking about. These rings are called decoder rings and use simple Caesar cipher substitutions. Secret characters were achieved by rotating the alphabet, assigning each letter a new value. Your message in the hands of someone with 30 minutes of free time could be easily cracked, giving them the ability to read all of your messages. This feeling of nostalgia is what gave me the urge to build a chrome extension that encrypts your Facebook messages from end-to-end. Not only would it be fun, but also secure. What is end-to end encryption? End-to-end encryption means that your messages are fully encrypted before they leave your computer. This makes it so that people can’t steal your messages while they are being delivered to the server. This also means that the messaging platform you’re using can’t read your messages. I like to think that anytime something leaves your computer it’s like leaving your house. You wouldn’t go outside naked right? Put some clothes on your messages! Encrypting your message will turn it into a string of gobbledygook: This is a secret! Original Message: MyjDqDUIATABEiEFwoMPwqvChMKkV3gUL8KKYsKKcDXDq2zDhsOUcsKuw7/CvhYmw4wdGkzDmiDCk0QaIQXCvsOMOkARwoJrEWDDrFkCYwfCnx7DrS8zwoPDkcOwLxQCFMOuw6fCnsOSw6MBIlIzCiEFF8OhwoNQeQEkw74CwqbCiiDDjnoHwpYgTMKwwrtvwofCqA42w4/DqWI7QikNEAAYACIgwrMXwp0/w7DDusOHTMOXwp3Co0XDr8K1KcO5wpROwr7DhsKUU8ONwr4jw4wiwptSDzXDs1vDssKOwr42H8Kawo0= Encrypted Message: Great! I doubt anyone would be able to read that! However… your friend needs to be able to read that 😝 Asymmetric encryption If you want your friend to be able to unlock your message they will need the key to the lock. If it was our lock, we could just send them our key! Butttt…. we don’t want to just send them the key right? Because then someone can steal the key and unlock our message 😵 So what do we do? We can get around this problem by using “asymmetric encryption”. Think of it like this… When you want to send your message, ask for a lock. They should be the only ones with the key to this lock. Now when you lock and send it, only your friend can open it and you don’t have to exchange any keys. them With asymmetric encryption you are dealing with pairs of public and private keys. Public keys can be thought of as the unlocked lock and can be freely distributed to all your friends. Private keys are the actual key and are to be kept top secret in a safe place. Hacking Facebook’s messaging api In order to send encrypted messages we need to figure out how to send regular messages. This is the core information needed to send a message through Facebook: Your friend’s Facebook user ID ( ) RECIPIENT_ID A unique message ID ( ) MESSAGE_ID A token ( ) fb_dtsg TOKEN A cookie as your credentials ( + ) C_USER XS The recipient ID, token, and cookie can be easily grabbed from inspecting Facebook Messenger’s network activity. fb_dtsg You have to send a message after you open the network panel. Note: Message IDs, on the other hand, have to be unique. If message IDs clash then the message will never appear. How does Facebook generate its IDs? 6306169721153220898 1503508024490 message_id: timestamp: I found that dividing the message_id by the timestamp equals ~4,194,304. This happens to be a power of 2 or 2²² to be exact. Facebook shifts the timestamp to the left by 22 bits and fills in the empty bits with a random number. Here is an example cURL command for sending a message: curl ' \-H "cookie: \c_user= ; \xs= ;" \-d "action_type=0\& body=My message.\& has_attachment=false\& message_id= & offline_threading_id= & other_user_fbid= & source=0\& timestamp=0\& fb_dtsg= " https://www.messenger.com/messaging/send/' C_USER XS MESSAGE_ID MESSAGE_ID RECIPIENT_ID TOKEN Be sure to replace , , , , and with your own values. Note: C_USER XS MESSAGE_ID RECIPIENT_ID TOKEN (For testing purposes, it is safe to just add 1 to the last sent _MESSAGE_ID_ ) Chrome extensions! Now that we can send messages, we need an actual interface. Chrome extensions give you a tremendous amount of power. You have complete control over any website. You can restructure html, manipulate css, and even inject scripts. If the user is on Facebook Messenger you can steal their cookies and determine which user they are talking to. This is exactly what we need. Building an extension is easy to do if you have some experience with web programming. It’s just like building a website, on top of a website. If not, have no fear, Google has a very thorough for building extensions, along with some helpful sample projects. walkthrough Since I don’t want to turn this into a tutorial for chrome extensions, I will just leave you with the for the project. (Don’t hesitate to contact me if you need some additional help) source code To run your extension, follow these steps: Visit in your browser chrome://extensions Ensure that the checkbox in the top right-hand corner is checked. Developer mode Click to pop up a file-selection dialog. Load unpacked extension Navigate to the directory in which your extension files live, and select it. Using a library and some of the tradeoffs As noted earlier, we need to use some form of asymmetric encryption. It’s a good idea to use a battle tested library when dealing with security. From what I’ve found, is the go-to encryption for messaging. It leaves a lot of room for implementation freedom, because Signal is just a protocol. This freedom lets us deal with a few tradeoffs. WhisperSystems’ Signal Protocol Reading your own messages When encrypting a message for your recipient, it’s encrypted in such a way that only the other person’s private keys can decrypt your message. Not even YOU can decrypt the message. If you want to be able read your own messages there are a few approaches. One way is to encrypt it twice, once for you and once for the recipient. This is a bit slower because we have to encrypt everything twice. It’s also a tad less safe. The recommended approach is to store the decrypted message locally on the client. Ratcheting forward The protocol recommends using a unique public key for every message you send. This preserves the secrecy of older messages. If your private key gets leaked only one message will be compromised, not your entire conversation. However, this means that you can only decrypt a message once. This gives rise to the need of storing a of keys on the server. If a user runs out of public keys they can’t receive messages. Meaning, if somebody goes offline and they only have 100 keys, we can only send them 100 messages until they’re back online. lot A possible middle ground could be generating a new key every x hours. This way users can always send messages, decrypt them multiple times, and we only need to store one key on the server at a time. Final Thoughts This project has been a wild roller coaster and is far from finished. If you are interested in the code behind the project, you can grab it and check out the actual extension . Have fun, be creative and keep on hacking! here here Thanks for reading! If you have any questions, feel free to reach out at bourdakos1@gmail.com, connect with me on , or follow me on and . LinkedIn Medium Twitter If you found this article helpful, it would mean a lot if you gave me some claps👏 and shared with friends.
