Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

The Config Guide

Download as pdf or txt
Download as pdf or txt
You are on page 1of 21

SNUSBASE

The first and the most simple website we will be making a config for is Snusbase.

Login page - https://snusbase.com/login

Step 1 – Intercept the traffic of the website

Open Inspect Element or simply press the shortcut - ctrl + shift + i

This is what the page should look like after opening inspect element

Now we will navigate to the Network Tab in inspect element

Here we will see the website’s traffic

The second step is getting the login API and checking what is required to login

With the network tab open type random information in the Snusbase login page for example

Username: Amongus123

Password: Passwordamongus123
A login request will pop up inside the network tab

We can see it is a post request to the login API

Now we will navigate to the payload tab inside the login request

Here we will see the login details we typed in earlier, in my case:


Here we can see that only the Username and Password are getting posted to the API, no CSRF tokens,
meaning this should be a fairly simple to make.

After checking all this, we will create a config in Openbullet, and start with a request block

We will put the URL we’ve earlier got from the network tab, and set the Method as POST

Content type stays application/x-www-form-urlencoded since the website states it is accepted in the
request headers:
In POST data we will put the payload we’ve also found earlier, but there’s a catch.

We will press the view source button above the payload.

Now it will look like this

Copy the full payload, in my case

login=Amongus123&password=Passwordamongus12&remember_me=on&action_login=

We will switch the Username and the Password we put in, with the standard Username and Password
variable names in Openbullet

Username = <USER>

Password = <PASS>

Now it will look like this

login=<USER>&password=<PASS>&remember_me=on&action_login=

We will put that in POST data and test our progress.

In the very top right of our Openbullet we see a Debugger:


Inside the Data we will put a random Username:Password combination, for example:

And press Start

Now we will navigate to the Log tab right below:

We will search for the response the website gave us.

In this case:

The username or password you entered was not found in our database.
If we get a match inside the Log tab, we’ve done everything right so far.

Now we will create a key check block.


For the Failure key chain we will put: The username or password you entered was not found in our
database.

Now we need a success key chain, for that we will need to create an account on the website.

After successfully doing so we will test the account details we just created inside the debugger from
earlier.

Now we will get greeted with a ban status on our config:

That is because we’ve checked the Ban if no key found option, without actually having the success key.

This just means that the source code does not match our failure key chain - The username or password
you entered was not found in our database.

If we look at the log further more we will see that the we got redirected to the dashboard page:

We can now put that as our success key chain.


We will change the <SOURCE> with <ADDRESS> and put the dashboard page in the key chain

If we run our config once again, now we will get a success key.

We’ve just successfully made a config.

In case you did a something wrong, you can check where you messed up by comparing your’s with our
code:

REQUEST POST "https://snusbase.com/login"


CONTENT "login=<USER>&password=<PASS>&remember_me=on&action_login="
CONTENTTYPE "application/x-www-form-urlencoded"
HEADER "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/80.0.3987.149 Safari/537.36"
HEADER "Pragma: no-cache"
HEADER "Accept: */*"

KEYCHECK
KEYCHAIN Failure OR
KEY "The username or password you entered was not found in our database."
KEYCHAIN Success OR
KEY "<ADDRESS>" Contains "https://snusbase.com/dashboard"

In order to see your code, press the Switch to Loliscript button in the bottom left:
Want to practice on similar difficulty websites?

https://sportbet.one

https://dashboard.tenderly.co/login

https://plisio.net/account/login

SHODAN

The second and a bit more difficult website we will be doing is shodan

Login page - https://account.shodan.io/login

After looking at the payload, we will see a CSRF token:

It might look very confusing but believe me it is very simple.

To put it in short, you will not be able to successfully send a POST request to their API without the exact
CSRF token provided by the website.

How do we get the CSRF token?

In this case very simple.


We will copy the CSRF token and open the elements tab in Inspect Element then press the shortcut – ctrl
+ f and paste it in the given text box, so we can search for it in the HTML of the website.

And we found if, this means we will simply load the HTML and Parse the token before doing a POST
request.
We will create a request block and GET request the login page.

Press Start on the Debugger and open the Log tab.


We will search for CSRF.

And we should get matching results.

How do we copy the csrf token from here?

Using the Parse block.

We will now create a Parse block.

We can name the variable anything we want, I usually go with csrf or tk as it’s easy to remember.

Set the Mode to LR (LR means Left string Right string)

The left string is going to be the specific HTML that’s on the left of the string we are trying to parse.

And the right string is going to be what’s on the right from the string we are trying to parse.
In the end it should look like this:

After pressing start on the debugger a variable with the CSRF token should appear:

Now we will be doing a POST request on the API, as we got everything required for the login.

