Recommended text-based browser pkg with javascript?

I want to set up a cron on my FreeBSD server to regularly reboot my router (WD My Net N900 w/ no telnet or SSH). I've come up with two concise curl commands (one to authenticate logon and the other to reboot). But the session-only cookie ("uid") resulting from authentication (which is critical in the reboot command) can only be produced via a web browser that utilizes javascript.

What are my options for a text-based browser with javascript that's available via pkg?

FYI - I'm not real experienced with all this, so if I've omitted key info, please bear with me.
 
The text based www browsers I know are links,elinks,lynx. But their functionality is limited compared to firefox/chromium.
So I have big doubts, you could try these three browsers and "enable" cookies if available.
 
Could you use a programming language (e.g. PHP) that links to cURL? Hmmm, looks like that has already been suggested to you!


Might have to build a robot arm to push a physical button, or have a little computer (like a Pi) that you can have Chromium installed on - send ssh command to "something" on the Pi that will run Chromium and do the reset step for you.

But not really what you after.
 
I think that's the wrong way, because this:
But the session-only cookie ("uid") resulting from authentication (which is critical in the reboot command) can only be produced via a web browser that utilizes javascript.
is not possible. It might be possible that there's some additional processing done by javascript on some secret obtained from the server, although I think that's somewhat unlikely, because it wouldn't really serve a purpose.

Use the "network" tab of the development tools available in e.g. chromium or firefox (disable the auto-clear function) while doing the process manually. At some point the server will include the secret you need in a response, if not in a cookie then maybe in a different header or, more likely, in the body, which might be json or xml or something else ... it will be a bit of detective work.
 

The instructions in that link are outdated - they apply only to the router's original firmware release. In all later firmwares, WD disabled telnet w/o authorization. While WD still makes available all later firmware versions, they've eliminated the original. I contacted WD support to no avail. The original firmware also included SSH - if I had that (or telnet, albeit less secure), then a cron reboot would be easy.
 
Use the "network" tab of the development tools available in e.g. chromium or firefox (disable the auto-clear function) while doing the process manually. At some point the server will include the secret you need in a response, if not in a cookie then maybe in a different header or, more likely, in the body, which might be json or xml or something else ... it will be a bit of detective work.

I've already done that, which is how I came upon the special session-only "uid" cookie ('uid=XXXXXXXXXX') that a browser w/ javascript produces. Once I have that specific cookie, I can reboot the router via curl.
 
Could you use a programming language (e.g. PHP) that links to cURL? Hmmm, looks like that has already been suggested to you!

Yes - going with the instructions offered on that post, I was unsuccessful.
 
I've already done that, which is how I came upon the special session-only "uid" cookie ('uid=XXXXXXXXXX') that a browser w/ javascript produces. Once I have that specific cookie, I can reboot the router via curl.
And that's why I say that the javascript code must somehow receive some secret from the server in order to produce the cookie, so that the server can later verify it. Therefore, dig deeper in all requests and responses, there must be something to find ;)
 
The only text browser that supports javascript i know is www/elinks.
To successfully incorporate javascript into elinks, one has to configure and make. My server runs on a modified FreeBSD designed for XigmaNAS, and the option to make is not available. I installed elinks as a pkg, but it would not run javascript.
 
Running javascript is not the correct way to solve this issue, really. You must understand how the client learns some secret from the server and how (if at all) it is processed and then written in a cookie. Then you can replicate that in your script and just use curl to fire the http requests.
 
Thanks for all the replies and suggestions, all of which I tried previously w/o success (If I've overlooked something, please let me know!). As I feared, it looks like I'm stuck having to manually reboot on occasion.
 
You can mail me your device so I can have a look at the logic for obtaining the cookie myself 🙈.

But seriously, this problem can be solved for sure. Maybe, in the worst case, you even need the javascript debugger of your browser to understand what's going on....
 
from the stackoverflow page it looks like it has some challenge response mechanism so you may have to reverse engineer some js shit
 
you can probably do it without reverse engineering the code with some type of phantomjs or some other nodejs stuff like https://github.com/jsdom/jsdom but it seems overkill to me
(i'll rather open the box and and find the serial console pins and hack shell access :))
 
And that's why I say that the javascript code must somehow receive some secret from the server in order to produce the cookie, so that the server can later verify it. Therefore, dig deeper in all requests and responses, there must be something to find ;)
I'm not sure what further to look for. Using Chrome developer tools, the critical step is when I enter my password, the next item that appears is "authentication.cgi", which yields the following curl output:
Code:
curl 'http://192.168.1.1/authentication.cgi' \
  -H 'Accept: */*' \
  -H 'Accept-Language: en-US,en;q=0.9' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Cookie: QPYVIXOAZD=admin; uid=fp2E0ODrAB' \
  -H 'Origin: http://192.168.1.1' \
  -H 'Referer: http://192.168.1.1/' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36' \
  --data-raw 'USERNAME=admin&DIGEST=D07B0B95EDF9BF8EC9BD2DC62631D558' \
  --compressed \
  --insecure ;

The only critical info I need from that is the "uid" cookie. With that, I can then enter via ssh on my server:
Code:
curl --cookie 'uid=fp2E0ODrAB' http://192.168.1.1/service.cgi --data-raw 'EVENT=REBOOT'
And the router reboots.

But, at this point, I can get that uid cookie only from a web browser with javascript (via its Developer Tools) and then manually enter it into the preceding curl command.
 
From that, I would assume the uid is random and the DIGEST is computed from the uid, the password you entered and (as covacat mentioned) some challenge that was probably delivered from the server together with the login form, or queried separately by some javascript bundled with the login form.

This is a major PITA for sure. You will probably need the full http traffic (right from requesting the login form) to understand exactly what happens, and, yes, reverse-engineer what the javascript is doing exactly.
 
jamaroney if you can, post the javascript here.

If the code is invariant, equivalent code can be written in the language of your choice. Worst case is to feed it into a JS engine of your choosing to extract the token - but still under script control - and without a browser.
 
Forgive my lack of expertise - how do I do that? Is that something that can be done via Chrome's Developer Tools?
In the "Sources" tab, you get a nice tree view of all resources for that page. Look there for javascript files and javascript embedded in HTML. I'd expect most of it to be "minified" and therefore completely unreadable, but it's a start.
 
There's a number of javascript files that are used in login/authentication:

comm.js
libajax.js
postxml.js
new_checkbox_radio.js
new_select.js
new_button.js
new_help.js
hmac_md5.js
multi_language.js
browser_detection.js
new_text.js
new_arrow.js

How could I determine which ones are important for the actual authentication process? I'm guessing the "new_*.js" files are probably not.
 
Back
Top