| Website | https://dfir.blog |
| Unfurl | https://unfurl.link |
| Hindsight | https://hindsig.ht |
| DFIQ | https://dfiq.org |
| Website | https://dfir.blog |
| Unfurl | https://unfurl.link |
| Hindsight | https://hindsig.ht |
| DFIQ | https://dfiq.org |
..and there's another Unfurl release as well! v2025.03 is live and adds new features and some fixes, including:
π Parsing #Google Search's UDM parameter
π Recognizing #Mastodon usernames and parsing Mastodon forks (like truthsocial[.]com and gab[.]com)
π§Ή Utility parser to "clean up" inputs
Try it out at https://unfurl.link or read more about the update https://dfir.blog/unfurl-parses-googe-udm-and-truth-social/
A new Unfurl release is here! v2025.02 adds:
π Parsing encoded/obfuscated IP addresses
π¦ Resolving #Bluesky handles to their identifiers (DIDs) and looking up their creation timestamps
π Bug fixes & better bulk parsing
Blog: https://dfir.blog/unfurl-parses-obfuscated-ip-addresses/
Code: https://github.com/obsidianforensics/unfurl
Over the winter holiday, I was watching Netflix's Carry-On and got a bit nerd-sniped by a real Google Search URL on-screen... and then proceeded to "authenticate" it.
https://dfir.blog/authenticating-screenshots-from-netflix-carry-on-movie/
Another new Unfurl feature is parsing DoH (DNS over HTTPS) requests! I haven't run into these often in URLs, but hey, it's nice that Unfurl can parse them for you if you do!
Unfurl can parse JSON Web Tokens!
At the highest level, JWTs have three parts: header, payload, and signature. Unfurl first splits a #JWT into those three components, then base64-decodes the header and payload, then parses the resulting JSON objects. While Unfurl could parse all that in one step, it does it in three steps to keep with the "show your work" spirit of the tool.
Here's an example: https://dfir.blog/unfurl/?url=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
ULID (Universally Unique Lexicographically Sortable Identifier) is another βοΈ-like timestamp (and Unfurl πΏ can extract the timestamp from them).
Example: 01ARZ3NDEKTSV4RRFFQ69G5FAV
ULID Features:
πΉ Sortable
πΉ 26 chars vs UUID's 36
πΉ Larger timestamp range
π ULID Spec: https://github.com/ulid/spec
π Unfurl example: https://dfir.blog/unfurl/?url=01ARZ3NDEKTSV4RRFFQ69G5FAV
Why do we care about timestamps embedded in UUIDs?
A UUIDv1 timestamp often correlates with when the object it represents was created. Extracting this timestamp gives us another point in our timeline (or just more context).
For example, the timestamp from the UUID in this GitHub image = time of image upload β°
UUIDv1 has a timestamp & node ID, which can be the MAC address of the machine it was generated on (or random; it depends π€·ββοΈ).
Unfurl πΏ can extract the timestamp & node ID from a UUIDv1 and look up the vendor if it's a real MAC address.
Unfurl example: https://dfir.blog/unfurl/?url=a28cad70-0d73-11ea-aaef-0800200c9a66
UUIDs (universally unique identifiers) are everywhere online. UUIDv4 is the most common (random), but UUIDv1 (time-based) is still out there.
The 13th digit (or 1st of 3rd group) is a quick way to tell if a UUID holds a timestampβ°
RFC π : https://datatracker.ietf.org/doc/html/rfc4122#section-4.1.4
One gotcha to look out for is some IDs may claim to be UUIDs... and look like UUIDs... but not adhere to the RFC π€·ββοΈ.
This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]