username=Amongus&password=Suspicious&grant_type=password&continue=http%3A%2F%2Fwww.sh
odan.io%2Fdashboard&csrf_token=bf0ad65e0f85a62dbbe0074d1dd5815902e1f907

My payload looks like that, after the needed editing it should end up like this:

username=<USER>&password=<PASS>&grant_type=password&continue=http%3A%2F%2Fwww.shodan
.io%2Fdashboard&csrf_token=<csrf>

We’ve switched the Username and Password with the default variables, BUT we also switched the CSRF
token with our Parse Block Variable name, in my case it is csrf, so I edited it to <csrf>

The website should now return - Invalid username or password, after an invalid login.

Again we will have to create an account in order to get the success key (we will always have to do this
unless we already have a hit for the website)

Same as last time, we get redirected to the Dashboard page:


In the end the key check block should look like this:

If you’ve encountered a problem, you can compare your code with our code.

REQUEST GET "https://account.shodan.io/login"

HEADER "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/80.0.3987.149 Safari/537.36"
HEADER "Pragma: no-cache"
HEADER "Accept: */*"

PARSE "<SOURCE>" LR "name=\"csrf_token\" value=\"" "\"" -> VAR "csrf"

REQUEST POST "https://account.shodan.io/login"


CONTENT
"username=<USER>&password=<PASS>&grant_type=password&continue=http%3A%2F%2Fwww.shoda
n.io%2Fdashboard&csrf_token=<csrf>"
CONTENTTYPE "application/x-www-form-urlencoded"
HEADER "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/80.0.3987.149 Safari/537.36"
HEADER "Pragma: no-cache"
HEADER "Accept: */*"

KEYCHECK
KEYCHAIN Failure OR
KEY "Invalid username or password"
KEYCHAIN Success OR
KEY "<ADDRESS>" Contains "https://www.shodan.io/dashboard"

Want to practice on similar difficulty websites?

https://dashboard.anchorusd.com/login

https://anonfiles.com/login

https://www.monect.com/login

https://www.chess.com/login

https://steelseries.com/login

HONEYGAIN

Honeygain is basically the same as our earlier examples, however if we want to add capture we might
encounter some issues, and that is because we need to include a Authorization token in every request to
the dashboard.

Let’s see how we will add capture to this website

We will have to capture the amount of credits an account has

If we look in our network tab after logging in with the correct details we will see various API requests
happening
Lets check which one of these contains the amount of credits, probably the balances one

This is the exact one that contains the balance of the account, however if we just want to make a get
request to it, the website will not respond with any useful information and will probably just return us to
the login page

If we look in the headers we can see a specific token that is getting sent

This token is generated on successful login, and it contains information about our account when
decoded

We need to also include it in our request, so the website will know which user is trying to access the API

We can’t use the same one as seen in this request, as it will give the same capture for all accounts, since
this token contains the information to this singular account

We will need to parse the token from somewhere, usually given In the response code

After a successful login we will see this:


We will now have to parse the access_token

Instead of using Left string Right string to parse, when the source is in the json format we can also use
the JSON mode

When using JSON mode the field name is what is in between the “”

In this case the JSON looks like “access_token”:

So our field will be access_token

Our parse block should look like this

Now we need to include the token in the request the same way the website did it in the headers

Our headers should look like this:


And our whole block should look like this:

We should now successfully get the amount of credits in the response from the API

Now we simply parse it like we did before:

If we want the value parsed to be included in the capture when checking account we will check the Is
Capture tick like on the screenshot
If you’ve encountered a problem, you can compare your code with our code.

REQUEST POST " https://dashboard.honeygain.com/api/v1/users/tokens"


CONTENT "{\"email\":\"<USER>\",\"password\":\"<PASS>\"}"
CONTENTTYPE "application/json"
HEADER "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101
Firefox/97.0"
HEADER "Accept: application/json, text/plain, */*"
HEADER "Accept-Language: en-US,en;q=0.5"
HEADER "Accept-Encoding: gzip, deflate, br"
HEADER "Content-Type: application/json"
HEADER "Content-Length: 54"
HEADER "Origin: https://dashboard.honeygain.com"
HEADER "Connection: keep-alive"
HEADER "Referer: https://dashboard.honeygain.com/login"
HEADER "Sec-Fetch-Dest: empty"
HEADER "Sec-Fetch-Mode: cors"
HEADER "Sec-Fetch-Site: same-origin"
HEADER "TE: trailers"

KEYCHECK
KEYCHAIN Failure OR
KEY "Bad credential"
KEYCHAIN Success OR
KEY "{\"meta\":null,\"data\":"

PARSE "<SOURCE>" JSON "access_token" -> VAR "tk"

