Many Gen 1 panels require a token too as well as the MAC

[ian10951]

A parameter option for both a token and valid account details are needed before saving the MAC as some portals allow all MACs but then there is no access to any content with most of them

Here is an example of one. With this one the code not only has to get a token but the account details need to be there as well in order to establish that a MAC is actually valid. Without this all MACS are reported as valid. This one is an excellent server too , so I would love this issue to be fixed.

http://privatesystem.co.uk:2086/c

A tshark scan on the ethernet card and the requests for this server when using /c are returning http error 404 (my server IP removed for safety )

17218 4.446114313 xxx.xxx.xxx.xxx → 172.67.222.213 HTTP 344 GET /c//portal.php?action=handshake&type=stb&token=&mac=00%3A1A%3A79%3A69%3A23%3AFF HTTP/1.1 17224 4.449867968 172.67.222.213 → xxx.xxx.xxx.xxx TCP 60 2086 → 59624 [ACK] Seq=1 Ack=291 Win=65536 Len=0 17447 4.534195442 172.67.222.213 → xxx.xxx.xxx.xxx TCP 815 HTTP/1.1 404 Not Found [TCP segment of a reassembled PDU]

So it would apper that the trailing "/" us not required, the url is added to "portal.php?action=handshake&type=stb&token=&mac=00%3A1A%3A79%3A17%3A57%3A6F" and the /c is dropped but it doesnt work without it either and gives

592 0.193861537 xxx.xxx.xxx.xxx → 104.21.62.103 HTTP 358 GET /c/portal.php?action=handshake&type=stb&token=&mac=00%3A1A%3A79%3A17%3A57%3A6F HTTP/1.1 610 0.209861645 104.21.62.103 → xxx.xxx.xxx.xxx TCP 60 2086 → 45358 [ACK] Seq=1 Ack=305 Win=65536 Len=0 801 0.244035608 104.21.62.103 → xxx.xxx.xxx.xxx TCP 821 HTTP/1.1 404 Not Found [TCP segment of a reassembled PDU]

So to sum up the code not only has to get a token but the account details need to be there as well in order to establish a hit and that the tested MAC is indeed valid.

Ive now encounterd several panels like this, all are Gen 1, where the account details need to be saved before the tested MAC can be established as actually being valid, so its not an isolated problem, its actually quite common.

I believe its for this very reason that other scanners sumilar to this also save the account details as well as the MAC in their results.

Perhaps you know of another way of establishing the validity of a MAC though ? without the need for the account details.

Ive attached code from another scanner that does work on these type of portals that you may find useful.

Edit.zip

[dougy147]

Hi @ian10951 ! Thanks for your detailed feedback. I think I've managed to correct this in the code. Empty profiles are now considered... empty ! I don't know of other ways to check the validity of a MAC, but this should do the stuff for the moment. Don't hesitate to tell me if that works or if there still are bugs (which I unfortunately don't doubt).

PS : I wanted to recommend you tmux on your last issue, but you seem to have found it on your own, enjoy ;)

[ian10951]

Many thanks Dougy.

Looking good

xxx.xxx.xxx.xxx → 104.21.62.103 HTTP 450 GET /portal.php?type=account_info&action=get_main_info&mac=00:1A:79:B3:E2:31 HTTP/1.1 104.21.62.103 → xxx.xxx.xxx.xxx TCP 60 2086 → 35824 [ACK] Seq=1 Ack=397 Win=65536 Len=0 104.21.62.103 → xxx.xxx.xxx.xxx HTTP 795 HTTP/1.1 200 OK (text/javascript) (text/javascript)

But I will need a couple of days to confirm properly. This panel, although very good, doesnt have that many subs and it usually takes a while to get results. I've had two, but they had no date set against them, which usually means theyre expired and when tested they didnt work. Strange how they are sometimes saved even when mcbash is set not to. I think some servers keep old expired macs to prevent users from subscribing elsewhere when the sub runs out which is wrong. They deserve everything they get from things such as this lol.

Ian.

[ian10951]

OK Dougy further testing has revealed that its still not saving valid macs on many Gen 1 portals. It is now saving macs but all are without the expiry date and none work. I'm unable to speculate why this is because things do now look OK on tshark.

Working perfectly with all Gen 2 and NXT panels tested though.

[ian10951]

OK I think the problem is this.

mcbash needs to request the profile url before the account data url and then it will work for gen 1 panels such as http://privatesystem.co.uk:2086 and http://panelnet.co.uk:8000 for example

profile url "portal.php?type=stb&action=get_profile&mac=

At the moment mcbash cant get the account info. It gets a http 200 response but no data in the response and so saves the mac as valid ( when its not ) without an expiry date.

This is not the case for every Gen 1 panel, but it is the case for most of them.

Ian.

[ian10951]

Any update on this Dougy ?

The problem with most Gen 1 servers is every invalid MAC gives a response but the valid MACs seem to give nothing. Could it be the headers or user agents that mcbash uses ? It seems mcbash uses random headers but some are not the Magbox ones. Gen 2 seems to be easy as mcbash tries to make a handshake and when it gets null, moves on to the next MAC. As soon it gets a response that is not null it saves the MAC.

If this issue with many Gen 1 panels could be fixed mcbash would be an awesome little program.

[dougy147]

Hi @ian10951 ! It's been a while. I used your advice "[...] to request the profile url before the account data url" in the last commit. It should be working good now. I also added a little extra (showing the exp date on output). Thanks for your feedback again, hope you were not in a hurry ;).

Cheers !

[dougy147]

Closing this issue as it is not about GEN1 tokens anymore