http://s89.filesonic.in/download/504192291
/4e0f1700/1e0d5d23/1358d/2/75c00f1c/0/84016488e74bc9d3e450054ae4272a94e83ae282

4e0f1700 = time (hex) in seconds since epoch
1e0d5d23 = fileID in hex (504192291)
75c00f1c = IP in hex
84016 - SHA1 hash.
The download server providing the file has 0 authentication in itself. You have a unique SHA1 hash that changes every time I make a request for the same file, from the same IP, same username. Also, if I send two requests at almost the same time - it refuses the second one. But while my first connection is open I can reuse that URL to download from a different IP with no auth whatsoever.

The above URL is generated (with SHA changing) and given to my downloader every time it requests the same file (fileID in decimal, username, password provided). What I don't understand is why he needs to store time, fileID, etc as part of the download URL.

It looks overly complicated to me Why can't he just:
1. authenticate me
2. create some random hash and symlink that to the real file i want.
3. stick that hash in the download url he gives me.
and presto! After my download is complete, delete the symlink so no one else can download that file!

Why is the complication necessary??? What's going on???

1. Authenticate me
The scheme above doesn't need any authentication for free users and will work with session keys derived from inputs such as time, ip etc.
2. create some random hash and symlink that to the real file i want.
Single symlink-ing sounds a simple file operation. But imagine that operation for millions of users in real-time. It wouldn't simply scale. File-hosters like the above need to keep in mind the amount of traffic and users they may have at any given instant of the day. This is why a scalable real-time database driven model is so important.

Besides, in your scheme, how do you think you'd protect downloading of the same file from two locations if the hash is shared? If allowed, that'll simply be a very big waste of their bandwidth. Hosters supporting free users have to keep many of these questions in mind as part of their business model.

oh boy! they've changed the URL format slightly - slightly cleaner, but it's still just as peculiar:
http://s99.filesonic.in/apidownload/500852531_13877881_1975520018_0_1411309848047?username=barneyhowells%40gmail.com&password=whatever

/unalteredFileID_unalteredUserID_mangledIP_0_no-longer-a-SHA-hash?whateverAuthInfo

Again, I don't understand why he's passing all that data. There are two servers involved.
1. api.filesonic.com [[ wget -q -U "Konq" "http://api.filesonic.com/link?method=getDownloadLink&u=barnsley&p=whatever&format=xml&ids=500852531" -O - ]]

This will return:
<FSApi_Link><getDownloadLink><response><links><link><id>500852531</id><status>AVAILABLE</status><filename>Building.a.Small.Steam.Engine.by.Rudy.Kouhoupt.2.DVDs.part01.rar</filename><url><![CDATA[http://s99.filesonic.in/apidownload/500852531_13877881_1975520018_0_1411309848047?username=barneyhowells%40gmail.com&password=whatever]]></url></link></links></response><status>success</status></getDownloadLink

2. s99.filesonic.com [[wget -q -U "Konq" --limit-rate=0.2K "http://s99.filesonic.in/apidownload/500852531_13877881_1975520018_0_1411309848047?username=barneyhowells%40gmail.com&password=whatever" -O - ]]

1. If he has a centralized DB (as you say might be expected) then all his download-servers (s99.filesonic) plug into that DB, therefore he should just update the DB with the new-download-session-info, and be done with it. The SHA1 hash that the download-server receives can act as a key. He should also have fast back-end communication between the server/s-DB so the download-servers can verify with the DB server.

BUT!!! He authenticates twice!! (once at the DB (api.filesonic.com) and then again at the download server (s99.filesonic.com))

2. Which means he doesn't have a centralized DB! Now the individual servers share a common password file which is synced in some way?? You authenticate with the DB server and tell it, give me xyz file. The DB server authenticates you and digs out the server that has that file (fs99) then it sends you off to auth with that server (and he sends user-name which is an email address instead of a loginID)!
---
**So, fs99 receives fileID (since it has no clue or access to the central DB), it also receives the userID so it can confirm email/password match, and obfuscated IP field so it can prevent multiple downloads - this IS OBVIOUSLY WRONG but minor.

Now they dropped SHA1 and switched to something else (1411309..), they also dropped that time field - just yesterday it was SHA1+timefield. Anyway..
***

So, to test the above theory i tried something:
1. I took a bunch of URLs and got the sXX.filesonic server links. Some files are on the same server!
s89.filesonic.in/apidownload/500865141
s89.filesonic.in/apidownload/504192291

s99.filesonic.in/apidownload/500805721
s99.filesonic.in/apidownload/500852531

So, I took one valid download URL for file 500865141 and replaced it with 504192291 obviously the IP is the same, userID is the same and i just used the original hash-like-string and it didn't work

So, obviously that "hash" is related to the data in some way.. and I was wondering.. how does one go about reversing that?? Grr! I don't understand..

[[ SHA1(fileID+userID+mangledIP+commonServerSekretKey) = hash ]] But!! this can be reused.. so +time?? but how will fs99 verify then ]]