REQUEST GET "https://dashboard.honeygain.com/api/v1/users/balances"

HEADER "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101


Firefox/97.0"
HEADER "Authorization: Bearer <tk>"

PARSE "<SOURCE>" JSON "credits" Recursive=TRUE CreateEmpty=FALSE -> CAP "Balance"

Want to practice on similar difficulty websites?

https://order.andpizza.com/#/login

https://app.memrise.com/signin
USEFUL INFORMATION FOR BEGGINERS BY HARRY

VISIT HIS THREAD HERE - https://cracked.io/Thread-CONFIG-GUIDE-Good-guide-for-beginners

AKAMAI AND STATIC VARIABLES

Okay first offs, static variables are terrible. What I mean by this is static cookies, csrf tokens, AKAMAI
COOKIES FOR FUCK SAKES, x-acf-sensor-data and shit like that. Some sites use static variables, but most
don't. Take for instance this config:

As you can see, this "config maker" uses a static akamai cookie along with static akamai-bmp sensor
data (red and dark blue). They're also using a static sig (light blue) and static unix (light blue). I'm not
sure about the other headers as I haven't attempted Zalando before due to their akamai-bmp. The other
headers may be static but as I said, I'm not sure. Anyways, in case you don't know what akamai is, it's an
anti-bot that prevents us config makers from sending requests to the login api. You need a specific
cookie or sensor data in this case. Sensor data is used for apps (I haven't seen it in a website before,
correct me if I'm wrong) whereas akamai on a website uses cookies and some other shit. Zalando also
contains a signature and unix like Onlyfans. Using static variables like this will work for maybe 3
requests, but after that, it won't work and it'll more than likely lock your accounts. If you're going to
attempt a site with akamai or app, I recommend trying to find an alt api unless you have the bypass
(obviously). This not only makes you look bad as a config maker, but proves you don't have much
knowledge in the config scene which isn't what you want for obvious reasons. You'll also be mocked by
other config makers. You can identify akamai by looking in your httpsdebugger under the cookies
section of the api you're looking at. It'll have a cookie called _abck. Sometimes you might be able to get
an unenforced akamai site where it isn't actually enforced on their site despite them having akamai on
there. This was seen with a Panera config I made quite a while ago where they unenforced one of their
api's and you got like 4k+ cpm.

PARSING

When you're parsing a csrf token, make sure you place the variable name CORRECTLY into the token
thing. Lets say hypothetically I parse a csrf token with the name "t" then I go and place the variable
name under the csrf token as "<T>". This'll just give you <T> because the variable names are case-
sensitive and the site will give you a response "csrf token wrong" or something along those lines (unless
the site is fucked/has silent-ban). You need to make sure you parse all variables correctly and use the
correct variable name otherwise problems will arise within your config.

UNIX

Unix is the number of seconds that have elapsed since 00:00 UTC on 1 January 1970. It's used in some
sites, including Zalando. Openbullet has a feature in the function block where you can generate the
current unix time. You can spot it by looking at the first two numbers, most commonly it has 10
numbers, however, sometimes it has 13 since some sites include the milliseconds. For example,
1632555366233, I'd just remove the first ten numbers and put your variable and leave the last 3
(doesn't always work I don't think).

Omylord was kind enough to send some JS to generate 13 unix.

BEGIN SCRIPT JavaScript

var TIME = new Date().getTime();

END SCRIPT -> VARS "TIME"

The variable is <TIME>

Thanks Omylord!

PerimeterX

PerimeterX is sort of similar to akamai, however, they use (most commonly), a security where they
redirect you to another page and make you solve a press & hold captcha and give you a cookie which
gives you access to login. This is seen on many sites including Sams Club, StockX, Goat, Walmart, etc. As I
said with akamai, I wouldn't try with it unless you have a bypass or you're trying to bypass it, just find an
alt api. You can identify PerimeterX by looking at the cookies in your httpsdebugger. If the site has pxhd
in the cookies, it has perimeterX. Very rarely, sites may have unenforced PX where you can send a
request to the login api despite them having the PX cookie. That's extremely rare, but it doesn't hurt to
try anyways.

Shape

I don't know much about shape, however, it's easy to identify. If you look in the headers, you'll see x-(a
random string of letters)-a, followed by a fucking shit ton of characters. It's encrypted headers and it's
whack, that's all I know.

Anyways, I hope this guide helps some config makers and most importantly, helps people when looking
at configs they bought. WATCH OUT FOR STATIC SHIT. This took a while to make, I'd appreciate if y'all
would drop a like, thank you! Also, if you have any other tips, leave them in the comments below and if
I'm wrong about anything, also leave a comment below and I'll correct it.

You might also like