Guide Forum Post Downloader - Tampermonkey Script

willowbranch
I tested b06 with an existing GoFile cookie. The downloads worked correctly and no warm-up tab opened.
The console did show this after the downloads finished:
Failed to restore original accountToken cookie: Failed to parse or set cookie named "accountToken".
The original GoFile guest account still appeared when I opened GoFile afterward, but I think GoFile may have restored it from its own localStorage.
I noticed that the GM_cookie.set call used to create the temporary guest cookie includes: url: 'https://gofile.io/'
but the GM_cookie.set call used to restore the original cookie does not. Since Chrome required the URL for the first set call, it may also be required for the restore call.
 
deobfuscation of wt.obf.js:
Code:
function generateWT(stuff) {
var ua = navigator.userAgent;
var lang = navigator.language || '';
var time = Math.floor(Date.now() / 1000 / 14400).toString();
return _sha256(ua + "::" + lang + "::" + stuff + "::" + time + "::" + "9844d94d963d30");
}
 
I'm not sure if it has already been asked before, but I think it would be neat if, when downloading a goonbox album, it used the album name instead of the url for the folder name
 
iNeed2Sleep
Was actually working on that as well. New version b09 is up now, and it should address all those. I also added the cut-through to skip the code when on GoFile itself. If this one is all good, I can wrap it up for a pull to the main script.
Nice find :)
The good news is that the code fetches and live-evals wt.obf.js and then calls generateWT on every request. There's a Date.now() in that function that's run at call time, so it still works as-is, even though I didn't know about the time bucket and thought it was just 2 rotating salts.
 
willowbranch
I tested b09 in Chrome with and without an existing GoFile cookie. Cookie restore looks good in both cases.
I also tested two DIRECT downloads.
-The initial request stalled for about 40 seconds, then the warm-up opened the direct CDN download URL. That already started a browser download, and the retry started the same file again with GM_download, so it was downloaded twice.
-After switching to DIRECT, the old stall timer was still active and later logged STALLED/FAILED, even though both downloads completed successfully.
I repeated the same test later without changing anything, and both files switched to DIRECT immediately and downloaded normally. So this appears to be an occasional edge case, possibly depending on the GoFile CDN response.
It may be better to warm up https://gofile.io/ or the album page instead of the direct CDN URL, and clear or ignore the old stall timer once switchedToDirect is set.
Also, if the file size from /contents is already available, using it to choose DIRECT before starting the Blob request could avoid the long wait.
 
Bunkr works, but every case I've looked into for this is on Bunkr's side due to the restructuring. Do you have an example?
 
Working for me on b09. Check your console, you might be getting blocked by Cloudflare.
 
weird. I don't believe I am being blocked by cloudflare. I have tried it with and without a VPN, and it does the same thing either way. It says it is downloading, but it doesn't actually start the download.
Here is a copy of my console output:
[Sat Jul 18 2026 5:04:56 PM] [INFO] [POST #37] USING 1 HOST(S): Bunkr
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:56 PM] [INFO] [POST #37] PREPARING DOWNLOAD
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:56 PM] [INFO] [POST #37] URL RESOLUTION STARTED
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:57 PM] [INFO] [POST #37] RESOLVED: https://c4ta-b.cdn.cr/0hk5ydixh0prn...e0419ecadb09f8b16f2afcf0e0b1e95&ex=1784419496
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:57 PM] [INFO] [POST #37] URL RESOLUTION COMPLETED
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:57 PM] [INFO] [POST #37] FOUND 1 RESOURCE(S)
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:57 PM] [INFO] [POST #37] DOWNLOADING: https://c4ta-b.cdn.cr/0hk5ydixh0prn...e0419ecadb09f8b16f2afcf0e0b1e95&ex=1784419496
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:58 PM] [INFO] [POST #37] ZIPPED ON BUT NOTHING TO ZIP (ALL DIRECT DOWNLOADS) -> SKIPPING ZIP
userscript.html?name=XenForoSCPDL.user.js&id=87765437-115f-41c9-9572-27b203564815:207 [Sat Jul 18 2026 5:04:58 PM] [INFO] [POST #37] DOWNLOAD COMPLETED
 
yep that certainly works, its just that the script has to evaluate all that extra obf stuff
 
maybe unrelated, apologies, but did anyone else's tampermonkey just randomly updated and deleted all their existing scripts? just happened to me on firefox
 
Which browser and userscript manager are you using? Could your antivirus or web protection be blocking cdn.cr?
 
I can't seem to reproduce the error at all. The only possible gap would be a stalled download that erroneously gave a COMPLETED indication. The stall watchdog was only running on GoFile, so I added it for all the hosts. At the least, you should see a log message indicator if it fails due to a stall.
v3.20.b10 is up now
Give it a try.
 
When its confirmed working and ready for release it'll be incorporated into the main release.
These other versions are for testing
 
Happened to me right now. Sucks.
Someone made a copy of the tensor.art bypass script?
 
How do you download password protected gofile ? I have the password for it but there are over 300 images and it won't let me batch download when I don't have gofile premium.
 
Mine stopped working on all pages all of a sudden. I've made no changes. I installed a fresh up-to-date copy and nothing.
Using Tampermonkey Legacy with Brave.
 
Back
Top