hakthepla.net

Hacking the URL schema

2025-11-20T00:00:00Z

Hacking the URL schema

A while ago I submitted an article to the 2600 magazine. It was published in the Autumn issue of 2024. For those who don't know the 2600 magazine (2600 - The Hacker Quarterly), it's a publication about hacking and technology that has been around for 41 years. Check it out:

https://2600.com

Since it's been a year since my article has been published, I thought it was time to release online. So, here it is (with some minor corrections and updates). I hope you enjoy it.

Let's hack

Let's talk a little about the ancient art of generating URL's that look legit and similar to some address that you may know. There are several ways to do it.

The most common technique is called typosquatting and relies on the typos that we make when typing an address on the address bar. Like goggle.com or paypall.com. Although we get to those malicious sites by mistyping a website address, many people would also click on a link with that URL not really noticing the typo.

There are also homograph attacks which rely on the fact that different characters can look very similar, like the capital I and the lower case L. Also there are different alphabets (latin, greek, cyrillic) that have very similar symbols.

But in this article I'm going to focus on a different kind of attack called "URL Schema Obfuscation". It's so good that it allows you to create a fake URL that looks pretty normal and you don't even have to register a fake domain.

Let's say that you receive a legitimate looking link to a supposedly enraging tweet by some billionaire that you love to hate:

http://twitter.com∕elonmusk∕status∕@2672109077

You click on it. But instead, you're taken somewhere else. In this case, you would be taken to a homepage with a video you may have see before.

How did this happen? Let's split the above address in parts and start by the end.

The 2672109077 part, which looks like the id of a tweet, is indeed a disguised IP address in decimal format. This is a valid format, although most people don't know. An IP address is, in fact, a 32 bit number. It's easier to represent it in the normal dotted notation, separating it in 4 parts, each part having 8 bits, like we usually do. But we can as well use it in decimal format.

Let's say that we want our victims to be redirected to a prank website, which in this case has the IP address 159.69.38.21. First, start by converting each part of that address into binary format:

10011111.01000101.00100110.00010101

Remove the dots, obtaining a 32 bit value, and then convert it to a decimal number:

binary 10011111010001010010011000010101 = decimal 2672109077

Now, if you paste that decimal number into your browser's address bar, preceding it with http://, you will be taken to the prank website. Try it:

http://2672109077

But what about the rest of the URL (twitter.com/elonmusk/status/@)? Well, this part also has some tricks in it.

First there's the at sign (@). That character, when placed before a domain name, means that you want to authenticate to that site using some username. Let's say you wanted to sign as user jaime at the site joana-blog.net. You would type http://jaime@joana-blog.net. This is not a very common means of authentication (nor a secure one), but it's a valid one. It was common in the old days to authenticate to FTP servers.

So, at the example given above, you would be authenticating at http://2672109077 with the username "twitter.com/elonmusk/status/".

Kind of. If you type that manually on your address bar, the browser it will see those slashes and invalidate all that I've been saying. But instead of using regular forward slashes we can use a unicode character that looks like a slash but is instead interpreted as a regular character. In my example I'm using the unicode character U+2215 (division slash). You can see more details about it here:

https://codepoints.net/U+2215

