0

I'm having some trouble building an app that gets data from a database to keep a log of files added to a website.

Most URLs are generated from a file ID and a time stamp, some of those URLs are missing in the database but they're quite easy to regenerate. There's another type of generated URL that includes a string that I can't figure out. I'd like to know if it is possible to generate them too.

These URLs look quite like this:

http://www.mysite.com/files/a9780ed25285890789147440840/file.ext
http://www.mysite.com/files/a9789f9b5285890789147441956/file.ext
http://www.mysite.com/files/8b9b5d1f5285890789167885136/file.ext
http://www.mysite.com/files/a97906135285890789147442083/file.ext
http://www.mysite.com/files/a9790e735285890789147442272/file.ext
http://www.mysite.com/files/a9791a905285890789147442521/file.ext
http://www.mysite.com/files/8b9bedfd5285890789167886250/file.ext
http://www.mysite.com/files/a97aaf595285890789147445176/file.ext
http://www.mysite.com/files/a97ab7fc5285890789147445386/file.ext
http://www.mysite.com/files/8b9d17895285890789167888638/file.ext
http://www.mysite.com/files/a97ac03a5285890789147445564/file.ext
http://www.mysite.com/files/a97acd635285890789147445897/file.ext

As you can see, it looks like hexadecimal for the first 8 characters, the middle section looks very similar, but I can't recognize a pattern here. I would like to point out that the dates are stored as epoch numerals, though the easy links have readable dates.

I'd appreciate any kind of information that could help me start figuring out this pattern.

Thanks!

  • Hi and welcome to RE.SE. Since those are URLs, have you considered correlating the last modified timestamp sent by the servers with parts of the URL? – 0xC0000022L Jul 31 at 7:44
  • the decimal part could be nanoseconds since november 2002 – Jasen Aug 4 at 0:28
0

Since this would not fit into a simple comment, I am posting this as community Wiki. The script, after all, may be helpful to others.

What I would try in such a case is to see if parts of the string can be interpreted as timestamps, for example.

#!/usr/bin/env python3
"""\
Little script to interpret integers given on the command line as
Unix time (unless that causes an error) and Windows FILETIME.

It outputs the human-readable date and time retrieved from either
interpretation.
"""
import sys
from contextlib import suppress
from datetime import datetime, timedelta, timezone

if __name__ == "__main__":
    START = datetime(1601, 1, 1, tzinfo=timezone.utc)
    print("FILETIME base time:", START)
    for ftval in sys.argv[1:]:
        with suppress(ValueError):
            ft = int(ftval)
            print("You gave:", ft)
            with suppress(OverflowError, ValueError, OSError):
                dt = datetime.utcfromtimestamp(ft)
                print("\t... interpreted as Unix time:", dt)
            # Windows FILETIME uses 100 ns intervals as base unit.
            # 100 ns == 0.1 µs
            microsecs = ft / 10
            with suppress(OverflowError):
                delta = timedelta(microseconds=microsecs)
                dt = START + delta
                print("\t... interpreted as Windows FILETIME:", dt)

... unfortunately, having tried that with ./winft.py 5285890789147445564 (I named the script winft.py), I can tell you that it's likely not timestamps. Even using parts that look like Unix timestamps, the output hardly makes sense:

$ ./winft.py 147445564
FILETIME base time: 1601-01-01 00:00:00+00:00
You gave: 147445564
        ... interpreted as Unix time: 1974-09-03 13:06:04
        ... interpreted as Windows FILETIME: 1601-01-01 00:00:14.744556+00:00

... putting that 9 back in front of the apparent Unix time doesn't make it better:

$ ./winft.py 9147445564
FILETIME base time: 1601-01-01 00:00:00+00:00
You gave: 9147445564
        ... interpreted as Unix time: 2259-11-15 05:06:04
        ... interpreted as Windows FILETIME: 1601-01-01 00:15:14.744556+00:00

On the other hand the decimal part after the 8 hex digits could be a bunch of (not so random) bytes that are being interpreted as integer and so could be decoded back into an integer (in either Endianess). Python for example deals with huge integer values effortlessly.

However, last but not least I would like to remark that proper encryption is pretty unlikely, given how similar the part behind the 8 hex digits looks. You would get much more random values if this was properly encrypted.

The 8 hex digits could be a truncated hash digest (MD5, SHA1 ...) or something else entirely. Would make much more sense to look at available meta-data such as the HTTP headers, at the file contents ... try to compute the digests on the file using various algorithms and then try to see if one of 8 hex digit strings matches the digests in hexadecimal representation ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.