Server Acting Weird (again)

[Joonath]

Seems like they were changing its method quite frequent

[Joonath]

Update: I think I see why

[mstephen77]

Everything's randomized now, btw.
And those javascript thingy is too pro LOL.

[Joonath]

It's rare to see unescape() being used on site these days. I guess it's reasonable for avast to have it as a threat.

[chrsep]

Wow, i can't even see the html page now. How does this work?

I have no idea when i can work on this. hmmm This seems a lot more complicated than any changes before it.

[senacand]

I have my own Binus Maya third-party app that I created for private use, and I have successfully bypassed their new 'encryption' and I believe it would be useful to share it.

It's true that the source code is hidden if you use view-source, but it's because how Google Chrome works. But if you simply do a GET request through POSTMAN or other app that can extract HTML without running the JavaScript, it would work just fine (since you use Retrofit, this should work too).

If you look at it, the whole thing is quite simple. They simply just print out the webpage using document.write everywhere, placed inside a function that they use unescape and document.write it into the page. But here's the thing: you don't need to care about them, because the data you need are not encoded in any weird way.

In order for login (as you already know), you need to get the name of the inputs for:

1. Username
2. Password
3. Login submit button (yes, they used to keep it a constant variable. Now they randomized it too)

which Bimay jumbled them up on their last update. But that's not all, you also need the 'serial' which accesses https://binusmaya.binus.ac.id/login/loader.php?serial=something (which you also probably know. You'll get two input name and values from the javascript which you need).

Here's the thing: You don't need to go through the encoding and encryptions. It's written in plaintext.

Go use Postman or something to get the content of login page. You'll see that there are few "document.write" functions, here are them in order from top to bottom:

1. document.write(unescape(.... => this will write the javascript function required to decode/decrypt the whole interface. no need to worry about this.
2. document.write("string") => this is the serial (you can then go to the usual 'loader.php?serial=' file using this serial
3. document.write("string") => this is the name and id for the username input
4. document.write("string") => this is the name and id for the password input
5. document.write("string") => this is the name and id for the submit button (login button) input

You can just extract the HTML file, do a simple REGEX search and get the 'string' from the second to fifth and you'll get all the information needed to perform login.

I would love to do a pull request, but unfortunately I'm not used to native Android development (the app I coded uses React-Native, so it's complete JavaScript), so I can't help to port it to Kotlin. I hope this will help a lot.

[Joonath]

In case of curiousity, you can copy-paste those escaped string here: https://www.tareeinternet.com/scripts/unescape.html

Also, if you mean that the whole content is being hidden (and only showing the comment sign), it isn't fully true though, we can see the 'encrypted' source code at the very bottom of it.

I wonder what would happen if they use unescape thing for the whole content 😐

[chrsep]

Wow thanks, I haven't look into this deeper, I thought they would have encrypted the whole thing with a custom encryption that I need to implement myself or something.

If the whole login tokens is not encrypted and stays the same, the only thing that needs to be changed in Portal's login is probably it's regex pattern in AuthInteractor.kt. But I still don't really have time to handle this yet though for a while, I got some deadline to catch 😅.

If anyone wanted to try, you can try to create a pull request.

[mstephen77]

Well, right now I'd recommend looking at libraries for headless / automated browser... At least it was robust enough since it was practically the same as manual login, and you could just scrape PHPSESSID from the Cookie.

[senacand]

Turns out the problem is not only there. Somehow, Binus Maya refuse (purposefully or not purposefully) when the User-Agent is from Mobile Chrome Browser (I haven't tested other mobile browsers however), so not only we need to change the Username and Password names, but also change the user agent.

I have created a pull request with the fixes, you may want to check it.

[chrsep]

Thanks @senacand , they do seems to change their login rule quite often, everything seems to work now though 😁, I'll push an update by the end of the day.