So, after these small manipulations, you end up with a normal looking URL that will trick anyone because it looks like a valid address. That teaches us that we should be very careful when clicking random links even when they look legit (don't click links on suspicious emails, remember?)

Since this method only works when using http (instead of https), if you see a link that starts with http:// you should probably avoid it. If in doubt, try typing the address manually into your browser.

Another thing you should do is use Firefox as your main browser. Firefox shows a warning saying that you're trying to login to a website that doesn't request authentication. Something like this:

You are about to log in to the site "159.69.38.21" with the username "twitter.com".

(I wonder how many people will still click "OK" after this message, anyway)

Unfortunately Google Chrome doesn't show that warning. And you know what? 7 out of 10 people use Google Chrome or some variant of it, which makes an attack like this pretty efficient.

This is not a complicated method, but I created a python script to make the creation of these URL's easier:

#!/bin/python3

import sys

URL_TEMPLATE = "http://{}@{}"

if len(sys.argv) != 3:
    print("Usage: ./obfuscate_url.py <fake_address> <real_ip_address>\n" \
    "Example: ./url_schema_obfuscation.py twitter.com/elonmusk 194.150.169.131")
    exit(-1)

fake_addr = sys.argv[1]
real_ip_addr = sys.argv[2]

username_part = (
    fake_addr.replace("http://", "")
    .replace("https://", "")
    .replace("/", "\u2215")
)

ip_parts = real_ip_addr.split(".")
binary_string = ""

for part in ip_parts:
    binary_string += "{0:08b}".format(int(part))

print(URL_TEMPLATE.format(username_part, int(binary_string, 2)))

Be safe and beware of any links with an at sign!

Prevent M$ Teams from changing your status to Away

2025-11-03T00:00:00Z

Prevent M$ Teams from changing your status to Away

If, like me, you are a Linux user and have to use M$ Teams because of your $dayjob, you may be confused by the fact that your status keeps changing to Away, even when you're using your computer. Only when you hover your mouse pointer over Teams does it decide to wake up and change your status back to Available.

To prevent this from happening, you just have to trick it into thinking that you're periodically hovering your mouse pointer over it.

M$ Teams, on Linux, runs in the browser or as a progressive web app (PWA), which allows us to easily inject javascript code and change its behavior:

Open Teams, press F12 to access the browser's DevTools
Click on Console
Run this script to simulate a `mousemove` event:

function moveMouse() {
    const event = new MouseEvent('mousemove', { clientX: 0, clientY: 0 });
    window.dispatchEvent(event);
}

setInterval(moveMouse, 30000);

You can run this every time you open the application or automate its execution. There are several add-ons that allow you to do this. I'm not going to compare them, so choose the one you like best.

My magazine scanning workflow

2025-04-22T00:00:00Z

My magazine scanning workflow

As you may have noticed, I've been scanning my complete collection of Cyber.net magazines. This post serves as a mental note of the steps I use to scan and publish each issue.

Step 1 - Scan

First I scan the magazine using my flatbed scanner (a CanoScan 9000F) at 300DPI, using the following software:

XSane for Linux

Let's say the output is a file named magazine_original.pdf.

Step 2 - resize file

Since the generated file is too big, I usually resize it, using ghostscript:

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/prepress -dNOPAUSE -dQUIET -dBATCH -sOutputFile=magazine.pdf magazine_original.pdf

Instead of /prepress, we can use /printer to obtain a smaller file, but I think image quality is too low.

Step 3 - Set metadata info

Now, set the metadata of the PDF to whatever you desire, using exiftool. Eg:

exiftool -Title="Cyber.net #25 (1997)" -Producer="Your name" -Keywords="revista internet portugal cyber net" -Subject="Revista portuguesa dedicada à Internet (1995-1998)" cybernet_25.pdf

Step 4 - Upload to Internet Archive

There are likely effective tools available for OCRing the PDF, but my approach is:

1. Upload file to Internet Archive

2. Let Internet Archive generate a copy with OCR

You have to wait a few minutes or hours between step 1 and 2.

After that long wait, go to the page of your uploaded file in the Internet Archive, and you should find a file named PDF WITH TEXT in the "DOWNLOAD OPTIONS" section.

3. Download that file

The file is usually much smaller than the file you uploaded.

Step 5 - Merge PDF OCR and PDF hi-res

Now you should have 2 files:

magazine.pdf - the file you uploaded to the Archive
magazine_text.pdf - the file you downloaded from the Archive (with OCR).

In this step we want to merge both files, resulting in a file that has the quality of the first file and the OCR text of the second.

1. Create a bash script named pdf-merge-text.sh with the following content:

#!/usr/bin/env bash

set -eu

pdf_merge_text() {
    local txtpdf; txtpdf="$1"
    local imgpdf; imgpdf="$2"
    local outpdf; outpdf="${3--}"
    if [ "-" != "${txtpdf}" ] && [ ! -f "${txtpdf}" ]; then echo "error: text PDF does not exist: ${txtpdf}" 1>&2; return 1; fi
    if [ "-" != "${imgpdf}" ] && [ ! -f "${imgpdf}" ]; then echo "error: image PDF does not exist: ${imgpdf}" 1>&2; return 1; fi
    if [ "-" != "${outpdf}" ] && [ -e "${outpdf}" ]; then echo "error: not overwriting existing output file: ${outpdf}" 1>&2; return 1; fi
    (
        local txtonlypdf; txtonlypdf="$(TMPDIR=. mktemp --suffix=.pdf)"
        trap "rm -f -- '${txtonlypdf//'/'\\''}'" EXIT
        gs -o "${txtonlypdf}" -sDEVICE=pdfwrite -dFILTERIMAGE "${txtpdf}"
        pdftk "${txtonlypdf}" multistamp "${imgpdf}" output "${outpdf}"
    )
}

pdf_merge_text "$@"

2. Make it executable:

chmod u+x pdf-merge-text.sh

3. Finally, execute the script to merge both files. Example:

~/pdf-merge-text.sh magazine_text.pdf magazine.pdf magazine_final.pdf

4. A file named magazine_final.pdf is created. Publish it, store it, do whatever you want with it.

Blocking big instances might save the Fediverse

2023-12-21T00:00:00Z

Blocking big instances might save the Fediverse

A few days ago, the new social network Threads fulfilled the promise it made a few months ago. It started testing the implementation of ActivityPub, the protocol responsible for the interoperability between all the instances of Mastodon, Pleroma, Lemmy, PixelFed (what we like to call the Fediverse).

Back in July, when it was announced that this new social network was planning to implement ActivityPub, the Fediverse was divided over whether to allow or to block federation with it. Now we're back in this debate, but now we know they're really doing it.

This whole discussion centers on the fact that Threads is yet another product of Meta, the tech giant that owns Facebook, Instagram and Whastapp. In fact, to use Threads you must have an Instagram account.

Many of us who lurk in the Fediverse view this move by Meta with suspicion. Tech giants have a long history of adopting open protocols when they are favorable to their business and abandoning them when they have already built a big user base and don't want those to flee to other platforms. Examples abound. The most famous are those of the RSS protocol, abandoned by Google Reader, and the XMPP/Jabber protocol, abandoned by Google Talk and Facebook Messenger.

There's little doubt that the same could happen with ActivityPub. If Meta is currently considering adopting it, it's because they think they can get some commercial benefit from it. But if this strategy doesn't work, if they reach the conclusion that it is in fact detrimental to their financial health, the protocol will certainly be abandoned.

Many fear that this could happen, that the Fediverse will become too dependent on a single instance where most of the users host their accounts.

Many even think that that is in fact Meta's big evil plan. They will enter the Fediverse, build a big user base and abandon it, leaving all the other users wishing they were on Threads so they can continue to interact with the majority of their contacts. But does that make any sense? Just a few hours after Threads was launched, it already had more users than the entire Fediverse. Why would they want to extinguish something that can't stand up to them?

We all know in fact who their main rival is: Twitter, the social network that launched the concept of microblogging but has become a nightmare after being acquired by its new billionaire last year . And yes, there is also another potential competitor: BlueSky, the new social network launched by the former billionaire of Twitter, Jack Dorsey. It was supposedly designed from the start to be decentralized, but so far this has been nothing more than promises.

Maybe this whole adoption of ActivityPub thing is some kind of plan to win this space. I have no idea. But I know they're not doing it just because they believe in decentralization. If they did believe, why haven't they implemented it on Facebook or Instagram? Why do we even need an account to read posts from those platforms? Why don't they make their users' posts available via RSS so that we can follow them without accessing their platform, like Mastodon has done from the beginning?

A very interesting feature of Mastodon is the ease with which you can migrate an account from one server to another, bringing all the followers from the old account to the new one. According to Eugen Rochko (Gargron), Mastodon's creator, his "wife is looking forward to deleting her Instagram account once she can connect with the same folks from her Mastodon account. Being able to remain in touch with over 100M people who still use Meta products out of the comfort of an ad-free, privacy-friendly platform like Mastodon is a game changer".

Read Gargron's post here

What Gargron doesn't tell us is how he expects that to happen. First of all, ActivityPub is being tested on Threads, not Instagram. But let's imagine that Instagram goes down that road too. Can you imagine Instagram implementing an account migration feature that allows its users to move away to a Mastodon instance? I can see it happening in the opposite direction, sure. But believing that Meta will allow any celebrity to leave its platform while keeping their millions of followers, is totally naive.

Even if they did allow it, and if they somehow managed to monetize posts from other servers, it would still be a huge risk if those celebrities' followers also decided to migrate to the same server where the "cool people" are now.

But wait a minute. Why am I so critical of Meta's plan, when I've always been and advocate for interoperability? And, like me, why are so many other defenders of open protocols wary of federation with Threads? Isn't it contradictory that, now that this platform is going to adopt one of those protocols, we are so suspicious and thinking of blocking it in our accounts and on our servers? Aren't we the ones who compare ActivityPub with SMTP, the successful protocol that allows email to also be a decentralized and federated system?

Well, when we advocate the adoption of open protocols, what we're really saying is that anyone with some technical ability can create and manage a server. If so many people can do it, then the existence of servers that hold a majority of users is completely unnecessary. There are currently thousands of Mastodon servers (instances.social currently lists almost 17,000). Most of those only have a few dozen users. This is what we call decentralization. It's the possibility for a community to have its own corner of the Internet, free and independent of the big tech infrastructure. On the other hand, if a majority of users are centered on a single server, can we really call that decentralization? Multiple servers orbiting a massive server, resembles a centralized system more than the opposite.

I've thought about this a lot and I believe that the way forward is to block any instance that becomes a threat to the existence of the Fediverse by accumulating a significant percentage of users. I'm not only talking about Threads, Instagram, Twitter, Tik Tok, etc. I'm saying that we should also block any instance of Mastodon that grows beyond a reasonable size. Yes, Gargron, we're keeping an eye on your instance, too. Just like we block instances with hateful content, we should block any instance that may be toxic to the environment. That means blocking ones that are, or have become, bigger than they should be.

Basically, and going back to the email analogy, we don't want another Gmail. We want diversity.

But, unfortunately, not everyone agrees with blocking these platforms, which means that the Fediverse is split between blocking and non-blocking instances. In the latter, users will be able to interact with those trapped in Threads. In the former, this won't be possible.

Perhaps some users will migrate from the blocking instances to permissive ones where they will be able to follow Cristiano Ronaldo or Kim Kardashian's posts. I'd rather look at the bright side of it and enjoy that some other people will choose to delete their big tech social accounts and move to smaller instances where they will be able to interact with the many interesting people and communities who have chosen to keep control of their own data and posts.

Blocking is taking care of our space. It means keeping it healthy and free from manipulative algorithms, targeted advertising and dark patterns. Blocking is the best way to send out the message that we're fine as we are and don't need Zuckerbergs or Musks to get what, after all, we already have.

Hacking a custom homepage for your Mastodon instance

2023-01-19T00:00:00Z

Hacking a custom homepage for your Mastodon instance

Starting with version 4.0.0, Mastodon's homepage is not that great. It defaults to the "explore" page that basically shows the public timeline of that instance. If you want to know more you have to click on the "Learn more" button and then you're presented with the about page that shows the long description of the instance, the rules and the list of moderated servers. And it all shows up in a column centered on the page, which is kinda limiting.

You can add some html tags to the description of the instance. That is good. But you can't do it in the rules section, where you can't even add hyperlinks.

In our instance, Ciberlândia, we decided to hack a custom homepage:

https://ciberlandia.pt

Looks good, doesn't it? aiscarvalho and rlafuente did a great work with the design of the page.

We didn't want to mess with the Mastodon source code, so we did it all by hacking a few rules in the NGINX config.

Step 1: Create your homepage html

SSH to your server as the mastodon user (or sudo - mastodon if you're already logged in as root).

Create the directory where your html will be. We used /home/mastodon/live/custom-index/. Put your index.html, images and css files in there.

Step 2: Add rules to NGINX config

In this step you have to be logged in as root.

Edit the file /etc/nginx/sites-available/mastodon and add these lines (don't forget to change you Content-Security-Policy according to your needs):

# START CUSTOM HOMEPAGE

location /welcome {
  rewrite ^ /welcome/ redirect;
}

location /welcome/ {
  alias /home/mastodon/live/custom-index/;
  add_header Content-Security-Policy "default-src 'none'; font-src 'self'; img-src 'self' data:; script-src 'self'; style-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'";
  add_header X-XSS-Protection "1; mode=block";
  add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-Content-Type-Options nosniff;
}

location = / {                                                             
  if ($cookie__session_id = "") {
    rewrite ^/$ https://<**your instance url in here**>/welcome/ redirect;
  }                                                                                                                                                      
  try_files $uri @proxy;                                                   
}                                   

# END CUSTOM HOMEPAGE

Step 3: restart NGINX

Run this:

systemctl restart nginx

Now when a user tries to access the root of your site, NGINX will check if the user is logged in (checking the value of the cookie session_id) and redirect them to your custom page which is located at the /welcome/ path.

If the user is logged in, they will of course be served the default Mastodon interface.

[EDIT 2023-03-12] Added security headers