You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/hits/general-info.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ sidebar_position: 1
5
5
6
6
# Hits
7
7
8
-
All of the hits you obtain with a *Multi Run Job* that has *Database* in its *Hit Outputs* will be saved to the SQLite database, usually saved in `UserData/OpenBullet2.db`. You can view them in the *Hits* section of OpenBullet 2.
8
+
All of the hits you obtain with a *Multi Run Job* that has *Database* in its [hit outputs](./hit-outputs.md) will be saved to the SQLite database, usually saved in `UserData/OpenBullet2.db`. You can view them in the *Hits* section of OpenBullet 2.
9
9
10
10
### Types of hits
11
11
Hits have a type that depends on the *status* of the bot when it ended the execution of the config. Configs can change the status of the bot that executes them through *Keycheck* blocks or statements that specifically set the value of the `data.STATUS` variable. The values of the status that will result in a hit being sent to the hit outputs (for example the database) are, by default,
The hits you obtain with a *Multi Run Job* can be saved or sent to different places. You can configure them in the hit outputs of a Multi Run Job. You can add more than one hit output: in this case, the hit will be saved/sent to each of the outputs you configured.
8
+
9
+
### Database
10
+
Hits will be saved to the SQLite database, usually found at `UserData/OpenBullet2.db`. You can view them in the *Hits* section of OpenBullet 2.
11
+
12
+
### File System
13
+
Hits will be stored inside the folder you specify, following this structure:
14
+
15
+
```text
16
+
BaseFolder
17
+
- ConfigName
18
+
- SUCCESS.txt
19
+
- TOCHECK.txt
20
+
- CUSTOM.txt
21
+
- ...
22
+
```
23
+
24
+
If the folder does not exist, it will be automatically created. Hits are stored in the format `<DATA> | <CAPTURE>`. This cannot currently be changed.
25
+
26
+
### Discord
27
+
Hits will be sent to a Discord Webhook URL of your choice. You can also specify the username and avatar that the bot will use.
28
+
29
+
### Telegram
30
+
Just like for discord, hits will be sent to a Telegram chat via a bot. You just need the bot token and the chat id.
31
+
32
+
### Custom Webhook
33
+
If you want to implement a custom sink for your hits, you can use this custom webhook. Hits will be sent to this hook via a POST request with an `application/json` payload such as:
34
+
35
+
```json
36
+
{
37
+
"data": "my data",
38
+
"capturedData": "captured data",
39
+
"configName": "my config",
40
+
"configAuthor": "author",
41
+
"timestamp": 1714754553,
42
+
"type": "SUCCESS",
43
+
"user": "username"
44
+
}
45
+
```
46
+
47
+
Where `username` can be configured via the hit output options.
48
+
49
+
:::info INFO
50
+
For the last three hit outputs, there is an option to only send hits with a `SUCCESS` type and not other types.
You can give your job a *name* to quickly identify it, especially in the [Job Monitor](../job-monitor.md).
20
21
22
+
You can also specify the *start condition* and number of *bots* to use (which can also be changed at runtime).
23
+
24
+
:::info INFO
25
+
Do not use more bots than needed to avoid overloading both your system and the endpoint, most of the times the sweet spot is in the middle!
26
+
:::
27
+
28
+
#### Start Condition
21
29
The start condition tells the job how long to wait before starting. This is used to start the job at a specific time, for example if you know you will not be at the computer. There are two types of start conditions:
22
-
-**Start in...** - relative, starts the job after a given amount of time from now
30
+
-**Start in...** - relative, starts the job after a given amount of time
23
31
-**Start at...** - absolute, starts the job at a specific time
24
32
25
-
You have to manually click on *Start* after you created the job to activate the wait. A timer will be displayed to let you know that the job is waiting to start.
33
+
You have to manually click on *Start* after you created the job to activate the wait. A timer will be displayed to let you know that the job is waiting to start (you will be able to skip the wait during this time).
26
34
27
35
<!--
28
36
TODO: ADD IMAGE HERE
29
37
-->
30
38
31
-
### Data Pool
39
+
#### Config
40
+
You can select the config that you want the bots to run.
Here you can define the sources from which proxies will be loaded. The available sources are:
46
+
-**Group** - loads proxies from one of the proxy groups you created in the *Proxies* section of OpenBullet 2
47
+
-**File** - loads proxies from a file on disk
48
+
-**Remote** - loads proxies from a remote URL
49
+
50
+
These sources will be queried when you start a job that requires proxies, and every time all proxies are banned if you set the *No valid proxy behaviour* to *Reload*.
32
51
52
+
Please refer to [this doc page](../../proxies/how-to-use-proxies.md) to know more about what each proxy setting does.
The data pool defines the set of inputs that will be provided to the bots, which will then process them using the config you provided. The available data pools are:
36
58
-**Wordlist** - select a pre-imported file
37
-
-**File** - directly select a file from the file system
59
+
-**File** - directly select a file from the file system without importing it as a wordlist first
38
60
-**Range** - generates a range of numbers
39
61
-**Combinations** - generates all possible combinations of a string
40
62
-**Infinite** - an infinite source of empty inputs, for jobs that should be running forever
These are the sources from which proxies will be loaded. The available sources are:
47
-
-**Group** - loads proxies from one of the proxy groups you created in the *Proxies* section of OpenBullet 2
48
-
-**File** - loads proxies from a file on disk
49
-
-**Remote** - loads proxies from a remote URL
50
-
51
-
These sources will be queried when you start a job that requires proxies, and every time all proxies are banned if you set the *No valid proxy behaviour* to *Reload*.
64
+
Please refer to [this doc page](../../wordlists/using-a-wordlist.md) to know more about data pool settings in a Multi Run Job.
When a check that is performed through a config has a result that is either `SUCCESS`, `CUSTOM`, `NONE` or one of the custom statuses in your `Environment.ini` file, OpenBullet 2 will count that as a *hit* and will store it in the hit outputs you configured. The available hit outputs are:
@@ -61,46 +73,4 @@ When a check that is performed through a config has a result that is either `SUC
61
73
-**Telegram bot** - sends the hits to telegram
62
74
-**Custom webhook** - sends the hits to a custom webhook
You can select the *config* you want to execute and the number of *bots* that will execute it. The number of bots can always be changed later, and even during the run.
73
-
74
-
:::info INFO
75
-
Do not use more bots than needed to avoid overloading both your system and the endpoint, most of the times the sweet spot is in the middle!
76
-
:::
77
-
78
-
After that, you can set the *skip*, which says how many items of the data pool will be skipped from the start. This is only useful when using wordlists to support resuming from a previous checkpoint.
79
-
80
-
#### Proxy Settings
81
-
The *Proxy Mode* can have the following values
82
-
-*On* - forces the use of proxies
83
-
-*Off* - disabled the use of proxies
84
-
-*Default* - lets the config decide, according to the *Use proxies* option in the *Config Settings*
85
-
86
-
The *No valid proxy behaviour* option regulates what happens when all proxies are banned or invalid, and can have the following values
87
-
-*DoNothing* - will do nothing
88
-
-*Unban* - sets all proxies as available without pulling them again from the configured proxy sources (this guarantees that the same proxies are used when running a job)
89
-
-*Reload* - loads new proxies by polling the proxy sources (if the sources updated in the meantime, it will pull new proxies and remove the old ones)
90
-
91
-
The *shuffle proxies* option will shuffle proxies in the pool before assigning them to bots.
92
-
93
-
Enable *never ban proxies* if you don't want your proxies to be banned (for example if you're using a rotating proxy service).
94
-
95
-
Use *concurrent proxy mode* if you want your proxies to be assigned to more than one bot at a time.
96
-
97
-
You can set up a *periodic reload interval*, which is the amount of time that will pass between automatic reloads. This is useful if you want to keep reloading your proxies and not wait until all are banned.
98
-
99
-
The *proxy ban time* setting regulates the amount of time for which a proxy will stay banned before it will be able to get unbanned. This is useful if the site bans proxies for a given amount of time, so you can be sure that the proxy is not used for that time to avoid refreshing its timeout, and only start making requests again when the timeout has expired.
100
-
101
-
:::caution WARNING
102
-
The option *proxy ban time* only works when *no valid proxy behaviour* is set to *Unban*.
103
-
:::
104
-
105
-
#### Others
106
-
The *mark as to check on abort* option will mark all data lines as *to check* when you abort a job. This is useful since, when you hard abort a job, you have no guarantee that the data that is being processed has finished. Enable this option if you don't want to skip checking a single data line.
76
+
Please refer to [this doc page](../../hits/hit-outputs.md) to know more about hit outputs in a Multi Run Job.
0 commit comments